This scenario assumes the following:
Two networked machines, hosta and hostb, are running Sun Solaris
A media management subsystem is accessible by both machines
The directory structure of hostb is different from hosta, so that trgta is located in /net/hosta/dev3/oracle/dbs, but you want to restore the database to /net/hostb/oracle/oradata/test
A target database named trgta is on hosta and uses a recovery catalog catdb
Database trgta uses a server parameter file (not a client-side initialization parameter file)
You want to test the restore and recovery of trgta on hostb, while keeping database trgta up and running on hosta
The ORACLE_SID for the trgta database is trgta and will not change for the restored database
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
You have a record of the DBID for trgta
To test the restore of the database to a new host:
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 on hostb. Hence, you must configure the media management software so that hostb is a media manager client and can read the backup sets created on hosta. Consult the media management vendor for support on this issue.
Configure the ORACLE_SID on hostb. This case study 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 to hostb either locally or through telnet.
While connected to hostb with administrator privileges, edit the /etc/group file so that you are included:dba:*:614:
Run the setenv command on hostb to set the ORACLE_SID. In this example, you set the SID to the same value that you used on hosta:% setenv ORACLE_SID trgta
Start RMAN and connect to the target instance without connecting to the recovery catalog.% rman TARGET / NOCATALOG
Start the instance without mounting it. To start the instance, you first need to set the DBID. The DBID is recorded in several places, including:
V$DATABASE in the target and RC_DATABASE in the catalog
The RMAN output (command-line and V$RMAN_STATUS)
The filename of the control file autobackups
Run SET DBID to set the DBID, then run STARTUP NOMOUNT:SET DBID 1340752057;
STARTUP NOMOUNT
RMAN 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 started
Restore 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. Hence, you can allocate a channel to the media manager and restore the server parameter file to a new location as a client-side initialization parameter file. Then you can edit the client-side file and restart the instance with the edited client-side file. For example: RUN
{
ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='...';
RESTORE SPFILE TO PFILE '?/oradata/test/inittrgta.ora' FROM AUTOBACKUP;
SHUTDOWN ABORT;
}
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_FILES
Restart the instance, specifying the client-side initialization parameter file that you restored:STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';
Restore the control file from an autobackup and then mount the database. Because you edited the init.ora in the preceding step, 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 query V$ 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
UNION
SELECT GROUP#,MEMBER FROM V$LOGFILE;
SQL> SPOOL OFF
SQL EXIT
Restore and recover the database. At this point you are ready to write the RMAN recovery script. The script should do the following:
Run SET NEWNAME for each datafile so it is renamed to its new hostb path name
Run SQL commands to rename the online redo logs to their new hostb path names
Perform a SET UNTIL to limit media recovery to the end of the archived redo logs, as described in "Determining the SCN for Incomplete Recovery After Restore"
Run SWITCH so that the control file recognizes the new path names as the official new names of the datafiles
Restore and recover the database
The following is an example of an 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;
}
EXIT
Caution:
It is imperative that you not be connected with the recovery catalog when you run this script, so that you do not incorporate extraneous repository data about backups into the recovery catalog.
For example, connect and execute as follows:% rman TARGET / NOCATALOG
RMAN> @reco_test.rman
RMAN 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.
Open the database. From the RMAN prompt, open the database with the RESETLOGS options: RMAN> ALTER DATABASE OPEN RESETLOGS;
Remove the test files from the operating system. If the test is successful, then shut down the instance and exit the RMAN session: RMAN> SHUTDOWN ABORT
RMAN> EXIT
Remove 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 ok 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.
No comments:
Post a Comment