Restoring a Database on a New Host

本文用于测试disaster recovery或是move a database to a new host，数据库DBID不会发生变化，如果目标是创建当前数据库副本使用RMAN DUPLICATE

If your goal is to perform a test run of your disaster recovery procedures, or to permanently move a database to a new host, then you can use the procedure in this section

If you use the procedure in this section, then the DBID for the restored database is the same as the DBID for the original database. Do not register a test database created in this way in the same recovery catalog as the source database. Because the DBID of the two databases is the same, the metadata for the test database can interfere with RMAN's ability to restore and recover the source database.

If your goal is to create a copy of your target database for ongoing use on a new host, then use the RMAN DUPLICATE command instead of this procedure. The DUPLICATE command assigns a new DBID to the database it creates, enabling it to be registered in the same recovery catalog as the original database.

1. Preparing to Restore a Database on a New Host

To prepare for the restoration of the database to a new host, take the following steps:

1. Record the DBID for your source database.
2. Make the source database initialization parameter file accessible on the new host. Copy the file from the old host to a new host by using an operating system utility.
3. If you perform a test restore operation only, then ensure that RMAN is not connected to the recovery catalog. Otherwise, RMAN records metadata about the restored data files in the recovery catalog. This metadata interferes 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 must restore, then use Oracle Data Pump to export the catalog and import it into a different schema or database. Afterward, use the copied recovery catalog for the test restore. Otherwise, the recovery catalog considers the restored database as the current target database.

1. Ensure that backups used for the restore operation are accessible on the restore host. For example, if the backups were made with a media manager, then verify that the tape device is connected to the new host. If you are using disk copies, then use the procedure in the following section.
2. If you are performing a trial restore of the production database, then perform either of the following actions before restoring the database in the test environment:

1. If the test database will use a fast recovery area that is physically different from the recovery area used by the production database, then set DB_RECOVERY_FILE_DEST in the test database instance to the new location.
2. If the test database will use a fast recovery area that is physically the same as the recovery area used by the production database, then set DB_UNIQUE_NAME in the test database instance to a different name from the production database.

If you do not perform either of the preceding actions, then RMAN assumes that you are restoring the production database and deletes flashback logs from the fast recovery area because they are considered unusable.

1. Restoring Disk Backups to a New Host

To move the database to a new host by using data file copies or backup sets on disk, you must transfer the files manually to the new host. This example assumes that RMAN is using a recovery catalog.

To restore backup files to a new host:

1. Start RMAN and connect to a target database and recovery catalog.
2. Run a LIST command to see a listing of backups of the data file and control file autobackups.
3. Copy the backups to the new host with an operating system utility.

$ cp -r /disk1/*dbf /net/new_host/oracle/oradata/trgt

Enter a command such as the following to copy the autobackup backup piece to the /tmp directory on the new host:

$ cp -r /disk1/auto_bkp_loc/c-1618370911-20130208-00 /net/new_host/tmp

1. Testing the Restore of a Database on a New Host

This scenario tests whether you can restore your database to a new host.

In this scenario, you have two networked Linux hosts, hosta and hostb. A target database named trgta is on hosta and is registered in recovery catalog catdb. You want to test the restore and recovery of trgta on hostb, while keeping database trgta up and running on hosta.

Now, assume that the directory structure of hostb is different from hosta. The target database is located in /net/hosta/dev3/oracle/dbs, but you want to restore the database to /net/hostb/oracle/oradata/test.

You have tape backups of data files, control files, archived redo logs, and the server parameter file on a media manager accessible by both hosts. The ORACLE_SID for the TRGTA database is TRGTA and does not change for the restored database.

To restore the database on a new host:

1. Ensure that the backups of the target database are accessible on the new host.

To test disaster recovery, you must have a recoverable backup of the target database. When preparing your disaster recovery strategy, ensure that the backups of the data files, control files, and server parameter file are restorable on hostb. Thus, you must configure the media management software so that hostb is a media manager client and can read the backup sets created on hosta.

1. Configure the ORACLE_SID on hostb.

This scenario assumes that you want to start the RMAN client on hostb and authenticate yourself through the operating system.

After logging in 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 on hostb to the same value used on hosta:

$ setenv ORACLE_SID trgta

1. Start RMAN on hostb and connect to the target database without connecting to the recovery catalog.

$ rman NOCATALOG

RMAN> CONNECT TARGET /

1. Set the DBID and start the database instance without mounting the database.

SET DBID 1340752057;

STARTUP NOMOUNT

RMAN fails to find the server parameter file, which has not yet been restored, but starts the instance with a "dummy" file.

1. Restore and edit the server parameter file.

RUN

{

  ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...';

  SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F';

  RESTORE SPFILE

    TO PFILE '?/oradata/test/inittrgta.ora'

    FROM AUTOBACKUP;

  SHUTDOWN ABORT;

}

1. Edit the restored initialization parameter file.

Change any location-specific parameters, for example, those ending in _DEST, to reflect the new directory structure. For example, edit the following parameters:

  - IFILE

  - LOG_ARCHIVE_DEST_1

  - CONTROL_FILES

1. Restart the instance with the edited initialization parameter file.

STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';

1. Restore the control file from an autobackup and then mount the database.

RUN {

  ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...';

  RESTORE CONTROLFILE FROM AUTOBACKUP;

  ALTER DATABASE MOUNT; }

RMAN restores the control file to whatever locations you specified in the CONTROL_FILES initialization parameter.

1. Catalog the data file copies that you copied in "Restoring Disk Backups to a New Host", using their new file names or CATALOG START WITH (if you know all the files are in directories with a common prefix easily addressed with a CATALOG START WITH command).

CATALOG START WITH '/oracle/oradata/trgt/';

If you want to specify files individually, then you can execute a CATALOG command as follows:

CATALOG DATAFILECOPY

  '/oracle/oradata/trgt/system01.dbf', '/oracle/oradata/trgt/undotbs01.dbf',

  '/oracle/oradata/trgt/cwmlite01.dbf', '/oracle/oradata/trgt/drsys01.dbf',

  '/oracle/oradata/trgt/example01.dbf', '/oracle/oradata/trgt/indx01.dbf',

  '/oracle/oradata/trgt/tools01.dbf', '/oracle/oradata/trgt/users01.dbf';

1. Start a SQL*Plus session on the new database and query the database file names recorded in the control file.

COLUMN NAME FORMAT a60

SPOOL  LOG '/tmp/db_filenames.out'

SELECT FILE# AS "File/Grp#", NAME

FROM   V$DATAFILE

UNION

SELECT GROUP#,MEMBER

FROM   V$LOGFILE;

SPOOL OFF

EXIT

1. Write the RMAN restore and recovery script. The script must include the following steps:

1. For each data file 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.
2. 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 path name 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.
3. Perform a SET UNTIL operation to limit recovery to the end of the archived redo logs. The recovery stops with an error if no SET UNTIL command is specified.
4. Restore and recover the database.
5. Run the SWITCH DATAFILE ALL command so that the control file recognizes the new path names as the official new names of the data files.

The following code shows the RMAN script reco_test.rman that can perform the restore and recovery operation.

RUN

{

  # allocate a channel to the tape device

  ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS '...';

  # rename the data files 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';

  ALTER DATABASE RENAME FILE '/dev3/oracle/dbs/redo01.log'

      TO '?/oradata/test/redo01.log';

  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 data file names

  RESTORE DATABASE;

  SWITCH DATAFILE ALL;

  # recover the database

  RECOVER DATABASE;

}

EXIT

1. Execute the script created in the previous step.
2. Open the restored database with the RESETLOGS option.

ALTER DATABASE OPEN RESETLOGS;

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 file names of the production database are replaced by the new file names specified in the script.

1. Optionally, delete the test database with all of its files.

If you used an ASM disk group, then the DROP DATABASE command 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.

STARTUP FORCE NOMOUNT PFILE='?/oradata/test/inittrgta.ora';

DROP DATABASE;

Because you did not perform the restore and recovery operation 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.