Oracle RMAN 11g Backup and Recovery (122 page)

Once you have corrected the database block corruption, rerun the
backup validate database
command, and then query V$DATABASE_BLOCK_CORRUPTION to ensure that no further corruption exists.

As we mentioned already, you can query the view V$DATABASE_BLOCK_CORRUPTION

for details on corrupted blocks. To make it easy to correct corrupted blocks in V$DATABASE_

BLOCK_CORRUPTION, you can use the
blockrecover
command with the
corruption list restore
parameter:

BLOCKRECOVER CORRUPTION LIST RESTORE UNTIL TIME 'SYSDATE - 5';

Chapter 14: RMAN Advanced Recovery Topics
353

If you are restoring from an older level 0 and you want to validate that the block and redo stream will have problems during
blockrecover
, use NOFILEUPDATE to make a test run before you apply and redo:

BLOCKRECOVER CORRUPTION LIST RESTORE UNTIL TIME 'SYSDATE - 5' NOFILEUPDATE; In this case, we restore all corrupted blocks on our corrupt block list that are no older than five days. You can also use the
until time
and
until sequence
keywords with this command.

Recovering to a Previous Incarnation

Recall from our earlier discussion about the
resetlogs
command that an incarnation of a database is a representation of a specific logical lifetime for that database. As a hotshot DBA, you may find yourself in an odd restore situation in which you need to restore your database using a backup that took place from before the last time you opened the database using the
resetlogs
command, and/or you may wish to restore to a point in time before you issued the last
resetlogs
command. In this section, we discuss how to recover your database from a previous incarnation both with a recovery catalog (a rather easy task) and without a recovery catalog (plan for time and frustration).

Finally, we will cover a rather unique recovery situation in which you need to recover through the
resetlogs
command.

Recovering to a Previous Incarnation with a Recovery Catalog

Let’s look at an example of recovering from a previous incarnation. In this example, we assume we have done backups using a recovery catalog and that we have recently done a point-in-time recovery using
resetlogs
. Now, we need to recover our database using a backup taken from a point in time before we issued our
resetlogs
command. First, we need to list the database incarnations by using the
list incarnation
command (covered in detail in the next chapter): RMAN> list incarnation;

List of Database Incarnations

DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time

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

1 2 RECOVER 2539725638 NO 763059 08-JUL-02

1 123 RECOVER 2539725638 YES 764905 09-JUL-02

In this list, we discover that there have been two different incarnations of our database, incarnation key 2 and incarnation key 123. The CUR column indicates that we are on incarnation key 123 right now (since it says YES). So, we need to switch back to incarnation 2 of the database.

Now that we know which incarnation we want to recover, we proceed to do the recovery (we removed some of the output here to make this example clearer):

RMAN> startup force nomount

Oracle instance started

RMAN> reset database to incarnation 2;

database reset to incarnation 2 in recovery catalog

RMAN> restore controlfile;

Finished restore at 10-JUL-02

RMAN> restore database until scn 764904;

Finished restore at 10-JUL-02

RMAN> recover database until scn 764904;

starting media recovery

media recovery complete

354
Part III: Using RMAN Effectively

Finished recover at 10-JUL-02

RMAN> alter database open resetlogs;

database opened

new incarnation of database registered in recovery catalog

starting full resync of recovery catalog

full resync complete

The following steps describe what we have done in this example:

1.
Start the instance. We don’t mount it, though, because we first want to get a control file that is associated with the incarnation of the database we wish to recover.

2.
Use the
reset database to incarnation
command to indicate to RMAN which incarnation’s backup sets we wish to be considered for the recovery.

3.
Issue the
restore controlfile
command, prompting RMAN to restore the most current control file for us.

4.
Mount the database.

5.
Restore the database, doing an SCN-based restore (discussed earlier in this chapter). We have decided to restore the database to the SCN just before the last
resetlogs
(which was at SCN 764905), so we issue the
restore database
command, limiting the restore to SCN

764904.

6.
Issue the
recover
command, again limiting the recovery of the database to SCN 764904, and wait for the recovery to complete.

7.
Open the database, resetting the online redo logs.

Now, when we run the
list incarnation
command, the results are as follows: RMAN> list incarnation;

List of Database Incarnations

DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time

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

1 2 RECOVER 2539725638 NO 763059 08-JUL-02

1 123 RECOVER 2539725638 NO 764905 09-JUL-02

1 245 RECOVER 2539725638 YES 764905 10-JUL-02

Note the new incarnation of the database that has been created (with incarnation key 245).

Also note that the reset SCN for this new incarnation is the same as that of incarnation 123 (which was the active incarnation). The reset time, however, reflects the actual time that this incarnation was created.

Recovering to a Previous Incarnation Without a Recovery Catalog

Oracle has made recovery to a previous incarnation without a recovery catalog so much easier in Oracle Database 10
g.
No longer are you required to jump through hoops, ask Oracle developers for favors, and send them cookies! No, it’s simple!

To recover through a previous incarnation, you have a control file that is aware of the previous incarnation. This can be the current control file in most cases. If the current control file is not aware of the incarnation that you need to restore to, you need to restore a control file that is aware of this information to use this method of recovering your database. You can determine which incarnations your control file is aware of by using the
list incarnation of database
command, as shown in this example:

Chapter 14: RMAN Advanced Recovery Topics
355

RMAN> list incarnation;

List of Database Incarnations

DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time

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

4 4 ROB10R2 3753137102 PARENT 3599781 05-FEB-06

5 5 ROB10R2 3753137102 PARENT 3715262 08-FEB-06

6 6 ROB10R2 3753137102 CURRENT 4296046 20-FEB-06

In this example, we find that the control file contains information on incarnations (Inc Key) 4, 5, and 6. The current incarnation is incarnation 6. If we needed to restore incarnation 3, we could not use this control file, because incarnation 3 does not exist in this control file.

Note that the
list incarnation
output when not connected to a recovery catalog looks slightly different from the
list incarnation
output when connected to a recovery catalog. This is because you are getting your information from the control file, so certain keys (Inc Key, for example) will be different. This is perfectly normal.

If we wish to reset to incarnation 5 and then recover our database, we need to do the following:
1.
Run the
list incarnation
command from RMAN, and determine which incarnation we wish to reset to.