Release 2 (8.1.6)
Part Number A76990-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Recovery Manager User's Guide and Reference Release 2 (8.1.6) Part Number A76990-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:
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 7, "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 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 is 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. You can perform this procedure so long as you have a valid backup and a recovery catalog or control file.
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 the database with the RESETLOGS option.
This scenario assumes that:
The restore procedure differs depending on whether the target database uses a recovery catalog.
% rman target sys/change_on_install@host_b catalog 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; alter database open resetlogs; }
% 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; alter database open resetlogs; }
The procedure for moving the database to a machine with a different file system is basically the same as described in "Moving the Target Database to a New Host with the Same File System"; 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.
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; alter database open resetlogs; }
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; alter database open resetlogs; }
To create a duplicate database for testing while maintaining your original database, use the duplicate command instead of the restore command (see Chapter 7, "Creating a Duplicate Database with Recovery Manager"). RMAN automatically creates a unique database identifier for the duplicate database.
To test the restore of a database to a new host using the restore command, follow the procedures described in "Moving the Target Database to a New Host with the Same File System" or "Moving the Target Database to a New Host with a Different File System". To prevent the generation of unnecessary records in the recovery catalog, do one of the following:
The following table describes the impact on the RMAN repository of the various restore scenarios:
If a datafile is lost or corrupted but the disk is accessible, then you can restore the datafile to its previous location. Take the tablespace offline and issue a restore tablespace command. If the old location is inaccessible, then take the tablespace offline and restore the associated datafiles to a new location.
If you cannot restore datafiles to the default location, then 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, that is, 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.
% 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 does 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, then 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; }
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 initialization parameter file and restore backups, subsequent restore and recovery operations detect this new location and do not look for the files in the initialization parameter 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; }
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; }
In some customer configurations, tape backups can only be restored from the node that created the backups. Consequently, if node A makes a backup to tape in an OPS configuration, node A--and not node B or node C--must perform the restore. Issue the set autolocate command to force RMAN to discover which nodes of an OPS cluster should attempt to restore which backups. If you do not issue set autolocate when restoring in conjunction with certain media management products or when restoring from a file system, the restore can fail because RMAN attempts to restore a backup from a node where it does not reside.
Issue the set autolocate on command only if:
% 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;
run { allocate channel node_1 type disk connect 'sys/sys_pwd@node_1'; allocate channel node_2 type disk connect 'sys/sys_pwd@node_2'; allocate channel node_3 type disk connect 'sys/sys_pwd@node_3'; set autolocate on; 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 or non-current 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 initialization parameter 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:
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 clause 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; 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 prevents 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 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 because 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.
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; 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; 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; alter database open resetlogs; }
reset database;
run { allocate channel ch1 type 'sbt_tape'; backup database; }
Performing DBPITR without a recovery catalog requires that you adhere to the following precautionary measures:
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. Nevertheless, this backup control file does not contain a 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 because the control file has no record of them.
To back up the control file separately, issue commands within your run command as in the following example:
backup database; backup current controlfile tag = 'database backup';
These commands create two backup sets, each of which contains a backup control file. The control file backup created by the second command is the useful one, that is, it will contain all the records related to the database backup. Creating a tag for the backup control file is useful if you need to specify it later for a restore. Do not change the tag when you take a subsequent control file backup.
Immediately following the addition of a new tablespace or datafile to the database, make a new backup. If you are running in NOARCHIVELOG mode, you must back up the entire database. If you are running in ARCHIVELOG mode, then you can back up just the tablespace or datafiles that you added. Follow the backups with a backup of the control file using the backup current controlfile command as described in "Back Up the Control File Separately".
This operation is insurance in case you need to manually restore a control file from a backup set without using RMAN (as described in "Restoring the Control File from a Backup Set Without Using RMAN").
To make RMAN write output to a file, either redirect STDOUT at the operating system level or use the RMAN log command line option.
To ensure that the control file contains backup records that you need for performing DBPITR, set the following initialization parameter to a non-zero value (where integer is some number of days):
CONTROL_FILE_RECORD_KEEP_TIME = integer
This value should be equal to or greater than the maximum number of days that you need to go back during point-in-time recovery. For example, if you need to recover to a point two weeks before the present, then set the parameter to 14 or higher.
|
See Also:
"Monitoring the Overwriting of Control File Records" and "Managing Records in the Control File" to learn how to manage CONTROL_FILE_RECORD_KEEP_TIME. |
% rman target / nocatalog
startup force mount;
For example, execute the following script 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' from tag = 'database backup'; }
|
Note: This example assumes the NLS_DATE_FORMAT environment variable has been set to 'MON DD YYYY HH24:MI:SS'. You can set it to any format you like, but you must specify the date to RMAN in that format. For the NLS_DATE_FORMAT to take effect, you must also explicitly set the NLS_LANG environment variable to whatever locality, language, and character set that you are using. For more information, see "Setting NLS Environment Variables" |
RMAN-08021:
RMAN-08021: channel c1: restoring controlfile RMAN-08505: output filename=/oracle/dbs/cf1.f RMAN-08023: channel c1: restored backup piece 1 RMAN-08511: piece handle=/oracle/dbs/0ab81tct_1_1 tag=post_wholedb params=NULL RMAN-08024: channel c1: restore complete
SQL> alter database backup controlfile to '/tmp/original_cf';
For example, assume that the CONTROL_FILES parameter is set as follows:
CONTROL_FILES = (?/dbs/cf1.f, ?/dbs/cf2.f)
Then, shut down the database and use operating system commands to copy the control file that you restored to the temporary location to the initialization parameter locations. For example, enter:
SQL> SHUTDOWN ABORT % cp /tmp/cf.tmp $ORACLE_HOME/dbs/cf1.f % cp /tmp/cf.tmp $ORACLE_HOME/dbs/cf2.f
SQL> STARTUP MOUNT
run { set until time 'Jun 18 1998 16:32:36'; allocate channel ch1 type disk; restore database; recover database noredo; alter database open resetlogs; }
reset database;
run { allocate channel ch1 type disk; backup database; }
If you are running in ARCHIVELOG mode, then stop here. If you are running in NOARCHIVELOG mode, then proceed to the next step.
run { allocate channel ch1 type disk; # or type 'sbt_tape' backup backup controlfile '/tmp/original_cf' format ...; }
Alternatively, you can copy the backup control file that you made in step 5 to a permanent location and then make RMAN aware of it by using the catalog command. First, copy the control file to a permanent location, giving it a meaningful filename:
% cp /tmp/original_cf $ORACLE_HOME/dbs/backup_cf_JUN-20-1999
Then, use the catalog command make RMAN aware of this control file:
catalog backup controlfile '/oracle_home/dbs/backup_cf_JUN-20-1999';
Following are useful scenarios for performing restore and recovery operations:
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, you must use some other unique piece of information 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 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, that is, 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 disk; restore controlfile; alter database mount; }
You must 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: NULL 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; /
After 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 a datafile due to a disk failure, you should probably restore it to a new location or switch to an existing datafile copy. The following example restores and recover tablespace TBS_1, which contains four datafiles. Because some copies of these files are on disk and some backups on tape, the example allocates one disk channel and one tape channel to allow restore to restore from both media:
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:
The following scenario restores and recovers the database to the most recently available archived log, which is log 124 in thread 1. The example:
% 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 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'; # 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 that the database had at the specified 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, but # only if you used set newname commands. # switch datafile all; recover database; # Complete this last step only if no more archived logs need to be applied. alter database open resetlogs; }
Assume the following situation:
On July 25, you discover that you need crucial data that was dropped from the database at 8:00 a.m. on July 8, 1999. You decide to reset PROD1 to the prior incarnation, restore the July 2 backup, and then recover to 7:55 a.m. on July 8.
# 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-99 1 582 PROD1 1224038686 YES 59727 10-JUL-99
# reset database to old incarnation reset database to incarnation 2;
run { set until time 'Jul 8 1999 07:55:00'; # set time to just before data was lost allocate channel dev1 type disk; shutdown abort; startup nomount; restore controlfile; alter database mount; # mount database after restoring control file restore database; recover database; alter database open resetlogs; # this command automatically resets the database # so that this incarnation is the new incarnation }
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 searches for archived redo logs after applying the Friday incremental backup, and issues 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; alter database open resetlogs; }
In this scenario, the following sequence of events occurs:
rmantarg_t1.dbf.
rmantarg_t1.dbf from the operating system before you have a chance to back it up.
Are you prevented from recovering the data in the lost datafile because you have no backup of the file? No. You can recover the lost data by creating a new datafile with the exact same filename as the lost datafile, then issuing the RMAN recover command to apply the redo for this file.
For example, run the following job:
run { allocate channel c1 type disk; # take the missing datafile offline sql "alter database datafile ''/eg2k001/u02/ORACLE/rmantarg/rmantarg_t1.dbf" offline"; # create a new datafile with the same name as the missing datafile sql "alter database create datafile ''/eg2k001/u02/ORACLE/rmantarg/rmantarg_t1.dbf''"; # recover the newly created datafile recover datafile '/eg2k001/u02/ORACLE/rmantarg/rmantarg_t1.dbf'; # bring the recovered datafile back online sql "alter database datafile ''/eg2k001/u02/ORACLE/rmantarg/rmantarg_t1.dbf'' online"; }
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|