Answers to Review Questions

1.C.  The list backup of database command provides information on all database backups that are available for restore via RMAN.

2.A.  The crosscheck command is used to validate all RMAN-related metadata with associated physical backups on backup media.

3.B.  The resync catalog command is used to synchronize the recovery catalog with the database control file.

4.D.  The duration command is used to limit the overall time of a database backup.

5.E.  The catalog command is used to load backup set pieces that do not already exist into the recovery catalog or the control file.

6.B.  Expired backup set pieces are those backup set pieces that do not exist. They are discovered via the crosscheck command and marked as expired. The list expired command reports backup set records that are marked as expired. The delete expired backup command marks the backup metadata in the control file and recovery catalog with a status of DELETED.

7.C, D.  The delete obsolete command will mark the related metadata records for the backups as DELETED in the control file and the recovery catalog.

8.D.  If a backup is expired, it means that a crosscheck command has detected that one or more backup set pieces associated with that backup are missing.

9.B.  You would make the lost backup set available again by running the crosscheck command once the backup set piece becomes available on the backup media.

10.B.  The backup will be allowed to run for 2 hours.

11.B, C, E.  The backup will fail after the duration period expires, but the datafiles that were backed up successfully will be able to be used in any restore operation. RMAN will prioritize any datafiles not backed up in subsequent backups. Also, the backup will not return an error when the duration expires and other commands will be executed.

12.B.  This output would be from the V$SESSION view. It contains the current wait event for each session as well as how long the wait has been occurring.

13.E.  The V$SESSION_LONGOPS view is used to estimate how long a given running operation has until it is complete.

14.B.  The users01.dbf database datafile has had an unrecoverable operation occur. Because an unrecoverable operation does not generate redo records, the data involved in that operation will be lost in the event of a recovery. The datafile should be backed up.

15.B.  The #bkps columns shows zero, which indicates that the datafile has not been backed up. The datafile may yet still be recoverable as long as the archived redo logs are available.

312  Chapter 7  n  Reporting, Monitoring, and Tuning with RMAN

16.C.  RMAN will attempt to spread the overall IO over the total stated duration of the backup listed in the duration parameter. This will have the effect of limiting the overall load on the database and reducing the performance impacts of the backup.

17.E.  This command lists all database datafiles that would require that more than three days of archived redo logs be applied in order to be restored.

18.B.  The report obsolete command will list all RMAN backups that have aged beyond the RMAN retention criteria and are eligible for removal.

19.C, E.  The report schema command does not contain the date of the last backup of the datafiles and tempfiles. Also, the report schema command does not report the checkpoint SCNs associated with each RMAN backup.

20.E.  If a backup is expired, then the physical backup set pieces are missing from the backup media. This backup cannot be restored unless the physical backup set pieces are found, and either re-cataloged or re-crosschecked.

We have already discussed the basics of recovering your Oracle database. You now know how to use the restore and recover commands to recover your database to the point of failure.

In this chapter, we will cover more advanced recovery topics. First we will cover RMAN incarnations, and then we will introduce you to RMAN database duplication. After that we will discuss tablespace point-in-time recovery, and we will close the chapter with some discussion of disaster recovery of your Oracle database.

Exam objectives are subject to change at any time without prior notice and at Oracle’s sole discretion. Please visit Oracle’s Training and Certification website (http://www.oracle.com/education/certification/) for the most current exam-objectives listing.

Switching Between RMAN Incarnations

We introduced you to the idea of RMAN incarnations in Chapter 2 and have talked about incarnations in several other chapters. A database incarnation is the measure of the logical lifetime of an Oracle database. A database’s first incarnation begins when it is created and ends whenever the resetlogs option is used to open the database. The next incarnation starts at the point of the resetlogs operation and ends at the point of the next resetlogs operations and so on. When a new incarnation is started, the log sequence numbers are reset, the online redo logs are flushed, and the database literally has a new future.

Sometimes when performing RMAN operations it is necessary to reset to a previous database incarnation. This is pretty rare and is typically done in cases where you have restored your database using point-in-time recovery. After such cases, if you need to perform another restore and that restore needs to be to an SCN that is before the current resetlog SCN, then you will have to reset the database incarnation.

For example, look at this output of this list incarnation command:

RMAN> list incarnation;

using target database control file instead of recovery catalog

If you wanted to restore the database to a point in time before 10/03/2008 at 14:05:15 (or SCN 904361), you would need to reset the database to one of the previous incarnations. If, however, you wanted to restore the database to the resetlog time/SCN or after that time, then you would not need to reset the database incarnation.

To reset the database incarnation, you would need to mount the database first. Then use the reset database to incarnation command. You include the incarnation number that you want to switch to in the command. This number comes from the Inc Key column displayed in the list incarnation command output. Here is an example of switching the database to incarnation number 2:

RMAN> shutdown immediate database closed database dismounted

Oracle instance shut down RMAN> startup mount

connected to target database (not started)

RMAN> Reset database to incarnation 2; database reset to incarnation 2

Figure 8.1 provides a graphic example of database incarnations. In this graphic,

the database crashes at SCN 40000 (shown in point A in the figure). We restore the database from a backup taken at SCN 10000 (shown in point B in the figure) and recover it to SCN 25000 (shown in point C). Perhaps we have lost the redo logs needed to restore the database beyond SCN 25000, and so we open the database at SCN 25000 with the alter database open resetlogs command. This creates a new incarnation of the database. Note that the SCNs are greater than 40000 (because the SCN does not change), but notice that there is a new timeline with which the changes are being recorded (the tangent line heading to the northeast in the figure). This is the new incarnation of the database (demonstrated in point D). It’s a completely new life for the database, and everything that happened in the database in the previous life after the previous SCN 25000 is as if it had never happened. There will now actually be two SCN 25000s in the redo stream.