Release 8.1.5
A67773-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Backup and Recovery Guide Release 8.1.5 A67773-01 |
|
This chapter describes how to use Recovery Manager to perform restore and recovery operations, and includes the following topics:
Use the RMAN restore command to restore datafiles, control files, or archived redo logs from backup sets or image copies. RMAN restores backups from disk or tape, but image copies only from disk.
When restoring files, you should:
Restore files to either:
This section contains the following topics:
See Also: For restore syntax, see "restore". For set newname syntax, see "set_run_option".
When restoring a target database, you can:
To restore the database to its default location, issue the restore database command. To move your target database to a new host, rename the datafiles as needed using set newname. To create a test database using backups of your target database, use the duplicate command (see Chapter 10, "Creating a Duplicate Database with Recovery Manager" for complete instructions).
This chapter contains the following topics:
If you do not specify set newname commands for the datafiles during a restore job, the database must be closed or the datafiles must be offline. Otherwise, you will see output similar to the following, which results from an attempt to restore datafile 3 while the file is online:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure during compilation of command RMAN-03013: command type: restore RMAN-03006: non-retryable error occurred during execution of command: IRESTORE RMAN-07004: unhandled exception during command execution on channel ch1 RMAN-10035: exception raised in RPC: ORA-19573: cannot obtain exclusive enqueue for datafile 3 ORA-19600: input file is datafile-copy 102 (/vobs/oracle/dbs/df.3) ORA-19601: output file is datafile 3 (/vobs/oracle/dbs/tbs_11.f) RMAN-10031: ORA-19573 occurred during call to DBMS_BACKUP_RESTORE.COPYDATAFILECOPY
The database must be closed when you restore the whole database. If the target database is mounted, then its control file will be updated with any applicable datafile copy and archived log records to describe the restored files.
% rman target / catalog rman/rman@rcat
shutdown immediate; startup mount;
run { allocate channel ch1 type disk; allocate channel ch2 type disk; allocate channel ch3 type disk; restore database; }
A media failure may force you to move a database by restoring a backup from one host to another. Note that if you want to create a duplicate database for testing and still maintain your original database, use the duplicate command instead of following this procedure (see Chapter 10, "Creating a Duplicate Database with Recovery Manager").
Because your restored database will not have the online redo logs of your production database, you will need to perform incomplete recovery up to the lowest SCN of the most recently archived redo log in each thread and then open with the RESETLOGS option.
This scenario assumes that:
The restore procedure differs depending on whether the target database uses a recovery catalog.
init.ora file for HOST_A to HOST_B using an O/S utility.
% rman target sys/change_on_install@host_b rman/rman@rcat
startup nomount;
Start SQL*Plus and use the following query to determine the necessary SCN:
SELECT min(scn) FROM (SELECT max(next_change#) scn FROM v$archived_log GROUP BY thread#);
run { set until scn = 500; # use appropriate SCN for incomplete recovery allocate channel ch1 type 'sbt_tape'; restore database; recover database; sql "ALTER DATABASE OPEN RESETLOGS"; }
init.ora file for HOST_A to HOST_B using an O/S utility.
% rman target sys/change_on_install@host_b nocatalog
startup mount;
Start SQL*Plus and use the following query to determine the necessary SCN:
SELECT min(scn) FROM (SELECT max(next_change#) scn FROM v$archived_log GROUP BY thread#);
run { set until scn 500; # use appropriate SCN for incomplete recovery allocate channel ch1 type 'sbt_tape'; alter database mount; restore database; recover database; sql "ALTER DATABASE OPEN RESETLOGS"; }
The procedure for moving the database to a machine with a different filesystem is basically the same as described in "Recovering an Inaccessible Datafile in an Open Database"; the difference is that you need to rename each datafile using set newname.
For example, assume that:
/disk1 and others to /disk2 on HOST_B.
init.ora file that specify a pathname.
run { set until scn 500; # use appropriate SCN for incomplete recovery allocate channel ch1 type disk; set newname for datafile 1 to '/disk1/%U'; # rename each datafile manually set newname for datafile 2 to '/disk1/%U'; set newname for datafile 3 to '/disk1/%U'; set newname for datafile 4 to '/disk1/%U'; set newname for datafile 5 to '/disk1/%U'; set newname for datafile 6 to '/disk2/%U'; set newname for datafile 7 to '/disk2/%U'; set newname for datafile 8 to '/disk2/%U'; set newname for datafile 9 to '/disk2/%U'; set newname for datafile 10 to '/disk2/%U'; alter database mount; restore database; switch datafile all; # points the control file to the renamed datafiles recover database; sql "ALTER DATABASE OPEN RESETLOGS"; }
init.ora file that specify a pathname.
run { set until scn 500; # use appropriate SCN for incomplete recovery allocate channel ch1 type disk; set newname for datafile 1 to '/disk1/%U'; # rename each datafile manually set newname for datafile 2 to '/disk1/%U'; set newname for datafile 3 to '/disk1/%U'; set newname for datafile 4 to '/disk1/%U'; set newname for datafile 5 to '/disk1/%U'; set newname for datafile 6 to '/disk2/%U'; set newname for datafile 7 to '/disk2/%U'; set newname for datafile 8 to '/disk2/%U'; set newname for datafile 9 to '/disk2/%U'; set newname for datafile 10 to '/disk2/%U'; restore database; switch datafile all; # point control file to renamed datafiles recover database; sql "ALTER DATABASE OPEN RESETLOGS"; }
If a datafile is lost or corrupted but the disk is accessible, then you can restore the datafile to its previous location. Simply take the tablespace offline and issue a restore tablespace command. If the old location is inaccessible, take the tablespace offline and restore the associated datafiles to a new location.
If you cannot restore datafiles to the default location, use the set newname command before restoring. In this case, Oracle considers the restored datafiles as datafile copies; perform a switch to make them the current datafiles. Oracle creates the filename or overwrites it if it already exists.
The RMAN switch command is equivalent to the ALTER DATABASE RENAME DATAFILE statement. Note that a switch effectively causes the location of the current datafile to change. Also note that switching "consumes" the copy, i.e., deletes the corresponding records in the recovery catalog and the control file.
If you do not specify the target of the switch, then the filename specified in a prior set newname for this file number is used as the switch target. If you specify switch datafile all, then all datafiles for which a set newname has been issued in this job are switched to their new name.
If you issue set newname commands to restore datafiles to a new location with the intention of performing a recovery afterwards, perform a switch after restoring but before recovering to make the restored datafiles the current datafiles.
See Also: For switch command syntax, see "switch".
% rman target / catalog rman/rman@rcat
For example, to restore tablespace USER_DATA to disk you might issue:
run { sql 'ALTER TABLESPACE user_data OFFLINE TEMPORARY'; allocate channel ch1 type disk; restore tablespace user_data; }
% rman target / catalog rman/rman@rcat
To restore the datafiles for tablespace TBS_1 to a new location on disk, you might enter:
run { allocate channel ch1 type disk; sql 'ALTER TABLESPACE user_data OFFLINE TEMPORARY'; # restore the datafile to a new location set newname for datafile '/disk1/oracle/tbs_1.f' to '/disk2/oracle/tbs_1.f'; restore tablespace tbs_1; # make the control file recognize the restored file as current switch datafile all; }
If a media failure damages your control file and you do not have multiplexed copies, you must restore a backup. Issue restore controlfile to restore the control file to the first CONTROL_FILES location specified in the parameter file. RMAN automatically replicates the control file to all CONTROL_FILES locations specified in the parameter file.
Specify a destination name with restore controlfile to 'filename' when restoring a control file to a non-default location. If the filename already exists, then Oracle overwrites the file. When you restore the control file to a new location, use the replicate controlfile from 'filename' command to copy it the CONTROL_FILES destinations: RMAN will not replicate the control file automatically.
Using the replicate controlfile command is equivalent to using multiple copy controlfile commands. After your specify the input control file by name, RMAN replicates the file to the locations specified in the CONTROL_FILES initialization parameter of the target database.
% rman target / catalog rman/rman@rcat
startup nomount;
run { # To restore a control file created before a certain date, issue the following # set command using a valid date for 'date_string'. You can also specify an SCN # or log sequence number. # set until time = 'date_string'; allocate channel ch1 type 'sbt_tape'; restore controlfile; alter database mount; }
RMAN automatically replicates to the control file to the locations specified by the CONTROL_FILES initialization parameter.
Note that the control file that contains information about a given backup is not the control file that is backed up along with the backup. For example, if you issue backup database, the backup control file in this whole database backup does not contain the record of the whole database backup. The next control file backup will contain information about the whole database backup.
% rman target / nocatalog
startup mount;
run { # To restore a control file created before a certain date, issue the following # set command using a valid date for 'date_string'. You can also specify an SCN # or log sequence number. # set until time = 'date_string'; allocate channel ch1 type 'sbt_tape'; # restore control file to new location restore controlfile to '/oracle/dbs/cf1.ctl'; shutdown immediate; # replicate the control file manually to locations in parameter file replicate controlfile from '/oracle/dbs/cf1.ctl'; startup mount; }
See Also: For replicate controlfile command syntax, see "replicate".
RMAN restores archived redo logs with names constructed using the LOG_ARCHIVE_FORMAT parameter and either the LOG_ARCHIVE_DEST or LOG_ARCHIVE_DEST_1 parameters of the target database. These parameters combine in a port-specific fashion to derive the name of the restored archived log.
Override the destination parameter with the set archivelog destination command. By issuing this command, you can manually stage many archived logs to different locations while a database restore is occurring. During recovery, RMAN knows where to find the newly restored archived logs; it does not require them to be in the location specified in the parameter file.
For example, if you specify a different destination from the one in the init.ora file and restore backups, subsequent restore and recovery operations will detect this new location and will not look for the files in the init.ora parameter destination.
If desired, you can also specify multiple restore destinations for archived redo logs, although you cannot specify these destinations simultaneously. For example, you can issue:
run { allocate channel ch1 type disk; # Set a new location for logs 1 through 10. set archivelog destination to '/disk1/oracle/temp_restore'; restore archivelog from logseq 1 until logseq 10; # Set a new location for logs 11 through 20. set archivelog destination to '/disk1/oracle/arch'; restore archivelog from logseq 11 until logseq 20; # Set a new location for logs 21 through 30. set archivelog destination to '/disk2/oracle/temp_restore'; restore archivelog from logseq 21 until logseq 30; . . . recover database; }
Note that if you restore archived redo logs to multiple locations, you only need to issue a single recover command. RMAN finds the restored archived logs automatically and applies them to the datafiles.
% rman target / catalog rman/rman@rcat
Optionally, specify a message log file at connect time:
% rman target / catalog rman/rman@rcat log = rman_log
shutdown immediate; startup mount
For example, this job restores all backup archived redo logs:
run { # Optionally, set a new location for the restored logs. set archivelog destination to '/oracle/temp_restore'; allocate channel ch1 type disk; restore archivelog all; }
See Also: For set archivelog destination command syntax, see "set_run_option".
Use the set until command to specify the termination point for recovery. This command affects any subsequent restore, switch, and recover commands that are in the same run command.
% rman target / catalog rman/rman@rcat
Optionally, specify a message log file at connect time:
% rman target / catalog rman/rman@rcat log = rman_log
shutdown immediate; startup mount;
For example, this job restores the database in anticipation of an incomplete recovery until December 15, 1998 at 9 a.m.
run { set until time 'Dec 15 1998 09:00:00'; allocate channel ch1 type 'sbt_tape'; restore database; }
Media recovery is the application of redo logs or incremental backups to a restored file in order to update it to the current time or some other specified time. You can only recover or apply incremental backups to current datafiles, not datafile copies.
Perform media recovery when:
RMAN restores backup sets of archived redo logs as needed to perform the media recovery. By default, RMAN restores the archived redo logs to the current log archive destination specified in the init.ora file. Use the set archivelog destination command to specify a different location.
If RMAN has a choice between applying an incremental backup or applying redo, then it always chooses the incremental backup. If overlapping levels of incremental backup are available, then RMAN automatically chooses the one covering the longest period of time.
If possible, make the recovery catalog available to perform the media recovery. If it is not available, RMAN uses information from the target database control file.
This section contains the following topics:
See Also: For an overview of incremental backups, see "Incremental Backups".
When and how to recover depends on the state of the database and the location of its datafiles.
% sqlplus sys/change_on_install@prod1;
SELECT parallel, status FROM v$instance; PAR STATUS --- ------- NO OPEN
If the STATUS column reads OPEN, then the database is open, but it is still possible that you need to restore or recover some tablespaces and their datafiles.
SELECT file#, status, error, recover, tablespace_name, name FROM v$datafile_header WHERE error IS NOT NULL OR recover = 'YES';
When performing complete recovery, recover either the whole database or a subset of the database. For example, you can perform a complete recovery of a majority of your tablespaces, and then recover the remaining tablespaces later. It makes no difference if the datafiles are read-write or offline normal.
The method you use for complete recovery depends on whether the database is open or closed.
| If the database is | Then |
|---|---|
|
Closed |
Do one of the following: |
|
Open |
Do one of the following: |
The skip option is useful for avoiding recovery of tablespaces containing only temporary data or for postponing recovery of some tablespaces. The skip clause takes the datafiles in the specified tablespaces offline before starting media recovery and keeps them offline until after media recovery completes.
Issue at least one allocate channel command before you issue the recover command unless you do not need to restore archived redo log or incremental backup sets. Allocate the appropriate type of device for the backup sets that you want to restore. If the appropriate type of storage device is not available, then the recover command will fail.
The procedure for performing complete recovery on the database differs depending on whether the control file is available.
% rman target / catalog rman/rman@rcat
shutdown immediate; startup mount;
run { allocate channel ch1 type disk; restore database; recover database skip tablespace temp; }
RMAN-08055 in the output:
RMAN-08024: channel ch1: restore complete RMAN-03023: executing command: partial resync RMAN-08003: starting partial resync of recovery catalog RMAN-08005: partial resync complete RMAN-03022: compiling command: recover RMAN-03022: compiling command: recover(1) RMAN-03022: compiling command: recover(2) RMAN-03022: compiling command: recover(3) RMAN-03023: executing command: recover(3) RMAN-08054: starting media recovery RMAN-08515: archivelog filename=/oracle/arc_dest/arcr_1_40.arc thread=1 sequence=40 RMAN-08515: archivelog filename=/oracle/arc_dest/arcr_1_41.arc thread=1 sequence=41 RMAN-08055: media recovery complete RMAN-03022: compiling command: recover(4) RMAN-08031: released channel: ch1
When you perform a restore operation using a backup control file and you use a recovery catalog, RMAN automatically adjusts the control file to reflect the structure of the restored backup.
% rman target / catalog rman/rman@rcat
startup nomount;
run { allocate channel ch1 type 'sbt_tape'; restore controlfile; alter database mount; restore database; recover database; sql "ALTER DATABASE OPEN RESETLOGS"; }
reset database;
run { allocate channel ch1 type 'sbt_tape'; backup database; }
The procedure for recovery tablespaces depends on whether the database is open or closed and whether the default tablespace location is accessible.
% rman target / catalog rman/rman@rcat
run { allocate channel ch1 type disk; restore tablespace tbs_3; recover tablespace tbs_3; }
% rman target / catalog rman/rman@rcat
run { allocate channel ch1 type disk; set newname for datafile '/disk1/oracle/tbs_1.f' to '/disk2/oracle/tbs_1.f'; restore tablespace tbs_1; switch datafile all; recover tablespace tbs_1; }
If a datafile is lost or corrupted but the disk is accessible, restore the datafile to its default location.
% rman target / catalog rman/rman@rcat
run { sql 'ALTER TABLESPACE user_data OFFLINE TEMPORARY'; allocate channel ch1 type disk; set archivelog destination to '/oracle/temp/arcl_restore'; restore tablespace user_data; recover tablespace user_data; sql 'ALTER TABLESPACE user_data ONLINE'; }
If a tablespace or datafile is inaccessible because of media failure, restore the datafile to a new location or switch to an existing datafile copy.
% rman target / catalog rman/rman@rcat
run { sql 'ALTER TABLESPACE user_data OFFLINE IMMEDIATE'; allocate channel ch1 type disk; set newname for datafile '/disk1/oracle/tbs_1.f' to '/disk2/oracle/tbs_1.f'; restore tablespace tbs_1; switch datafile all; recover tablespace tbs_1; sql 'ALTER TABLESPACE tbs_1 ONLINE'; }
RMAN allows you to perform recovery of the whole database to a specified non-current time, SCN, or log sequence number. This type of recovery is called incomplete recovery; if it is recovery of the whole database, it is sometimes called database point-in-time recovery (DBPITR).
Incomplete recovery differs in several ways from complete recovery. The most important difference is that incomplete recovery requires you to open the database with the RESETLOGS option. Using this option gives the online redo logs a new timestamp and SCN, thereby eliminating the possibility of corrupting your datafiles by the application of obsolete archived redo logs.
Because you must open RESETLOGS after performing incomplete recovery, you have to recover all datafiles. You cannot recover some datafiles before the RESETLOGS and others after the RESETLOGS. In fact, Oracle will prevent you from resetting the logs if a datafile is offline. The only exception is if the datafile is offline normal or read-only. You can bring files in read-only or offline normal tablespaces online after the RESETLOGS because they do not need any redo applied to them.
The easiest way to perform database point-in-time recovery (DBPITR) is to use the set until command, which sets the desired time for any subsequent restore, switch, and recover commands in the same run job. Note that if you specify a set until command after a restore and before a recover, you may not be able to recover the database to the point in time required, since the restored files may already have timestamps more recent than the set time. Hence, it is usually best to specify the set until command before the restore or switch command.
See Also: For set until command syntax, see "untilClause".
The database must be closed to perform database point-in-time recovery. Note that if you are recovering to a time, you should set the time format environment variables before invoking RMAN (see "Setting NLS Environment Variables"). For example, enter:
NLS_LANG=american NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS'
% rman target / catalog rman/rman@rcat
Optionally, specify a log file at connect time:
% rman target / catalog rman/rman@rcat log = rman_log
shutdown immediate; startup mount;
For example, this job performs an incomplete recovery until Nov 15 at 9 a.m.
run { set until time 'Nov 15 1998 09:00:00'; allocate channel ch1 type 'sbt_tape'; restore database; recover database; sql 'ALTER DATABASE OPEN RESETLOGS'; }
reset database;
run { allocate channel ch1 type 'sbt_tape'; backup database; }
% rman target / catalog rman/rman@rcat
Optionally, specify a message log file at connect time:
% rman target / catalog rman/rman@rcat log = rman_log
shutdown immediate; startup mount;
For example, this job performs an incomplete recovery until SCN 1000.
run { set until scn 1000; allocate channel ch1 type 'sbt_tape'; restore database; recover database; sql 'ALTER DATABASE OPEN RESETLOGS'; }
reset database;
run { allocate channel ch1 type 'sbt_tape'; backup database; }
% rman target / catalog rman/rman@rcat
Optionally, specify a message log file at connect time:
% rman target / catalog rman/rman@rcat log = rman_log
shutdown immediate; startup mount;
RECID STAMP THREAD# SEQUENCE# FIRST_CHAN FIRST_TIM NEXT_CHANG ---------- ---------- ---------- ---------- ---------- --------- ---------- 1 344890611 1 1 20037 24-SEP-98 20043 2 344890615 1 2 20043 24-SEP-98 20045 3 344890618 1 3 20045 24-SEP-98 20046 4 344890621 1 4 20046 24-SEP-98 20048 5 344890624 1 5 20048 24-SEP-98 20049 6 344890627 1 6 20049 24-SEP-98 20050 7 344890630 1 7 20050 24-SEP-98 20051 8 344890632 1 8 20051 24-SEP-98 20052 8 rows selected.
For example, this job performs an incomplete recovery until log sequence number 6 on thread 1:
run { set until logseq 6 thread 1; allocate channel ch1 type 'sbt_tape'; restore database; recover database; sql 'ALTER DATABASE OPEN RESETLOGS'; }
reset database;
run { allocate channel ch1 type 'sbt_tape'; backup database; }
Although you can perform DBPITR without a recovery catalog, be sure to follow these directions:
Make a backup of the control file after your RMAN database backups because you need a backup control file that contains information about the database backup that you just made. Even if your database backup included backing up the control file, as it does if you back up datafile 1 or specify include current controlfile, the backup control file contained in the backup set is not self-referential. Consider this command:
backup database;
This command produces a backup set that contains a backup of the control file. The backup control file does not contain any record for the backup set in which it is itself contained. Consequently, if you restore this backup control file and then mount it, you will not be able to restore files out of the backup set since the control file has no record of them.
To back up the control file separately, issue the following sequence of commands within your run command:
backup database; backup current controlfile; # obtain a useful control file backup.
These commands will create two backup sets, each of which contains a backup control file. The control file backup created by the second command will be the useful one, i.e., it will contain all the records related to the database backup.
% rman target / nocatalog
startup force mount;
If you saved all the RMAN output as suggested, then you can verify that the backup control file that RMAN picked was the correct one. Alternatively, you can use the tag option on the backup current controlfile command, and then specify this tag on the restore to force RMAN to pick the control file you want.
For example, issue the following command to restore the control file to a temporary location:
run { set until time 'Jun 18 1998 16:32:36'; allocate channel ch1 type disk; # restore a backup controlfile to a temporary location. restore controlfile to '/tmp/cf.tmp'; }
Verify that the control file that RMAN restored was one created via the backup current controlfile command that followed all backups. Alternatively, if you specified a tag on the backup current controlfile command, specify the from tag option on the restore controlfile command.
run { allocate channel ch1 type disk; # save a copy of the current controlfile just to be safe copy current controlfile to '/tmp/original.cf'; shutdown immediate; startup nomount; replicate controlfile from '/tmp/cf.tmp'; alter database mount; }
run { set until time 'Jun 18 1998 16:32:36'; restore database; recover database noredo; sql 'ALTER DATABASE OPEN RESETLOGS'; }
reset database;
run { allocate channel ch1 type disk; backup database; }
Following are useful scenarios for performing restore and recovery operations:
If you wish to move the database to a new host using datafile copies, you must transfer the copies manually to the new machine. This example assumes that you are using a recovery catalog.
list copy;
% cp -r /oracle/copies /net/new_host/oracle/dbs
change datafile copy 1,2,3,4,5,6,7,9,10 uncatalog;
catalog datafilecopy '/oracle/dbs/tbs_1.f', '/oracle/dbs/tbs_2.f', '/oracle/dbs/tbs_3.f', '/oracle/dbs/tbs_4.f', '/oracle/dbs/tbs_5.f', '/oracle/dbs/tbs_6.f', '/oracle/dbs/tbs_7.f', '/oracle/dbs/tbs_8.f', '/oracle/dbs/tbs_9.f', '/oracle/dbs/tbs_10.f';
The database identifier is a 32-bit number that is computed when the database is created. If you want to restore a database that shares a name with another database, you must distinguish it. Use the RMAN set dbid command to specify a database according to its database identifier.
If you have saved your RMAN output, refer to this information to determine the database identifier, since RMAN automatically provides it whenever you connect to the database:
% rman target / Recovery Manager: Release 8.1.5.0.0 RMAN-06005: connected to target database: RMAN (DBID=1231209694)
If you have not saved your RMAN output and need the DBID value of a database for a restore operation, obtain it via the RC_DATABASE or RC_DATABASE_INCARNATION recovery catalog views.
Because the names of the databases that are registered in the recovery catalog are presumed non-unique in this scenario, some other unique piece of information must be used to determine the correct DBID. If you know the filename of a datafile or online redo log associated with the database you wish to restore, and this filename is unique across all databases registered in the recovery catalog, then substitute this fully-specified filename for filename_of_log_or_df in the queries below. Determine the DBID by performing one of the following queries:
SELECT distinct db_id FROM db, dbinc, dfatt WHERE db.db_key = dbinc.db_key AND dbinc.dbinc_key = dfatt.dbinc_key AND dfatt.fname = 'filename_of_log_or_df'; SELECT distinct db_id FROM db, dbinc, orl WHERE db.db_key = dbinc.db_key AND dbinc.dbinc_key = orl.dbinc_key AND orl.fname = 'filename_of_log_or_df';
Only use the set dbid command to restore the control file when all of these conditions are met:
If these conditions are not met, you will receive the RMAN-20005: target database name is ambiguous message when you attempt to restore the control file. RMAN will correctly identify the control file to restore, so you do not need to use the set dbid command.
RMAN accepts set dbid only if you have not yet connected to the target database, i.e., set dbid must precede the connect target command. If the target database is mounted, then RMAN verifies that the user-specified DBID matches the DBID from the database; it not, RMAN signals an error. If the target database is not mounted, RMAN uses the user-specified DBID to restore the control file. After restoring the control file, you can mount the database to restore the rest of the database.
To set the database id enter the following, where target_dbid is an integer value:
set dbid = target_dbid;
To restore the control file to its default location enter:
run { allocate channel dev1 type 'sbt_tape'; restore controlfile; alter database mount; }
You will be forced to use a non-standard procedure to restore a control file from an RMAN backup set in the following situations:
If you have no other backup of the control file except in a RMAN backup set, and you need the control file to perform a restore operation, use the following PL/SQL program to extract the control file from the backup set.
Run this program from SQL*Plus while connected as SYSDBA to the target database:
DECLARE devtype varchar2(256); done boolean; BEGIN devtype := dbms_backup_restore.deviceallocate('devtype', params=>''); # Replace 'devtype' with the device type you used when creating the backup: disk or # sbt_tape. If you used an sbt_tape device and specified a 'parms' option on the RMAN # allocate channel command, then put that parms data in the 'params' operand here. dbms_backup_restore.restoresetdatafile; dbms_backup_restore.restorecontrolfileto('/tmp/foo.cf'); # This path specifies the location for the restored control file. If there are multiple # control files specified in the init.ora file, copy the control file to all specified # locations before mounting the database. dbms_backup_restore.restorebackuppiece('handle',done=>done); # Replace 'handle' with the your backup piece handle. This example assumes that the # backup set contains only one backup piece. If there is more than one backup piece in # the backup set (which only happens if the RMAN command set limit kbytes is used), then # repeat the restorebackuppiece statement for each backup piece in the backup set. END; /
Once you have successfully restored the control file, you can mount the database and perform restore and recovery operations.
In this scenario, the database is open but you cannot access a datafile. You execute the following SQL query to determine its status:
SELECT * FROM v$recover_file; FILE# ONLINE ERROR TIME ---------- ------- -------------- ---------- 19 ONLINE FILE NOT FOUND
You then decide to start RMAN and connect to the target and recovery catalog databases:
% rman target / catalog rman/rman@rcat
You issue a report command to determine the datafile's tablespace and filename:
RMAN> report schema; RMAN-03022: compiling command: report Report of database schema File K-bytes Tablespace RB segs Name ---- ---------- -------------------- ------- ------------------- 1 47104 SYSTEM YES /oracle/dbs/tbs_01.f 2 978 SYSTEM YES /oracle/dbs/tbs_02.f 3 978 TBS_1 NO /oracle/dbs/tbs_11.f 4 978 TBS_1 NO /oracle/dbs/tbs_12.f 5 978 TBS_2 NO /oracle/dbs/tbs_21.f 6 978 TBS_2 NO /oracle/dbs/tbs_22.df 7 500 TBS_1 NO /oracle/dbs/tbs_13.f 8 500 TBS_2 NO /oracle/dbs/tbs_23.f 9 500 TBS_2 NO /oracle/dbs/tbs_24.f 10 500 TBS_3 NO /oracle/dbs/tbs_31.f 11 500 TBS_3 NO /oracle/dbs/tbs_32.f 12 500 TBS_4 NO /oracle/dbs/tbs_41.f 13 500 TBS_4 NO /oracle/dbs/tbs_42.f 14 500 TBS_5 YES /oracle/dbs/tbs_51.f 15 500 TBS_5 YES /oracle/dbs/tbs_52.f 16 5120 SYSTEM YES /oracle/dbs/tbs_03.f 17 2048 TBS_1 NO /oracle/dbs/tbs_14.f 18 2048 TBS_2 NO /oracle/dbs/tbs_25.f 19 2048 TBS_3 NO /oracle/dbs/tbs_33.f 20 2048 TBS_4 NO /oracle/dbs/tbs_43.f 21 2048 TBS_5 YES /oracle/dbs/tbs_53.f
Because you need to take the datafile online immediately before you investigate the media failure, you decide to restore the datafile to a new location and switch to a copy of that datafile:
run { sql 'ALTER TABLESPACE tbs_3 OFFLINE IMMEDIATE'; allocate channel ch1 type disk; set newname for datafile '/oracle/dbs/tbs_33.f' to '/oracle/temp/tbs_33.f'; restore tablespace tbs_3; switch datafile all; recover tablespace tbs_3; sql 'ALTER TABLESPACE tbs_3 ONLINE'; }
If you cannot access datafiles due to a disk failure, it is likely that you must restore it to a new location or switch to an existing datafile copy. The following restore example restores and recover tablespace TBS_1, which contains four datafiles. Since some copies of these files are on disk and some backups on tape, the example allocates one disk channel and one media management channel to allow restore to restore from both disk and tape:
run { allocate channel dev1 type disk; allocate channel dev2 type 'sbt_tape'; sql "ALTER TABLESPACE tbs_1 OFFLINE IMMEDIATE"; set newname for datafile '/disk7/oracle/tbs11.f' to '/disk9/oracle/tbs11.f'; set newname for datafile '/disk7/oracle/tbs12.f' to '/disk9/oracle/tbs12.f'; set newname for datafile '/disk7/oracle/tbs13.f' to '/disk9/oracle/tbs13.f'; set newname for datafile '/disk7/oracle/tbs14.f' to '/disk9/oracle/tbs14.f'; restore tablespace tbs_1; switch datafile all; # makes the renamed datafile the current datafile recover tablespace tbs_1; sql "ALTER TABLESPACE tbs_1 ONLINE"; }
The following scenario assumes:
Before restoring the database, you must:
init.ora file, password file (if you use one), and your recovery catalog from your most recent backup using O/S commands or utilities.
The following scenario restores and recovers the database to the most recently available archived log, which is log 124 in thread 1. It:
init.ora parameter CONTROL_FILES.
% rman target sys/sys_pwd@prod1 catalog rman/rman@rcat startup nomount dba; run { # If you need to restore the files to new locations, tell Recovery Manager # to do this using 'set newname'. # 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'; # set newname for datafile 4 to '/dev/vgd_1_0/rlvt5_500M_4'; # etc... # 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 Recovery Manager restores # the database to the same structure the database was at that time. set until logseq 124 thread 1; allocate channel t1 type 'SBT_TAPE'; allocate channel t2 type 'SBT_TAPE'; allocate channel t3 type 'SBT_TAPE'; allocate channel t4 type 'SBT_TAPE'; restore controlfile; alter database mount; # Catalog any archivelogs that are not in the recovery catalog # catalog archivelog '/oracle/db_files/prod1/arch/arch_1_123.rdo'; # catalog archivelog '/oracle/db_files/prod1/arch/arch_1_124.rdo'; # etc... restore database; # Update the control file by telling it the new location of the datafiles # only if you used 'set newname for datafile' above. # switch datafile all; recover database; # Complete this last step only if no more archived logs need to be applied. sql 'ALTER DATABASE OPEN RESETLOGS'; }
Assume the following:
# obtain primary key of old incarnation list incarnation of database prod1; List of Database Incarnations DB Key Inc Key DB Name DB ID CUR Reset SCN Reset Time ------- ------- ------- ------ --- ---------- ---------- 1 2 PROD1 1224038686 NO 1 02-JUL-98 1 582 PROD1 1224038686 YES 59727 10-JUL-98 # reset database to old incarnation reset database to incarnation 2; # recover it run { set until time 'Jul 8 1998 07:55:00'; allocate channel dev1 type disk; shutdown abort; startup nomount; restore controlfile; alter database mount; restore database; recover database; sql 'alter database open resetlogs'; } # make this new incarnation the current incarnation reset database;
You can recover a database running in NOARCHIVELOG mode using incremental backups. Assume the following scenario:
In this case, you are forced to perform an incomplete media recovery until Friday, since that is the date of your most recent incremental backup. Note that RMAN always looks for incremental backups before looking for archived logs during recovery.
RMAN can perform the desired incomplete media recovery automatically if you specify the noredo option in the recover command. If you do not specify noredo, RMAN will search for archived redo logs after applying the Friday incremental backup, and issue an error message when it does not find them.
After connecting to PROD1 and the catalog database, recover the database using the following command:
run { allocate channel dev1 type 'sbt_tape'; restore database; recover database noredo; sql 'ALTER DATABASE OPEN RESETLOGS'; }
