對這文章發表回應
發表限制: 非會員 可以發表
7 Advanced RMAN Recovery Techniques
This chapter describes how to perform restore and recovery using RMAN in a number of advanced scenarios.
This chapter contains the following topics:
Restore and Recovery of NOARCHIVELOG Databases
Restore and Recovery of the Database on a New Host
Performing Recovery with a Backup Control File
Performing Disaster Recovery
Performing Block Media Recovery with RMAN
RMAN Restore and Recovery Examples
Restore and Recovery of NOARCHIVELOG Databases
Restore of a database running in NOARCHIVELOG mode is very similar to restore of a database in ARCHIVELOG mode. The main differences are:
Only cold backups (that is, backups created when the database was shut down normally) can be used in restoring a database in NOARCHIVELOG mode
Media recovery is not possible, because there are no archived logs
A limited form of restore and recovery is possible for NOARCHIVELOG databases if the backup strategy for the database includes incremental backups. The incremental backups (which, like the full backup of a NOARCHIVELOG database must be created when the database is shut down) can be applied to a full database backup to apply recent changes up to the time of the incremental backup.
Recovering a Database in NOARCHIVELOG Mode Using Incremental Backups
You can perform limited recovery of changes to a database running in NOARCHIVELOG
mode by applying incremental backups. Note that the incremental backups must be consistent, like all backups of a database run in NOARCHIVELOG
mode, so you cannot make backups of the database when it is open.
Assume the following scenario:
You run database
trgt
inNOARCHIVELOG
mode.You use a recovery catalog.
You shut down the database consistently and make a level 0 backup of database
trgt
to tape on Sunday afternoon.You shut down the database consistently and make a level 1 differential incremental backup to tape at 3:00 a.m. on Wednesday and Friday.
The database has a media failure on Saturday, destroying half of the datafiles as well as the online redo logs.
In this case, you must perform an incomplete media recovery until Friday, the date of the most recent incremental backup. RMAN uses the level 0 Sunday backup as well as the Wednesday and Friday level 1 backups.
Because the online redo logs are lost, you must specify the NOREDO
option in the RECOVER
command.
You must also specify NOREDO
if the online logs are available but the redo cannot be applied to the incrementals.
If you do not specify NOREDO
, then RMAN searches for redo logs after applying the Friday incremental backup, and issues an error message when it does not find them.
After connecting to trgt
and the catalog database, recover the database with the following command:
STARTUP FORCE MOUNT;
RESTORE CONTROLFILE; # restore control file from consistent backup
ALTER DATABASE MOUNT;
RESTORE DATABASE; # restore datafiles from consistent backup
RECOVER DATABASE NOREDO; # specify NOREDO because online redo logs are lost
ALTER DATABASE OPEN RESETLOGS;
The recovered database reflects only changes up through the time of the Friday incremental backup. Because there are no archived redo logs, there is no way to recover changes made after the incremental backup.
Note:
If the current online logs contain all changes since the last incremental , then you can run RECOVER DATABASE without specifying NOREDO. In such a case, the changes in the online logs are applied.Restore and Recovery of the Database on a New Host
The procedure described in this section can be used to perform test restores, or to move a production database to a new host.
Note:
If your goal is to perform a test run of the disaster recovery procedures you would use following a real disaster, or to permanently move the target database to the new host, then use the procedure described in this section, which uses theRESTORE
and RECOVER
commands.Note, however, that the DBID for the restored test database will be the same as the DBID for the original database. If, after the restore and recovery process is complete, you connect to the test database and the recovery catalog, the recovery catalog is updated with information about the test database that can interfere with RMAN's ability to restore and recover the source database.
If your goal is to create a new copy of your target database for ongoing use on a new host, then use the RMAN DUPLICATE
command instead of this procedure. DUPLICATE
assigns a new DBID to the duplicate database it creates, allowing it to be registered in the same recovery catalog as the original target database. See "Creating a Duplicate Database with RMAN: Overview" for details about duplicating a database.
Preparing for Restore of a Database to a New Host
To prepare for the restore of the database to a new host, take the following steps:
Record the DBID for your source database. If you do not know the DBID for your database, see Oracle Database Backup and Recovery Basics for details on ways to determine the DBID.
Make the source database initialization parameter file accessible on the new host. Copy the file from the old host to a new host using an operating system utility.
Make sure backups used for the restore are accessible on the restore host. For example, if the backups were made with a media manager, then make sure the tape device is connected to the new host.
Note:
If you perform a test restore only, then do notconnect to the recovery catalog when restoring the datafiles. Otherwise, RMAN records information about the restored datafiles to the recovery catalog. This intereferes with future attempts to restore and recover the primary database. If you must use a recovery catalog because the control file is not large enough to contain the RMAN repository data on all of the backups that you need to restore, then export the catalog and import it into a different schema or database and use the copied recovery catalog for the test restore. Otherwise, the catalog considers the restored database as the current target database.
Testing the Restore of a Database to a New Host: Scenario
This scenario assumes the following:
Two networked machines,
hosta
andhostb
, are running LinuxA target database named
trgta
is onhosta
and uses a recovery catalogcatdb
You want to test the restore and recovery of
trgta
onhostb
, while keeping databasetrgta
up and running onhosta
The directory structure of
hostb
is different fromhosta
, so thattrgta
is located in/net/hosta/dev3/oracle/dbs
, but you want to restore the database to/net/hostb/oracle/oradata/test
Database
trgta
uses a server parameter file (not a client-side initialization parameter file)The
ORACLE_SID
for thetrgta
database istrgta
and will not change for the restored databaseYou have a record of the DBID for
trgta
A media manager is accessible by both machines
You have recoverable backups on tape of all datafiles
You have backups of the archived logs required to recover the datafiles
You have control file and server parameter file autobackups on tape
Use the following steps to perform the restore process:
Make backups of the target database available to
hostb
. To test disaster recovery, you need to have a recoverable backup of the target database. When preparing your disaster recovery strategy, ensure that the backups of the datafiles, control files, and server parameter file are restorable onhostb
. Hence, you must configure the media management software so thathostb
is a media manager client and can read the backup sets created onhosta
. Consult the media management vendor for support on this issue.Configure the
ORACLE_SID
onhostb
. This scenario assumes that you want to authenticate yourself through the operating system, which is much faster than configuring Oracle Net and creating a password file. However, you must be connected tohostb
either locally or through a SQLNet alias.While connected to hostb with administrator privileges, edit the
/etc/group
file so that you are included: in the DBA group:
dba:*:614:<your_user_name>Set the
ORACLE_SID
environment variable onhostb
to the same value used onhosta
:
% setenv ORACLE_SID trgtaStart RMAN and connect to the target instance without connecting to the recovery catalog.
% rman TARGET / NOCATALOGStart the instance without mounting it. To start the instance, you first need to set the DBID. (If you do not know the DBID for your database, see Oracle Database Backup and Recovery Basics for details on how to determine the DBID.)
Run
SET
DBID
to set the DBID, then runSTARTUP
NOMOUNT
:
SET DBID 1340752057;
STARTUP NOMOUNTRMAN will fail to find the server parameter file, which has not yet been restored, but will start the instance with a "dummy" file. Sample output follows:
startup failed: ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '/net/hostb/oracle/dbs/inittrgta.ora'
trying to start the Oracle instance without parameter files ...
Oracle instance startedRestore and edit the server parameter file.
Because you enabled the control file autobackup feature when making your backups, the server parameter file is included in the backup sets.
Allocate a channel to the media manager, then restore the server parameter file (SPFILE) as a client-side parameter file (PFILE).
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
RESTORE SPFILE TO PFILE '?/oradata/test/inittrgta.ora' FROM AUTOBACKUP;
SHUTDOWN ABORT;
}Next, edit the restored PFILE. Change any location-specific parameters, for example, those ending in
_DEST
and_PATH
, to reflect the new directory structure. For example, edit the following parameters:
- IFILE
- *_DUMP_DEST
- LOG_ARCHIVE_DEST*
- CONTROL_FILESThen restart the instance, using the edited PFILE:
STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';Restore the control file from an autobackup and then mount the database. RMAN restores the control file to whatever location you specified in the
CONTROL_FILES
initialization parameter. For example:
RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
}Query the database filenames recorded in the control file on the new host (
hostb
). Because the control file is from the trgta database, the recorded filenames use the original hosta filenames. You can queryV$
views to obtain this information. Start a new SQL*Plus session and connect to the newly created instance on hostb:
% sqlplus '/ AS SYSDBA'Run the following query in SQL*Plus:
SQL> COLUMN NAME FORMAT a60
SQL> SPOOL LOG 'db_filenames.out'
SQL> SELECT FILE# AS "File/Grp#", NAME FROM V$DATAFILE
uni-on
SELECT GROUP#,MEMBER FROM V$LOGFILE;
SQL> SPOOL OFF
SQL EXITWrite the RMAN recovery script. The script must include the following steps:
For each datafile on the destination host that is restored to a different path than it had on the source host, use a
SET
NEWNAME
command to specify the new path on the destination host. (If the file systems on the destination system are set up to have the same paths as the source host, then do not use SET NEWNAME for those files restored to the same path as on the source host.)
For each online redo log that is to be created at a different location than it had on the source host, use SQL
ALTER
DATABASE
RENAME
FILE
commands to specify the pathname on the destination host. (If the file systems on the destination system are set up to have the same paths as the source host, then do not use ALTER DATABASE RENAME FILE for those files restored to the same path as on the source host.)Perform a
SET UNTIL
to limit media recovery to the end of the archived redo logs.Run
SWITCH
so that the control file recognizes the new path names as the official new names of the datafilesRestore and recover the database
For example, consider the following RMAN script to perform these steps, which is contained in text file
reco_test.rman
:
RUN
{
# allocate a channel to the tape device
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
# rename the datafiles and online redo logs
SET NEWNAME FOR DATAFILE 1 TO '?/oradata/test/system01.dbf';
SET NEWNAME FOR DATAFILE 2 TO '?/oradata/test/undotbs01.dbf';
SET NEWNAME FOR DATAFILE 3 TO '?/oradata/test/cwmlite01.dbf';
SET NEWNAME FOR DATAFILE 4 TO '?/oradata/test/drsys01.dbf';
SET NEWNAME FOR DATAFILE 5 TO '?/oradata/test/example01.dbf';
SET NEWNAME FOR DATAFILE 6 TO '?/oradata/test/indx01.dbf';
SET NEWNAME FOR DATAFILE 7 TO '?/oradata/test/tools01.dbf';
SET NEWNAME FOR DATAFILE 8 TO '?/oradata/test/users01.dbf';
SQL "ALTER DATABASE RENAME FILE ''/dev3/oracle/dbs/redo01.log''
TO ''?/oradata/test/redo01.log'' ";
SQL "ALTER DATABASE RENAME FILE ''/dev3/oracle/dbs/redo02.log''
TO ''?/oradata/test/redo02.log'' ";
# Do a SET UNTIL to prevent recovery of the online logs
SET UNTIL SCN 123456;
# restore the database and switch the datafile names
RESTORE DATABASE;
SWITCH DATAFILE ALL;
# recover the database
RECOVER DATABASE;
}
EXITOnline logs and datafiles are relocated as specified,
For example, connect and execute the script as shown here:
% rman TARGET / NOCATALOG
RMAN> @reco_test.rmanRMAN will apply as many of the archived redo logs as it can and leave the database in a state in which is can be opened.
Now perform an OPEN RESETLOGS at the restored database.
Caution:
When you re-open your database in the next step, do not connect to the recovery catalog. Otherwise, the new database incarnation created is registered automatically in the recovery catalog, and the filenames of the production database are replaced by the new filenames specified in the script.If this is a test restore, never connect RMAN to the test-restore database and the recovery catalog.
From the RMAN prompt, open the database with the
RESETLOGS
option:
RMAN> ALTER DATABASE OPEN RESETLOGS;If this was a test restore, and it was successful, then you can shut down the test database instance, and delete the test database with all of its files. Use the DROP DATABASE command to delete all files associated with the database automatically.
Note:
If you used an ASM disk group, then DROP DATABASE is the only way to safely remove the files of the test database. If you restored to non-ASM storage then you can also use operating system commands to remove the database.
RMAN> SHUTDOWN ABORT
RMAN> EXITRemove all test files. You can do this with an operating system utility or in RMAN. For example, in Unix you could perform the procedure this way:
% rm $ORACLE_HOME/oradata/test/*You can also use RMAN for a procedure that works on all platforms. For example:
RMAN> STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';
RMAN> DROP DATABASE;Because you did not perform the restore and recovery when connected to the recovery catalog, the recovery catalog contains no records for any of the restored files or the procedures performed during the test. Likewise, the control file of the
trgta
database is completely unaffected by the test.
Performing Recovery with a Backup Control File
If all copies of the current control file are lost or damaged, then you must restore and mount a backup control file before you can perform recovery. When using a backup control file, and using a recovery catalog, the process is identical to recovery with a current control file, as the RMAN repository information missing from the backup control file is available from the recovery catalog. There are special considerations when using a backup controlfile and not using a recovery catalog.
The following notes and restrictions apply regardless of whether you use a recovery catalog:
You must run the
RECOVER
command after restoring a backup control file, even if no datafiles have been restored.You must open the database with the
RESETLOGS
option after performing either complete or point-in-time recovery with a backup control file.If the online redo logs are inaccessible, then you must perform incomplete recovery to an SCN before the earliest SCN in the online redo logs. This limitation is necessary because RMAN does not back up online logs.
During recovery, RMAN automatically searches for online and archived redo logs that are not recorded in the RMAN repository, and catalogs any that it finds so that it can use them in recovery.
RMAN attempts to find a valid archived log in any of the current archiving destinations with the current log format. The current format is specified in the initialization parameter file used to start the instance (or all instances in a Real Application Clusters installation). Similarly, RMAN attempts to find the online redo logs by using the filenames as specified in the control file.
If you changed the archiving destination or format during recovery, or if you added new online log members after the backup of the control file, then RMAN may not be able to automatically catalog a needed online or archived log. In this situation, RMAN reports errors similar to the following:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/29/2001 14:23:09
RMAN-06054: media recovery requesting unknown log: thread 1 scn 86945In this case, you must use the
CATALOG
command to manually add the required logs to the repository so that recovery can proceed. The cataloging procedure is described in Oracle Database Backup and Recovery Basics.
Performing Recovery with a Backup Control File and No Recovery Catalog: Scenario
This section assumes that you have RMAN backups of the control file, but do not use a recovery catalog.
Assuming that you enabled the control file autobackup feature for the target database, you can restore an autobackup of the control file. Because the autobackup uses a default format, RMAN can restore it even though it does not have a repository available that lists the available backups. You can restore the autobackup to the default or a new location. RMAN replicates the control file to all CONTROL_FILES
locations automatically.
Note:
RESTORE
CONTROLFILE
FROM
'filename'
command. The server records the location of every autobackup in the alert log.Because you are not connected to a recovery catalog, the RMAN repository contains only information about available backups at the time of the control file backup. If you know the location of other usable backup sets or image copies, add them to the control file RMAN repository with the CATALOG
command.
Because the repository is not available when you restore the control file, you must use the SET
DBID
command to identify the target database. The DBID is used to determine the location of control file autobackups. Use SET
DBID
command only in the following special circumstances:
You are not connected to a recovery catalog and want to restore the control file or server parameter file.
You are connected to a recovery catalog and want to restore the control file, but the database name is not unique in the recovery catalog.
The server parameter file is lost and you want to restore it.
To recover the database with an autobackup of the control file without a recovery catalog:
Start RMAN and connect to the target database. For example, run:
CONNECT TARGET /Start the target instance without mounting the database. For example:
STARTUP NOMOUNT;Set the database identifier for the target database with
SET
DBID
. RMAN displays the DBID whenever you connect to the target. You can also obtain it by inspecting saved RMAN log files, querying the catalog, or looking at the filenames of control file autobackup. (refer to "Restoring Control File When Databases in the Catalog Have the Same Name: Example"). For example, run:
SET DBID 676549873;Restore the autobackup control file, then perform recovery. Do the following:
Optionally, specify the most recent backup time stamp that RMAN can use when searching for a control file autobackup to restore.
If you know that a different control file autobackup format was in effect when the control file autobackup was created, then specify a nondefault format for the restore of the control file.
If the channel that created the control file autobackup was device type
sbt
, then you must allocate one or moresbt
channels. Because no repository is available, you cannot use preconfigured channels.Restore the autobackup of the control file, optionally setting the maximum number of days backward that RMAN can search (up to 366) and the initial sequence number that it should use in its search for the first day.
If you know that your control file contained information about configured channels that will be useful to you in the rest of the restore process, you can exit the RMAN client at this point, to clear manually allocated channels from step "c". If you then restart the RMAN client and mount the database those configured channels become available for your use in the rest of the restore and recovery process.
If you do not care about using configured channels from your control file, then you can simply mount the database at this point.
If the online logs are usable, then perform a complete restore and recovery as described in Oracle Database Backup and Recovery Basics.
Otherwise, restore and perform incomplete recovery of the database, as described in Oracle Database Backup and Recovery Basics Use an
UNTIL
clause to specify a target time , SCN or log sequence number for the recovery prior to the first SCN of the online redo logs.
In this example, the online redo logs have been lost, and the most recent archived log sequence number is 13243. This example shows how to restore the control file autobackup, then performs recovery of the database to log sequence 13243.
RUN
{
# Optionally, set upper limit for eligible time stamps of control file
# backups
# SET UNTIL TIME '09/10/2000 13:45:00';
# Specify a nondefault autobackup format only if required
# SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK
# TO '?/oradata/%F.bck';
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...'; # allocate manually
RESTORE CONTROLFILE FROM AUTOBACKUP
MAXSEQ 100 # start at sequence 100 and count down
MAXDAYS 180; # start at UNTIL TIME and search back 6 months
ALTER DATABASE MOUNT DATABASE;
}
# uses automatic channels configured in restored control file
RESTORE DATABASE UNTIL SEQUENCE 13243;
RECOVER DATABASE UNTIL SEQUENCE 13243; # recovers to latest archived logIf recovery was successful, then open the database and reset the online logs:
ALTER DATABASE OPEN RESETLOGS;
Performing Disaster Recovery
Disaster recovery includes the restore of and recovery of the target database after the loss of the entire target database, the recovery catalog database, all current control files, all online redo log files, and all parameter files.
To perform a disaster recovery, the minimum required set of backups is backups of some datafiles, some archived redo logs generated after the time of the backup, and at least one autobackup of the control file.
The basic procedure for disaster recovery begins with restoring an autobackup of the server parameter file, as described in Oracle Database Backup and Recovery Basics.
Once you have an SPFILE, you can start the target database instance, restore the control file from autobackup and mount it.
With the control file mounted, then follow the instructions found in
"Performing Recovery with a Backup Control File" to restore and recover your datafiles.
Note:
If you are restoring to a new host, you should review the considerations described in "Restore and Recovery of the Database on a New Host".The following scenario restores and recovers the database to the most recently available archived log, which in this example is log 1124 in thread 1. It assumes that:
You are restoring the database to a new host with the same directory structure.
You have one tape drive containing backups of all the datafiles and archived redo logs through log 1124, as well as autobackups of the control file and server parameter file.
You do not use a recovery catalog.
In this scenario, perform the following steps:
If possible, restore all relevant network files such as
tnsnames.ora
andlistener.ora
by means of operating system utilities.Start RMAN and connect to the target database. If you do not have the Oracle Net files, then connect using operating system authentication.
Specify the DBID for the target database with the
SET
DBID
command, as described in "Performing Recovery with a Backup Control File and No Recovery Catalog: Scenario".Run the
STARTUP
NOMOUNT
command. RMAN attempts to start the instance with a dummy server parameter file.Allocate a channel to the media manager and then run the
RESTORE
SPFILE
FROM
AUTOBACKUP
command.Run
STARTUP
FORCE
NOMOUNT
mode so that the instance is restarted with the restored server parameter file.Allocate a channel to the media manager and then restore a control file autobackup (refer to
"Performing Recovery with a Backup Control File and No Recovery Catalog: Scenario").Mount the restored control file.
Catalog any backups not recorded in the repository with the
CATALOG
command (refer to "Removing DELETED Records From the Recovery Catalog After Upgrade").Restore the datafiles to their original locations. If volume names have changed, then run
SET
NEWNAME
commands before the restore and perform a switch after the restore to update the control file with the new locations for the datafiles (refer to "Performing Disaster Recovery").Recover the datafiles. RMAN stops recovery when it reaches the log sequence number specified.
Open the database in
RESETLOGS
mode. Only complete this last step if you are certain that no other archived logs can be applied.
# Start RMAN and connect to the target database
% rman TARGET SYS/oracle@trgt
# Set the DBID for the target database
RMAN> SET DBID 676549873;
RMAN> STARTUP FORCE NOMOUNT; # rman starts instance with dummy parameter file
RUN
{
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE SPFILE FROM AUTOBACKUP;
}
# Restart instance with restored server parameter file
RMAN> STARTUP FORCE NOMOUNT;
RMAN> RUN
{
# Manually allocate a channel to the media manager
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
# Restore autobackup of the control file. This example assumes that you have
# accepted the default format for the autobackup name.
RESTORE CONTROLFILE FROM AUTOBACKUP;
# The set until command is used in case the database
# structure has changed in the most recent backups, and you wish to
# recover to that point-in-time. In this way RMAN restores the database
# to the same structure that the database had at the specified time.
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 1124 THREAD 1;
RESTORE DATABASE;
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS; # Reset the online logs after recovery completes
The following example of the RUN
command shows the same scenario except with new filenames for the restored datafiles:
RMAN> RUN
{
# If you need to restore the files to new locations, tell Recovery Manager
# to do this using SET NEWNAME commands:
SET NEWNAME FOR DATAFILE 1 TO '/dev/vgd_1_0/rlvt5_500M_1';
SET NEWNAME FOR DATAFILE 2 TO '/dev/vgd_1_0/rlvt5_500M_2';
SET NEWNAME FOR DATAFILE 3 TO '/dev/vgd_1_0/rlvt5_500M_3';
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
RESTORE CONTROLFILE FROM AUTOBACKUP;
ALTER DATABASE MOUNT;
SET UNTIL SEQUENCE 124 THREAD 1;
RESTORE DATABASE;
SWITCH DATAFILE ALL; # Update control file with new location of datafiles.
RECOVER DATABASE;
}
RMAN> ALTER DATABASE OPEN RESETLOGS;
Performing Block Media Recovery with RMAN
The BLOCKRECOVER
command can restore and recover individual datablocks within a datafile. This procedure is useful when a trace file or standard output reveals that a small number of blocks within a datafile are corrupt.
Block media recovery is not useful in cases where the extent of data loss or corruption is not known; in this case, use datafile recovery instead.
See Also:
"Block Media Recovery with RMAN" for an overview of block media recovery,
Oracle Database Backup and Recovery Reference for
BLOCKRECOVER
syntaxOracle Database Reference for details about the
$DATABASE_BLOCK_CORRUPTION
view
Block Media Recovery Using All Available Backups
In this scenario, you identify the blocks that require recovery and then use any available backup to perform the restore and recovery of these blocks.
To recover datablocks by using all available backups:
Obtain the datafile numbers and block numbers for the corrupted blocks. Typically, you obtain this output from the standard output, the
alert.log
, trace files, or a media management interface. For example, you may see the following in a trace file:
ORA-01578: ORACLE data block corrupted (file # 8, block # 13)
ORA-01110: data file 8: '/oracle/oradata/trgt/users01.dbf'
ORA-01578: ORACLE data block corrupted (file # 2, block # 19)
ORA-01110: data file 2: '/oracle/oradata/trgt/undotbs01.dbf'Assuming that you have preallocated automatic channels, run the
BLOCKRECOVER
command at the RMAN prompt, specifying the file and block numbers for the corrupted blocks as in the following example:
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19;
Block Media Recovery Using Specific Backups
In this scenario, you identify the blocks that require recovery, and then use only selected backups to perform the restore and recovery of these blocks.
To recover datablocks while limiting the type of backup:
Obtain the datafile numbers and block numbers for the corrupted blocks. Typically, you obtain this output from the standard output, the
alert.log
, trace files, or a media management interface. For example, you may see the following in a trace file:
ORA-01578: ORACLE data block corrupted (file # 8, block # 13)
ORA-01110: data file 8: '/oracle/oradata/trgt/users01.dbf'
ORA-01578: ORACLE data block corrupted (file # 2, block # 19)
ORA-01110: data file 2: '/oracle/oradata/trgt/undotbs01.dbf'Assuming that you have preallocated automatic channels, execute the
BLOCKRECOVER
command at the RMAN prompt, specifying the file and block numbers for the corrupted blocks and limiting the backup candidates by means of the available options. For example, you can specify what type of backup should be used to restore the blocks:
# restore from backupset
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19 FROM BACKUPSET;
# restore from datafile image copy
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19
FROM DATAFILECOPY;You can indicate the backup by specifying a tag:
# restore from backupset with tag "mondayam"
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 199
FROM TAG = mondayam;You can limit the backup candidates to those made before a certain point:
# restore using backups made before one week ago
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19
RESTORE UNTIL 'SYSDATE-7';
# restore using backups made before SCN 100
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19
RESTORE UNTIL SCN 100;
# restore using backups made before log sequence 7024
RMAN> BLOCKRECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19
RESTORE UNTIL SEQUENCE 7024;
Note that if you limit the restore of datablocks with the UNTIL
clause, then RMAN must perform more recovery on the blocks, and the recovery phase must scan all logs for changes to the specified blocks.
Block Media Recovery of Blocks Listed in V$DATABASE_BLOCK_CORRUPTION
The V$DATABASE_BLOCK_CORRUPTION
view indicates which blocks in a datafile were marked corrupt since the most recent BACKUP
or BACKUP
VALIDATE
command was run. After a corrupt block is repaired, the row identifying this block is deleted from the view.
You can check for logical corruption in the database by running the BACKUP
(with or without VALIDATE
option) with the CHECK
LOGICAL
command. If RMAN finds corrupt blocks, then it populates V$DATABASE_BLOCK_CORRUPTION
. The backup will stop if the number of corrupt blocks exceeds MAXCORRUPT
. A historical record of block corruptions in RMAN backups is kept in V$BACKUP_CORRUPTION
and V$COPY_CORRUPTION
.
In this scenario, you identify the blocks that require recovery by querying V$DATABASE_BLOCK_CORRUPTION
, and then instruct RMAN to recover all blocks listed in this view by means of the CORRUPTION
LIST
keyword.
To recover datablocks while limiting the type of backup:
Query
V$DATABASE_BLOCK_CORRUPTION
to determine whether corrupt blocks exist in the most recent backups of the datafiles:
SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION;Assuming that you have preallocated automatic channels, recover all blocks marked corrupt in
V$DATABASE_BLOCK_CORRUPTION
by running theBLOCKRECOVER
CORRUPTION
LIST
command. For example, this command restores blocks from backups created more than 10 days ago:
BLOCKRECOVER CORRUPTION LIST
RESTORE UNTIL TIME 'SYSDATE-10';
See Oracle Database Backup and Recovery Reference for more details on block media recovery in RMAN.
RMAN Restore and Recovery Examples
The following sections illustrate the use of RMAN restore and recovery techniques in advanced scenarios.
Restoring Datafile Copies to a New Host: Example
To move the database to a new host by means of datafile copies, you must transfer the copies manually to the new machine. This example assumes that you are using a recovery catalog.
After connecting to the target database and recovery catalog, run a
LIST
command to see a listing of datafile copies and their associated primary keys, as in the following example:
LIST COPY;Copy the datafile copies to the new host with an operating system utility. For example, in UNIX:
% cp -r /tmp/*dbf /net/new_host/oracle/oradata/trgtStart RMAN and then uncatalog the datafile copies on the old host. For example, enter:
CHANGE COPY OF DATAFILE 1,2,3,4,5,6,7,8 UNCATALOG;Catalog the datafile copies, using their new filenames or
CATALOG START
WITH
(if you know all the files are in directories with a common prefix easily addressed with aCATALOG START WITH
). For example, run:
CATALOG START WITH '?/oradata/trgt/';Or this example specifies files individually:
CATALOG DATAFILECOPY
'?/oradata/trgt/system01.dbf', '?/oradata/trgt/undotbs01.dbf',
'?/oradata/trgt/cwmlite01.dbf', '?/oradata/trgt/drsys01.dbf',
'?/oradata/trgt/example01.dbf', '?/oradata/trgt/indx01.dbf',
'?/oradata/trgt/tools01.dbf', '?/oradata/trgt/users01.dbf';Perform the restore and recovery operation described in "Performing Disaster Recovery".
Restoring Control File When Databases in the Catalog Have the Same Name: Example
When using a recovery catalog and attempting to restore a lost control file, you encounter an error if there are other databases are registered in the recovery catalog with the same name as your target database.
To resolve this error, you must uniquely identify the database by DBID for the restore operation. This requires determining the correct DBID for your database, and then using the SET
DBID
command to identify the target database before the RESTORE
CONTROLFILE
command, as shown in the following example:
Start RMAN and connect to the target database.
Run the
STARTUP
FORCE
NOMOUNT
command.Run the
SET
DBID
command to distinguish this connected target database from other target databases that have the same name.Run the
RESTORE
CONTROLFILE
command. After restoring the control file, you can mount the database to restore the rest of the database.
See Also:
Oracle Database Backup and Recovery Reference for more details on the use ofSET
DBID.
Restoring a Backup Control File By Using the DBID
To set the DBID, connect RMAN to the target database and run the following SET
command, where target_dbid
is the value you obtained from the previous step:
SET DBID = target_dbid;
To restore the control file to its default location and then mount it, run:
RESTORE CONTROLFILE;
ALTER DATABASE MOUNT;
To restore and recover the database, run:
RESTORE DATABASE;
RECOVER DATABASE
# optionally, delete logs restored for recovery and limit disk space used
DELETE ARCHIVELOG MAXSIZE 2M;
Recovering a Lost Datafile Without a Backup: Example
RMAN can handle lost datafiles without user intervention during restore and recovery. When a datafile is lost, the possible cases can be classified as follows:
The control file knows about the datafile, that is, the user backed up the control file after datafile creation, but the datafile itself is not backed up. If the datafile record is in the control file, then
RESTORE
creates the datafile in the original location or in a user-specified location (for example, withSET
NEWNAME
). TheRECOVER
command can then apply the necessary logs to the datafile.The control file does not have the datafile record, that is, the user did not back up the control file after datafile creation. During recovery, the database will detect the missing datafile and report it to RMAN, which will create a new datafile and continue recovery by applying the remaining logs. If the datafile was created in a parent incarnation, it will be created during restore or recover as appropriate.
In this example, the following sequence of events occurs:
You make a whole database backup of your
ARCHIVELOG
mode database.You create a tablespace
history
containing a single datafile called/mydb/history01.dbf
.You populate the newly created datafile with data.
You archive all the active online redo logs.
A user accidentally deletes the datafile
history01.dbf
from the operating system before you have a chance to back it up.
In this case, the current control file knows about the datafile. To restore and recover the datafile, start RMAN, connect to the target database, and then enter the following commands at the RMAN prompt:
# take the tablespace with the missing datafile offline
SQL "ALTER TABLESPACE history OFFLINE IMMEDIATE";
# restore the tablespace even though you have no backup
RESTORE TABLESPACE history;
# recover tablespace
RECOVER TABLESPACE history;
# bring the recovered tablespace back online
SQL "ALTER TABLESPACE history ONLINE";