E x e r c i s e 8 .1   ( c o n t i n u e d )

If you want to run this exercise again after the first successful run, you will need to perform these steps:

1.Shut down the auxiliary instance (now it’s a new database!).

2.Remove the spfile assigned to the auxiliary instance.

3.Startup nomount the auxiliary instance.

4.Run this exercise again starting at step 11.

Performing an RMAN Tablespace

Point-in-Time Recovery

As you may recall, when you do a point-in-time recovery of an Oracle database, you have to restore the entire database to the point in time selected. There are times when you may want to restore a specific tablespace to a specific point in time. DBAs have been doing this type of recovery manually for a long time. Simply, they restore a backup to another database on the same or a different server to the point in time they want to restore the tablespace to. They then export the objects they want to restore (or use transportable tablespaces) to the original database.

Of course, this is a lot of manual work. RMAN automates tablespace point-in-time recovery (TSPITR) for you, making recovery much easier to perform. In this section we will address TSPITR. We will first look at the TSPITR-related prerequisites and considerations and then look at the aftereffects of a TSPITR. We will then look into setting up for and executing a TSPITR.

328  Chapter 8  n  Performing Oracle Advanced Recovery

For the until time commands shown in this chapter, we set NLS_DATE_ FORMAT at the Windows OS level to a value of mm/dd/yyyy hh24:mi:ss as seen in this example:

Set nls_date_format=mm/dd/yyyy hh24:mi:ss

How you set the NLS_DATE_FORMAT OS level parameter will vary by platform.

If you are using a date format other than ours, you will need to reformat the date/time in the commands to meet that format. You can also use the to_date function to format the date as seen in this example:

recover tablespace users

until time “to_date(‘10/06/2008:22:42:00’,’mm/dd/yyyy:hh24:mi:ss’)“ auxiliary destination ‘c:\oracle\auxiliary’;

TSPITR Overview

RMAN provides the ability to do a full TSPITR on a given tablespace or set of tablespaces with minimal user interaction. This is known as fully automated TSPITR. You may want to exercise more granular control over TSPITR, in which case you might want to choose to perform customized RMAN TSPITR where you have more control over the creation of the auxillary instance and other aspects of the operation. For the purposes of this book, we will be concerned with only fully automated TSPITR.

Before starting TSPITR  ​  Since​ TSPITR creates an auxiliary-instance database, it needs to know where you want to put the files associated with that database. For automated TSPITR, you are going to use the auxiliary destination parameter of the recover tablespace command (discussed shortly); then you will need to create the directory associated with the auxiliary destination before executing the TSPITR.

Starting TSPITR  ​  ​You will start TSPITR using the RMAN command recover tablespace. Special syntax (which we will cover shortly) that you will include in the body of the command will indicate to RMAN that this is a tablespace TSPITR rather than a normal tablespace recovery. Here is an example of the use of the recover tablespace command to start a TSPITR recovery:

recover tablespace users

until time ‘10/06/2008:22:42:00’

auxiliary destination ‘c:\oracle\auxiliary’;

In this case, we are executing a TSPITR of the USERS tablespace. We want to recover the entire USERS tablespace to 10/6/2008 at 22:42:00 hours. The auxiliary destination clause, discussed earlier, indicates where we want RMAN to create the auxiliary instance database files—in this case, the directory c:\oracle\auxiliary.

Now that we have executed the recover tablespace command, what happens next?

The TSPITR auxiliary instance   ​  ​TSPITR requires the use of an auxiliary instance just as database duplication does. The auxiliary instance (in RMAN output, it’s called an automatic

instance) is the database that will be used to perform the TSPITR. It is a transient database, used just long enough to restore the tablespaces, export the database, and finish the TSPITR. The main difference here is that once RMAN is done with the TSPITR, the auxiliary instance will no longer be needed.

TSPITR transport-set check   ​  When​ you start the TSPITR with the recover tablespace command, RMAN will check that the tablespace you want to recover can actually be recovered. It does this by checking the transport set to ensure that it’s wholly self-contained. See the next section, “Checking the Transport Set,” for more information on this process and why it’s needed.

Create the auxiliary instance   ​  ​Once RMAN confirms that the tablespace set can be transported, it will create the auxiliary instance, start it, and connect to it. This is nice since you will not have to create the auxiliary instance. You can opt to create the auxiliary instance yourself if there are specific reasons to do so. RMAN will create a control file for the auxiliary instance.

Target database tablespaces are taken offline   ​  Once​ the auxiliary instance has been created, the tablespaces on the target database to be moved will be taken offline. This implies that the data in these databases will not be available to users until the tablespaces are brought back online. Since you are restoring these tablespaces to a different point in time, the data the users will see the next time the tablespaces are brought back online will possibly be very different. Keep this in mind when doing a TSPITR: You are impacting the entire tablespace or set of tablespaces. If someone is not aware of what you are doing, you might get a very nasty phone call.

Transport the source tablespaces   ​  ​Now that the tablespace(s) has been taken offline, RMAN will restore the recovery set and the auxiliary set from the target database to the auxiliary instance. The recovery set is the set of tablespaces that you are going to recover with TSPITR. The auxiliary set is the set of datafiles that are required to get the auxiliary instance running. This includes files for the SYSTEM tablespace, the UNDO tablespace, and the SYSAUX tablespace and temporary tablespace tempfiles.

Recover the auxiliary-instance database  ​  Once​ the auxiliary set and the recovery set are restored, RMAN will proceed to recover the auxiliary-instance database to the point in time identified when the RMAN recover command was issued. Once the restore is complete, the auxiliary-instance database will be opened.

Transport the tablespace set  ​  ​TSPITR uses transportable tablespaces to facilitate the movement of the tablespace datafiles from the auxiliary database instance to the target database instance. To perform this action, RMAN will first export needed metadata from the auxiliary database instance. It will then shut down the auxiliary database instance. On the target system, RMAN switch commands are executed to cause the datafile locations in the target database control file to be switched to the newly recovered datafiles. Finally, the backed-up metadata will be restored to the target database so the data in the restored tablespaces will be accessible to the target database.

330  Chapter 8  n  Performing Oracle Advanced Recovery

Complete the operation  ​  ​The auxiliary database files will be removed after the operation is completed. The target database tablespaces will be offline. You should back up those tablespaces, and then you will need to bring those tablespaces online manually. Once you do, you will find that the tablespaces contain the data in the version it existed in at the restore time indicated in the recover command.

TSPITR does not restore the point-in-time statistics for the objects contained in the restored tablespaces. Thus, you should analyze the objects in the tablespaces after completing the TSPITR.

Checking the Transport Set

When you perform a TSPITR, you want a transport set that is self-contained. This means that the tablespaces in the transport set do not have external object references; that is, they don’t refer to objects that are not in the transport set. For example, suppose you are transporting the USERS tablespace, and a table in that tablespace has an index in the INDEX tablespace. In this case, you will not be able to transport the USERS tablespace unless you also transport the INDEX tablespace. When you transport both the USERS and the INDEX tablespace, you are transporting a wholly self-contained transport set.

RMAN will determine if the transport set is fully self-contained, but you may want to check beforehand to save some time. You can query the TS_PITR_CHECK view. In our example, USERS and INDEX_TBS are self-contained. If USERS is not transported with INDEX_TBS, then the TSPITR will error out. To determine if USERS and INDEX_TBS are self-contained, we would issue this query:

SQL> SELECT ts1_name, ts2_name, reason

2FROM SYS.TS_PITR_CHECK

3WHERE (

4TS1_NAME IN (‘USERS’,’INDEX_TBS’)

5AND TS2_NAME NOT IN (‘USERS’,’INDEX_TBS’)

6)

9AND TS2_NAME IN (‘USERS’,’INDEX_TBS’)

no rows selected

If you were to plan to transport only the USERS tablespace, then you would see the following error:

SQL> SELECT ts1_name, ts2_name, reason 2 FROM SYS.TS_PITR_CHECK

3WHERE (

4TS1_NAME IN (‘USERS’)

5AND TS2_NAME NOT IN (‘USERS’)

6)

9AND TS2_NAME IN (‘USERS’)

---------------------------------------------------------------------

USERS INDEX_TBS

Tables and associated indexes not fully contained in the recovery set

Lost Objects

When you perform a TSPITR recovery, it is possible that you will lose objects in the tablespace that were created after the point in time to which you restore the tablespace. You can export these objects before the TSPITR with Oracle Data Pump and then import them after the TSPITR has completed.

By querying the view TS_PITR_OBJECTS_TO_BE_DROPPED, you can determine which objects will be lost, as shown in this example:

SQL> SELECT OWNER, NAME, TABLESPACE_NAME,

2 TO_CHAR(CREATION_TIME, ‘YYYY-MM-DD:HH24:MI:SS’) 3 FROM TS_PITR_OBJECTS_TO_BE_DROPPED

4 WHERE TABLESPACE_NAME IN (‘USERS’)

5AND CREATION_TIME >

E x e r c i s e 8 . 2

Performing a Tablespace Point-in-Time Recovery

In this exercise, you will perform a tablespace point-in-time recovery of the USERS tablespace.

1.Log into the scott account in the database with SQL*Plus:

C:\Documents and Settings\Robert>set oracle_sid=orcl C:\Documents and Settings\Robert>sqlplus scott/tiger

SQL*Plus: Release 11.1.0.6.0 - Production on Thu Oct 9 21:06:00 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, OLAP, Data Mining and

Real Application Testing options SQL>

2.Create a table called TSPITR for this exercise. It will be created in the USERS tablespace (create the USERS tablespace if required):

SQL> create table tspitr (id number, the_date date) tablespace users; Table created.

3.Exit SQL*Plus and start RMAN. Back up the database with RMAN:

RMAN> backup as compressed backupset database plus archivelog delete input;

4.Exit RMAN and connect to the scott schema again with SQL*Plus:

RMAN> exit

Recovery Manager complete.

C:\Documents and Settings\Robert>sqlplus scott/tiger

SQL*Plus: Release 11.1.0.6.0 - Production on Thu Oct 9 21:15:39 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, OLAP, Data Mining and

Real Application Testing options SQL>

5.Insert a record into the TSPITR table and commit:

SQL> insert into tspitr values (1,sysdate); 1 row created.

SQL> commit;

334  Chapter 8  n  Performing Oracle Advanced Recovery

E x e r c i s e 8 . 2   ( c o n t i n u e d )

Commit complete.

SQL>

6.Wait a minute and insert another record into TSPITR. Commit the record:

SQL> insert into tspitr values (2,sysdate); 1 row created.

SQL> commit; Commit complete. SQL>

7.Select from the TSPITR table. Record the time/date of both records for a later step:

SQL> select * from tspitr;

ID THE_DATE

---------- -------------------

1 10/09/2008 22:09:02

1 10/09/2008 22:10:04

8.Exit SQL*Plus.

9.From the operating system, create a directory for the auxiliary database files. In our case we are using c:\oracle\oradata\auxiliary.

c:>mkdir c:\oracle\oradata\auxiliary

10.Start RMAN. Connect to the target database:

C:\Documents and Settings\Robert>rman target=/ Recovery Manager: Release 11.1.0.6.0 - Production on Thu Oct 9 21:30:01 2008

Copyright (c) 1982, 2007, Oracle. All rights reserved. connected to target database: ORCL (DBID=1194923408) RMAN>

11.Perform a tablespace point-in-time recovery of the USERS tablespace to a point in time between insert #1 and insert #2.

RMAN> recover tablespace users

2> until time ‘10/09/2008:22:09:20’ auxiliary destination ‘c:\oracle\ auxiliary’;

< we have decided to remove the output here to save a few trees.>

12.Back up the USERS tablespace:

RMAN> backup tablespace users;

E x e r c i s e 8 . 2   ( c o n t i n u e d )

Starting backup at 10/09/2008 22:28:51 using channel ORA_DISK_1

channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00004 name=C:\ORACLE\ORADATA\ORCL\USERS01.DBF

channel ORA_DISK_1: starting piece 1 at 10/09/2008 22:28:58 channel ORA_DISK_1: finished piece 1 at 10/09/2008 22:28:59

piece handle=C:\ORACLE\FLASH_RECOVERY_AREA\ORCL\BACKUPSET\2008_10_09 \O1_MF_NNNDF_TAG20081009T222851_4GXPJB5V_.BKP tag=TAG20081009T222851 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 10/09/2008 22:28:59

Starting Control File and SPFILE Autobackup at 10/09/2008 22:28:59 piece handle=C:\ORACLE\FLASH_RECOVERY_AREA\ORCL\AUTOBACKUP\2008_10_09 \O1_MF_S_667693739_4GXPJMNZ_.BKP comment=NONE

Finished Control File and SPFILE Autobackup at 10/09/2008 22:29:14.

13.Connect to SYS with SQL*Plus:

C:\Documents and Settings\Robert>sqlplus sys/robert as sysdba SQL*Plus: Release 11.1.0.6.0 - Production on Thu Oct 9 22:31:40 2008 Copyright (c) 1982, 2007, Oracle. All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production With the Partitioning, OLAP, Data Mining and

Real Application Testing options

14.Bring the USERS tablespace online:

SQL> alter tablespace users online; Tablespace altered.

15.Select from the TSPITR table. Notice that only the first record is now in the table. This concludes this exercise.

SQL> select * from tspitr;

ID THE_DATE

---------- -------------------

1 10/09/2008 22:09:02

336  Chapter 8  n  Performing Oracle Advanced Recovery

Performing a Database

Disaster Recovery

In the previous several chapters, we discussed user-based backup and recovery and RMANbased (or server-based) backup and recovery. So what happens if there is a complete disaster and you lose everything? First, you need to plan for such an event. Taking backups and moving them offsite is the first step. You will need to make sure that you not only have backups of your database offsite, but that you have copies of the Oracle software available offsite too. Any parameter files that are not backed up by RMAN (say, your tnsnames.ora or your listener

.ora files) should be backed up offsite.

We thought we would close this chapter with a review of what you would need to do

if you had to recover from offsite backups following a disaster. If you are using RMAN and you find you need to do a complete database recovery, you would follow the steps listed below. Chapter 6 provides more detail on the individual RMAN recovery steps and how to execute them:

1.Restore the OS.

2.Restore the Oracle software.

3.Configure Oracle networking.

4.Ensure that you have access to the RMAN backup set pieces that you need.

5.Restore the database spfile from the control-file autobackup. We assume that if you are doing control-file autobackups to disk, you will move those backups to tape and offsite them.

6.Once the database spfile is restored, you can mount the database and restore the control files of the database from the autobackups.

7.Once the database control file is restored, you would begin the restore and recovery of the database proper. This would complete your disaster-recovery operation. If you need to restore database files to a different location, you would use the set newname RMAN command as discussed in Chapter 6.

8.After you have completed the restore and recovery of the database datafiles, you would open the database with the alter database open resetlogs command.

If you are doing user-managed backup and recovery, the process is not all that different, as you can see here:

1.Restore the OS.

2.Restore the Oracle software.

3.Configure Oracle networking.

4.Ensure that you have access to the database backups that you will be restoring.

5.Restore the database parameter file or spfile from your backup media.