Yahoo!

White Paper

Restoring from a RMAN Backup into a different Host

By Ritesh Rajkaran Chhajer Mukesh Burgupalli Ashwin Nellore Arpan Kumar Shrivastava SE&O DBA Team

Yahoo! White Paper

RMAN RESTORE

1. Purpose This document explains the steps to restore and recover a RMAN backup to a different host. This document can be used to test the recovery of an existing RMAN backup as well as for the real-time recovery 2. Steps to restore and recover the database to different host The following recovery test will restore and recover the backup of database gqdna01s on gq1stgdnadb-001.data.gq1 to ac4-stgsstrdb-001.ysm.ac4. This test assumes the following: We have the RMAN backup, init.ora file available on the new machine. So we need to restore controlfile and then the datafiles. Steps to restore the spfile is also covered. The backup is made available on the new machine by mounting it in the same name as the target database. If it is mounted with a different name, you will have to create a symlink to that with the same name as on the target database. The datafile naming convention in the target database and the new host is different. Hence, the 'set newname' clause to rename datafiles is used. Source Host: gq1-stgdnadb-001.data.gq1 (ASM) Target Host: ac4-stgsstrdb-001.ysm.ac4 (Non-ASM) Existing RMAN Backup Location on source: /mnt/dna_rman1_nonprod/dev/full_lvl0 Pre-requisites: 1 .Copy the backup to be made available on the destination host under the same directory structure. 2. Edit /etc/fstab on the destination (ac4-stgsstrdb-001.ysm.ac4): ac4-stgiraud2nfs-001.adx.ac4.yahoo.com:/vol/RM_DAT /mnt/dna_rman1_nonprod nfs nolock,rsize=32768,wsize=32768,hard,nointr,rw,bg,vers=3,tcp,actimeo=0,timeo=600 0 0 # mkdir -p /mnt/dna_rman1_nonprod/dev # chmod 755 /mnt/dna_rman1_nonprod/dev # chown oracle:dba /mnt/dna_rman1_nonprod/dev Once the backup is available on the destination, follow the steps: 1) Get the DBID of the target database (gq1-stgdnadb-001.data.gq1) either from querying the source database, if available source /oracle/.zshrc select dbid from v$database; OR

Yahoo! White Paper

If you do not have a record of the DBID of your database, there are two places you can find it without opening your database. 1) The DBID is used in forming the filename for the control file autobackup. Ex: bkup_ctrl_c-2236648503-20101230-00_Full, the bold text is the DBID 2) If you have any text file that preserve the output from an RMAN session, the DBID is displayed by the RMAN client when it starts up and connects to your database. Typical output follows: Recovery Manager: Release 11.2.0.2.0 - Production on Sun Nov 28 02:00:02 2010 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: GQDNA01S (DBID=2236648503) using target database control file instead of recovery catalog 2) Copy the source init file to $ORACLE_HOME/dbs on the destination (ac4-stgsstrdb001.ysm.ac4) or you can restore using RMAN if you already have a backup of spfile as follows: rman target / run { set DBID=id restore spfile from autobackup; } 3) Create/Copy the source password file to $ORACLE_HOME/dbs on the destination. $orapwd file/oracle/product/11.2.0.2/dbs/orapwgqdna01s password=oracle entries=10 ignorecase=Y; 4) Modify the parameter 'control_files' in the pfile to reflect the new location. 5) export ORACLE_SID=gqdna01s startup nomount pfile='/oracle/product/11.2/dbs/initgqdna01s.ora'; 6) rman target / RMAN> set dbid=2236648503 (from Step 1) executing command: SET DBID RMAN> restore controlfile from /mnt/dna_rman1_nonprod/dev/full_lvl0/ bkup_ctrl_c2236648503-20101230-00_Full '; Location of the Existing Backup control file Starting restore at 20-DEC-10 using target database control file instead of recovery catalog

Yahoo! White Paper

allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=88 devtype=DISK channel ORA_DISK_1: restoring control file channel ORA_DISK_1: restore complete, elapsed time: 00:00:03 output filename=/u01/oradata/gqdna01s/control01.ctl Finished restore at 20-DEC-10

ls -ltr /u01/oradata/gqdna01s/control01.ctl will be the control file for the new database. 7) RMAN> sql 'alter database mount'; 8) RMAN> list backup of database; 9) Datafile location settings: Case 1: Source and destination hosts have different directory structure, for eg ASM to nonASM spool restore.rman select 'set newname for datafile '||file#||' to '''||replace(name,'x','y')||''';' from v$datafile; spool off --Modify restore.rman to look like this: run { #For all datafiles: Set newname for datafile '+DATA/prod/system01.dbf' to '/u01/oradata/gqdna01s/system01.dbf'; ... .... #For all tempfiles: set newname for tempfile 1 to '/u01/oradata/gqdna01s/tempfile'; ..... restore database; switch datafile all; switch tempfile all; recover database } Run: RMAN>@restore.rman Check if you have a proper backup of gqdna01s.

Yahoo! White Paper

Case 2: Source and destination have same directory structure. run { restore database; recover database } Optional (if the feature is enabled): Disable block change tracking After recovery is over, run the below command to disable the block change tracking. Otherwise when you try to open the database it will complain about the missing change tracking file. RMAN> SQLALTER DATABASE DISABLE BLOCK CHANGE TRACKING; Open the database: RMAN> SQL "ALTER DATABASE OPEN"; --Create new redo logs and drop the older one's, make sure they are not in current/active state. (Assumption: 123- old -456-new) SQL> ALTER DATABASE ADD LOGFILE GROUP 4 ('/u01/oradata/gqdna01s/redo04.log'); SQL> ALTER DATABASE ADD LOGFILE GROUP 5 ('/u01/oradata/gqdna01s/redo05.log'); SQL> ALTER DATABASE ADD LOGFILE GROUP 6 ('/u01/oradata/gqdna01s/redo06.log'); SQL> select group#,member from v$logfile; SQL> ALTER DATABASE DROP LOGFILE GROUP 1; SQL> ALTER DATABASE DROP LOGFILE GROUP 2; SQL> ALTER DATABASE DROP LOGFILE GROUP 3; Cleanup: Once the test is over successfully and you want remove the database and thus the database files, run the commands. SQL>conn /as sysdba SQL> startup force restrict mount; $rman target / RMAN> DROP DATABASE;