Oracle RMAN 11g Backup and Recovery (121 page)

Other RMAN Recovery Topics

We have covered a number of restore operations that you can do with RMAN, but a few more topics remain. In this section, we discuss more of the restore operations that are available. First, we look at how to restore archived redo logs from your backup sets. Next, we look at restoring control file copies from backup. Then, we move on to discuss restoring datafile copies and backup set backups. Finally, we discuss validating your backups, an important feature in RMAN.

Read-Only Tablespace Recovery Considerations

By default, RMAN will not restore read-only datafiles when you do a full database restore, even if the read-only datafile is not there. To restore a read-only datafile during a full recovery, you need to include the
check readonly
parameter in the
restore
command: restore database check readonly;

Note that the RMAN behavior is different if you issue a
recover tablespace
or
recover datafile
command. When you use either of these two
recover
commands, recovery occurs regardless of the read-only nature of the tablespace.

Archived Redo Log Restores

During the normal course of recovery with RMAN, there is no real need to recover the archived redo logs. However, restoring one or more archived redo logs may be required occasionally. For example, you might want to use LogMiner to mine some information from the archived redo log files stored in your backups. In this event, RMAN allows you to restore specific archived redo logs by using the
restore archivelog
command, as shown in these examples: restore archivelog all;

restore archivelog from logseq 20 thread 1;

restore archivelog from logseq 20 until logseq 30 thread 1;

You might want to have Oracle restore the archived redo logs to a location other than the default location. To do this, use the
set
command with the
archivelog destination to
parameter: run

{

set archivelog destination to "d:\oracle\newarch";

restore archivelog all;

}

Note that there is no alternative to the
set
command, so a
run
block is required. Finally, be aware that RMAN will not restore an archived redo log to disk if it determines that the archived redo log already exists. Even if you change the destination to a destination other than the default archive log destination, Oracle will not recover an archived redo log to that new destination.

Datafile Copy Restores

You can restore your database datafiles from a datafile copy (as opposed to a backup set). To do this, use the
restore from datafilecopy
command, and then use the
recover
command as you normally would to recover the database (or tablespace or datafile), as shown in this example:

Chapter 14: RMAN Advanced Recovery Topics
351

restore (datafile 5) from datafilecopy;

recover datafile 5;

sql "alter database datafile 5 online;"

Note that when you issue a
restore
command, it will identify the most current copy of the datafiles that needs to be restored and then restore those datafiles from that copy. The most current copy of a datafile might be within a datafile copy rather than a backup set. In that case, Oracle will recover the datafile copy. Also note that the use of parentheses is important; if they are not used, this command will fail.

Recovering Corrupted Data Blocks

RMAN offers
block media recovery
(BMR), which allows you to do block-level recoveries to repair logically or physically corrupted blocks in your Oracle database, even while the associated datafile is online and churning away the whole time.

So, just how do you do a block media recovery? It’s easy, as demonstrated in the following example. Suppose you receive the following error message when querying an Oracle table: ORA-01578: ORACLE data block corrupted (file # 19, block # 44)

ORA-01110: data file 19: 'd:\oracle\oradata\data\mydb maintbs 01.dbf'

This message is telling you that a block in the MAINTBS tablespace is corrupted. Of course, you need to do something about that. Without BMR, you would have had to recover the datafile from a backup. During this recovery, all data within that datafile would be unavailable to the users.

Instead, you can use BMR to recover just the corrupted blocks. This is facilitated through the
blockrecover
command. In the preceding example, the
blockrecover
command would look like this:

blockrecover datafile 19 block 44;

You can recover multiple blocks in multiple datafiles at the same time, if you like. Here are two examples of using
blockrecover
for such an operation:

BLOCKRECOVER DATAFILE 19 BLOCK 44,66,127;

BLOCKRECOVER DATAFILE 19 BLOCK 44 DATAFILE 22 BLOCK 203;

Of course, Oracle tracks block corruption that occurs during backups and copies. If a backup or copy operation has detected corruption, the operation will fail by default because Oracle will allow zero corruption in a backup. You can configure RMAN to allow a set amount of corruption, but this is not a recommended practice.

If you want to see all database corruption that might be detected by RMAN, you can use the
backup validate database
command, which populates the views V$BACKUP_CORRUPTION

and V$DATABASE_BLOCK_CORRUPTION with the results of all corrupted blocks. Here is some partial output of an execution of the
backup validate database
command: RMAN> backup validate database;

Starting backup at 18-JUL-09

using target database control file instead of recovery catalog

allocated channel: ORA DISK 1

channel ORA DISK 1: SID 117 device type DISK

channel ORA DISK 1: starting full datafile backup set

352
Part III: Using RMAN Effectively

channel ORA DISK 1: specifying datafile(s) in backup set

input datafile file number 00002 name C:\ORACLE\ORADATA\BORG\SYSAUX01.DBF

input datafile file number 00003 name C:\ORACLE\ORADATA\BORG\UNDOTBS01.DBF

input datafile file number 00001 name C:\ORACLE\ORADATA\BORG\SYSTEM01.DBF

input datafile file number 00005 name C:\ORACLE\ORADATA\BORG\EXAMPLE01.DBF

input datafile file number 00006 name C:\ORACLE\ORADATA\BORG\UNDO NEW 01.DBF

input datafile file number 00009 name C:\ORACLE\ORADATA\BORG\SMALL THREE01.DBF

input datafile file number 00004 name C:\ORACLE\ORADATA\BORG\USERS01.DBF

input datafile file number 00007 name C:\ORACLE\ORADATA\BORG\SMALL01.DBF

input datafile file number 00008 name C:\ORACLE\ORADATA\BORG\SMALLTWO.DBF

channel ORA DISK 1: backup set complete, elapsed time: 00:10:45

List of Datafiles

File Status Marked Corrupt Empty Blocks Blocks Examined High SCN

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

1 OK 0 12166 93440 4480511

File Name: C:\ORACLE\ORADATA\BETA1\SYSTEM01.DBF

Block Type Blocks Failing Blocks Processed

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

Data 0 66011

Index 0 12036

Other 0 3227

channel ORA DISK 1: starting full datafile backup set

channel ORA DISK 1: specifying datafile(s) in backup set

including current control file in backup set

including current SPFILE in backup set

channel ORA DISK 1: backup set complete, elapsed time: 00:00:03

List of Control File and SPFILE

File Type Status Blocks Failing Blocks Examined

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

SPFILE OK 0 2

Control File OK 0 1426

Finished backup at 18-JUL-09

Note in the sample output that all of the datafiles are checked. Once the check for corruption has completed, a report specific for each individual datafile is displayed (we only showed you the report for datafile system01.dbf in our example). Note also that the current control file and the current SPFILE are checked during the operation.

If corruption occurs during a copy operation, the V$COPY_CORRUPTION view indicates which backup sets contain corruption. Note that V$BACKUP_CORRUPTION is a historical view of past corruption. V$DATABASE_BLOCK_CORRUPTION is a view of current block corruption.