RMAN Recovery Scenarios: Case Studies (A practical approach) Written by : ANKESH BARODE P a g e 1
Contents 1) Taking database hot backup.(4-7) 2) SPFILE recovery...(7-8) 3) Control file recovery...(8-9) 4) System datafile recovery (Offline recovery)... (10-11) 5) Online datafile recovery (Online recovery)..(12-12) 6) Database block recovery.... (13-18) P a g e 2
GUIDELINES AND TOOLS & TECHNOLGIES USED Obiective: To demonstrate how to recover a database using RMAN Audience: The intended audiences are those who have basic idea of Recovery Manager Type of Document: Demonstration Platform: I have performed this exercise on Microsoft Windows 7. It can be done on any platform. Database Version: 11.2.0.1.0 Tools Used: Oracle RMAN and Hex Editor (for simulating block corruption) Disclaimer: The activity has been performed on my home pc i.e. it's not a production environment and request readers not to try it at client site. P a g e 3
Database hot backup running in Archivelog mode without recovery catalog Step 1: Took a fresh backup RMAN> run 2> {backup 3> format 'c:\rman_backup\streamsl_%u' 4> database plus archivelog; 5> backup current controlfile; 6> } Starting backup at 09-FEB-12 current log archived using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=131 device type=disk channel ORA_DISK_1: starting archived log backup set channel ORA_DISK_1: specifying archived log(s) in backup set input archived log thread=1 sequence=125 RECID=1 STAMP=771982167 input archived log thread=1 sequence=126 RECID=2 STAMP=772042038 input archived log thread=1 sequence=127 RECID=3 STAMP=772044006 input archived log thread=1 sequence=128 RECID=4 STAMP=772058936 input archived log thread=1 sequence=129 RECID=5 STAMP=772073801 input archived log thread=1 sequence=130 RECID=6 STAMP=772558755 input archived log thread=1 sequence=131 RECID=7 STAMP=772558885 input archived log thread=1 sequence=132 RECID=8 STAMP=772560548 input archived log thread=1 sequence=133 RECID=9 STAMP=772560560 input archived log thread=1 sequence=134 RECID=10 STAMP=772576819 input archived log thread=1 sequence=135 RECID=11 STAMP=772591183 input archived log thread=1 sequence=136 RECID=12 STAMP=772647047 input archived log thread=1 sequence=137 RECID=13 STAMP=772659948 input archived log thread=1 sequence=138 RECID=14 STAMP=772675219 input archived log thread=1 sequence=139 RECID=15 STAMP=772754867 input archived log thread=1 sequence=140 RECID=16 STAMP=772836067 input archived log thread=1 sequence=141 RECID=17 STAMP=772842637 input archived log thread=1 sequence=142 RECID=18 STAMP=773015458 input archived log thread=1 sequence=143 RECID=19 STAMP=773596501 input archived log thread=1 sequence=144 RECID=20 STAMP=773596664 input archived log thread=1 sequence=145 RECID=21 STAMP=773596808 input archived log thread=1 sequence=146 RECID=22 STAMP=773598294 P a g e 4
input archived log thread=1 sequence=147 RECID=23 STAMP=773618527 input archived log thread=1 sequence=148 RECID=24 STAMP=774824164 input archived log thread=1 sequence=149 RECID=25 STAMP=774824247 input archived log thread=1 sequence=150 RECID=26 STAMP=774824349 input archived log thread=1 sequence=151 RECID=27 STAMP=774824541 input archived log thread=1 sequence=152 RECID=28 STAMP=774825964 input archived log thread=1 sequence=153 RECID=29 STAMP=774825988 input archived log thread=1 sequence=154 RECID=30 STAMP=774828051 input archived log thread=1 sequence=155 RECID=31 STAMP=774828600 input archived log thread=1 sequence=156 RECID=32 STAMP=774828601 input archived log thread=1 sequence=157 RECID=33 STAMP=774828603 input archived log thread=1 sequence=158 RECID=34 STAMP=774828606 input archived log thread=1 sequence=159 RECID=35 STAMP=774828607 input archived log thread=1 sequence=160 RECID=36 STAMP=774829231 channel ORA_DISK_1: starting piece 1 at 09-FEB-12 channel ORA_DISK_1: finished piece 1 at 09-FEB-12 piece handle=c:\rman_backup\streamsl_07n2tt5i_1_1 tag=tag20120209t222032 comment=none channel ORA_DISK_1: backup set complete, elapsed time: 00:01:55 Finished backup at 09-FEB-12 Starting backup at 09-FEB-12 using channel ORA_DISK_1 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set input datafile file number=00001 name=d:\app\ankesh\oradata\vdc11g\system01.dbf input datafile file number=00002 name=d:\app\ankesh\oradata\vdc11g\sysaux01.dbf input datafile file number=00003 name=d:\app\ankesh\oradata\vdc11g\undotbs01.dbf input datafile file number=00005 name=d:\app\ankesh\oradata\vdc11g\example01.dbf input datafile file number=00004 name=d:\app\ankesh\oradata\vdc11g\users01.dbf channel ORA_DISK_1: starting piece 1 at 09-FEB-12 channel ORA_DISK_1: finished piece 1 at 09-FEB-12 piece handle=c:\rman_backup\streamsl_08n2tt96_1_1 tag=tag20120209t222230 comment=none channel ORA_DISK_1: backup set complete, elapsed time: 00:01:45 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 09-FEB-12 channel ORA_DISK_1: finished piece 1 at 09-FEB-12 piece handle=c:\rman_backup\streamsl_09n2ttcg_1_1 tag=tag20120209t222230 comment=none channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 09-FEB-12 Starting backup at 09-FEB-12 current log archived using channel ORA_DISK_1 channel ORA_DISK_1: starting archived log backup set channel ORA_DISK_1: specifying archived log(s) in backup set input archived log thread=1 sequence=161 RECID=37 STAMP=774829458 channel ORA_DISK_1: starting piece 1 at 09-FEB-12 channel ORA_DISK_1: finished piece 1 at 09-FEB-12 piece handle=c:\rman_backup\streamsl_0an2ttcj_1_1 tag=tag20120209t222419 comment=none P a g e 5
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 09-FEB-12 Starting backup at 09-FEB-12 using channel ORA_DISK_1 channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current control file in backup set channel ORA_DISK_1: starting piece 1 at 09-FEB-12 channel ORA_DISK_1: finished piece 1 at 09-FEB-12 piece handle=d:\app\ankesh\flash_recovery_area\vdc11g\backupset\2012_02_09\o1 _MF_NCNNF_TAG20120209T222420_7M7YKXO5_.B KP tag=tag20120209t222420 comment=none channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 09-FEB-12 RMAN> P a g e 6
Step 2: Performed following in order to simulate the complete recovery Shutdown the database P a g e 7
Renamed the folder/s which contains database files Renamed the splile Started recovery with the recovery of splile. So 1st opened the database in nomount state without spfile and then restored spfile from backup. Step 3: Once the spfile is restored, started the database in nomount state with spfile, Now I have to restore the controlfiles and restored successfully. Then mount the database by using RMAN>alter database mount Step 4: Started restoration of all the datafiles and restored successfully. P a g e 8
Step 5: Now it's time to recover the database. I like to do the same using SQLPLUS prompt (the legacy method). Performed cancel based recovery. Recovery completed successfully. And Opened the database. P a g e 9
Recovery of tablespaces Sub-sections Recovery of system tablespace Recovery of a tablespace online Step 1: To simulate the scenario, I did following: Shutdown the database Renamed the datafile SySTEM01.DBF which belongs to SYSTEM tablespace Tried starting the database Got errors ORA-01157 and ORA-01110. P a g e 10
Step 2: Restore the system datafile Step 3: Recovered the system tablespace and opened the database. P a g e 11
Recovery of a tablespace online Similarly if any of datafile gets corrupted(other datafiles are intact and database up and running), we may recover it as follows: (Note in case of UNIX OS no need to take datafile offline we can directly rename datafiles) Step 1: Take the tablespace or datafile offline (Say test tablespace has corruption): RMAN> sql "alter tablespace test offline ; OR RMAN> sql alter database datafile 'D:\APP\ANKESH\ORADATA\VDC11G\TEST01.DBF offline ; OR RMAN> sql alter database datafile 6 offline; Rename the datafile, if is still there but corrupt. Step 2: Restore the tablespace RMAN> restore tablespace test: OR RMAN> restore datafile 6; Step 3: Recover the tablespace RMAN> recover tablespace test; OR RMAN> recover datafile 'D:\APP\ANKESH\ORADATA\VDC11G\TEST01.DBF; P a g e 12
Recovering a block using RMAN Step 1: For the purpose, I have created a separate schema with a different default tablespace. Then created a table and inserted some dummy data in it. Schema Name: RMAN_TEST Tablespace Name: RMAN_TBS Table Name: TEST_BLOCK_RECOVER P a g e 13
Step 2: I took a full database backup using RMAN before I could play with the actual data. P a g e 14
Step 3: I took the RMAN_TBS tablespace offline. Step 4: Opened the datafile using Hex editor (You wouldn't be able to perform the same using Notepad or Word pad) and then tried finding the word Google. Step 5: I replaced G" of Google with T, so that it became Toogle. The purpose behind this was to corrupt at least one block to facilitate the demonstration. P a g e 15
Step 6: Brought back the RMAN_TBS tablespace online and tried querying the RMAN_TEST. TEST_BLOCK_RECOVER. Oops... ORA-01578 ORA-01110 was waiting for me. Step 7: Performed the basic diagnosis as we do in case of block corruption. First tried to find out to which segment this block belongs (With the help of absolute file number (AFN) and block number given in error message): So we're confirming that the corrupted block belongs to tablespace RMAN_TBS, segment type is TABLE, owner RMAN_TEST and the segment name TEST_BLOCK_RECOVER". P a g e 16
Step 8: I tried using DBVERIFY utility for verifying the same. Since this is a simulation therefore we know where the corruption exists, but in actual scenarios we will need these tools to perform the diagnostic. Step 9: Now the time is to calibrate the BLOCKRECOVER command of the RMAN utility, so tried recovering the block using command "RMAN> blockrecover datafile 7 block 134; The RMAN says the block has been recovered. I wouldn't believe unless and until I fire the same sql query and verify my data, right? So I did that... P a g e 17
my data is visible now, so I interpret that the block is recovered. P a g e 18