Oracle Rman Advanced Recovery Overview (ii) Recovery theme based on Rman

1, read-only table space recovery

By default, Rman does not restore a read-only data file when performing a full recovery database restore operation, even if a read-only data file is lost. To restore a read-only data file during a full recovery, you must use the check readonly parameter in the Restore command, such as:

Restore database Check readonly;

Note that Rman works differently when executing recover tablespace or recover datafile commands. When both commands are used, a recovery operation is performed regardless of whether the tablespace is read-only.

2, archive redo log Restore

During normal recovery using Rman, you do not have to restore the archived redo logs. Occasionally, however, you will be asked to restore one or more archived redo logs. For example, we might need to use Logminer to look up some information in the archive redo log file stored in the backup.

Restore Archivelog All;

Restore Archivelog from logseq=20 thread=1;

Restore Archivelog from logseq=20 until logseq=30 thread=1;

You can also restore archived redo logs to a location other than the default location:

Run

{

Set archivelog destination to "D:/arch";

Restore Archivelog All;

}

Note: 1. The set command in the example above has no workaround and must require the use of set.

2. If Rman believes that an archived redo log already exists, it will not restore the archived redo log on disk, and Oracle will not restore archived redo logs in this new location, even if the restore location is set differently from the default archive log location.

3, the restoration of data file copy

You can restore the database's data files from a copy of the data file (not a backup set). To do this, you need to first use the Restore from Datafilecopy command, and then use the recover of the recovery database (or tablespace, data file).

Rman>restore (datafile 5) from Datafilecopy; --The parentheses here are mandatory, and if there is no error

Rman>recover datafile 5;

Sql>alter database datafile 5 online;

When you perform restore, the command identifies the most recent copy of the data file that needs to be restored, and then restores the data files from that copy. The most recent copy of the data file may be in a copy of the data file, not in a single copy. In this case, Oracle restores the copy of the data file.

4, restore the corruption data block

Even if the data files associated with the corruption block are online, you can repair these logical or physical corruption blocks in the Oracle database by performing block-level recovery operations with block media recovery (blocks media recover:bmr).

When a block error occurs, there is an error message:

Ora-01578:oracle data block corrupted (file #18, block #88)

If there is no BMR, we must recover the data file from a backup, and during the recovery process, the user cannot use all the data in the block file.

Recovery with BMR is simple, just execute the blockrecover command:

Blockrecover datafile block 88;

If necessary, multiple blocks of data files can be recovered at the same time. Such as:

Blockrecover datafile block 16,17,88,108;

Blcokrecover datafile datafile Blcok 188;

Oracle tracks data block corruption that occurred during backup and recovery. If corruption is detected in a backup or copy operation, all of the backups fail because Oracle does not allow corruption to occur in the backup. Of course, Rman can be configured to allow a certain number of corruption, but this usage is not recommended.

You can use the backup validate database command to view all databases corruption that Rman detects. This command populates all the detected corruption blocks in the v$backup_corruption and v$database_block_corruption views. If corruption occurs during a copy operation, the V$copy_corruption view indicates the backup set that contains corruption.

Note that v$backup_corruption is a view that displays historical corruption, and v$database_block_corruption is a view that displays the current block of data corruption. Once you have fixed the block corruption of the database, you will need to rerun the backup validate Database command, and then query the V$database_block_corruption view to ensure that no other corruption exists.

The query V$database_block_corruption view allows you to view the details of a corruption block of data. As shown below, using the Blockrecover command with the corruption list restore parameter makes it easy to fix the corruption data blocks in the V$database_block_corruption view.

Blockrecover corruption list restore until time ' SYSDATE-5 ';

This command restores all corruption data blocks in the last 5 days of the corruption list. In the above command, you can also use until time and until sequence.

5, restore the previous counterpart

A database counterpart (incarnation) corresponds to the specific logical lifetime of the database. Sometimes we need to restore the database using a backup that was generated before the Resetlogs command was opened to open the database, or you might need to revert to a point in time before the last Resetlogs command was executed. This requires the use of incarnation.

5.1 Restoring a previous counterpart using the recovery directory

Assuming that the backup operation was performed using the recovery directory and that the Resetlogs command was recently used to perform point-in-time recovery, it is now necessary to recover the database using a backup prior to the execution of the Resetlogs command.

Operation Steps:

(1) Start but do not load the instance because we have to get a control file associated with the recovery database counterpart first

(2) using the Reset database to incarnation command for Rman to indicate the backup set of the corresponding object.

(3) Restore Controlfile to enable Rman to restore the latest control files

(4) Loading the database

(5) Restore database

(6) Recover database

(7) using Resetlogs to open the database

Examples are as follows:

C:/users/administrator.daviddai>rman Target/catalog RMAN/RMAN@ORCL;

Recovery manager: Release 11.2.0.1.0-production on Tuesday July 6 10:31:40 2010

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Connect to target database: ORCL (dbid=1247395743)