RMAN Recovery Scenarios Related To Database

RMAN Recovery All Scenarios (Santosh
Patil)
Recovery Scenarios Related To Database

RMAN performs backup and recovery tasks on the databases and automates
administration of the backup strategies. It greatly simplifies backing up, restoring,
and recovering database files.
Some of the database recovery scenarios are listed below.
Below cases are discussed in this post:
Case 1: all data files are lost
Case 2: few blocks in datafile got corrupted
Case 3: only one data file is lost/corrupted
Case 4: all datafiles of a tablespace got corrupted/lost
Case 5: spfile/pfile lost
RMAN Page 1
Patil)
Case 1: all data files are lost

Assumption:
 You have good backups of your database

 You have access to all redo archive files generated after the
backup was taken. You have all the redo required to recover
the database datafiles.
 You can perform a complete database-level recovery in this situation with
either the current control file or a backup control file.
I) Using current control file

In this situation, we simply start up the database in mount mode, issue the restore
and recover commands, and then open the database:
$ rman
Recovery Manager: Release 11.2.0.4.0 – Production on Mon Feb 24 10:04:14

2014
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights
reserved.
RMAN> connect target /
connected to target database (not started)
RMAN> startup mount

Oracle instance started database mounted
Total System Global Area 1068937216 bytes
Fixed Size 2260088 bytes

Variable Size 671089544 bytes
Database Buffers 390070272 bytes
Redo Buffers 5517312 bytes
RMAN> restore database;
Starting restore at 24-FEB-2014 10:04:47

using target database control file instead
of recovery catalog allocated channel:
ORA_DISK_1
channel ORA_DISK_1: SID=133 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
RMAN Page 2
Patil)
channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to
/u01/oracle/DB11G/oradata/brij/system01.dbf channel ORA_DISK_1: restoring
datafile 00002 to /u01/oracle/DB11G/oradata/brij/sysaux01.dbf channel
ORA_DISK_1: restoring datafile 00003 to
/u01/oracle/DB11G/oradata/brij/undotbs01.dbf
/u01/oracle/DB11G/oradata/brij/users01.dbf channel ORA_DISK_1: restoring
datafile 00005 to /u01/oracle/DB11G/oradata/brij/example01.dbf
channel ORA_DISK_1: reading from backup piece
/u01/oracle/DB11G/fast_recovery_area/BRIJ
/backupset/2014_02_20/o1_mf_nnndf_TAG20140220T140141_9jdyt91f_.bkp
channel ORA_DISK_1: piece
handle=/u01/oracle/DB11G/fast_recovery_area/BRIJ/backupset/2
014_02_20/o1_mf_nnndf_TAG20140220T140141_9jdyt91f_.bkp
tag=TAG20140220T140141 channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed
time: 00:01:45 Finished restore at 24-FEB-2014
10:06:35
RMAN> recover database;
Starting recover at 24-FEB-

2014 15:23:16 using channel
ORA_DISK_1
starting media recovery

media recovery complete, elapsed time: 00:00:09
Finished recover at 24-FEB-2014 15:23:26
RMAN> alter database open;
database opened
Note: Remember that RMAN will look in older backups if it can’t find a backup piece
or if corruption is detected. RMAN will search through backup history until it locates
a good backup or until it exhausts all possibilities. This feature is called restore
failover.
What about Read only and temporary tablespaces?
Read only tablespaces:
NOTE: By default, the restore command skips datafiles associated with read-only
tablespaces. If you want read-only tablespaces restored, then you must use the check
readonly command.
RMAN Page 3
Patil)
RMAN> restore database check readonly;
Temporary Tablespaces:
You don’t have to restore or re-create missing locally managed temporary
tablespace tempfiles. When you open your database for use, Oracle automatically
detects and re-creates locally managed temporary tablespace tempfiles.
If you wanna restore form some specific backups which you tagged:
RMAN> restore database from tag WEEKLY_BACK
How to use until clause with RMAN restores command
You can also tell RMAN to restore datafiles from a point in the past using the until
clause of the restore command in one of the following ways:
A) Until SCN
If you know the SCN in a backup piece that you want to restore from
Example:
RMAN> restore database until SCN 5634174;
B) Until sequence
If you know the log sequence number that you want to restore up to
RMAN> restore database until sequence 17;
C) Until restore point
If you’ve created restore points, then you can also use the restore point name
RMAN> restore database until restore point WEEKLY_BACK;
D) Until time
You can also specify a point in time from which you want RMAN to restore an
older backup. RMAN> restore database until time ‘sysdate – 5?;
RMAN> restore database until time “to_date(’08-jan-2014

13:00:00?, dd-mon-rrrr hh24:mi:ss’)”;
RMAN Page 4
Patil)
ii) Using backup control file

RMAN> startup nomount;
RMAN> restore controlfile from autobackup;
RMAN> alter database mount;
RMAN> restore database;
RMAN> recover database;
RMAN> alter database open resetlogs;
You are required to open your database with the open resetlogs command anytime
you use a backup control file during a recovery operation.
RMAN Page 5
Patil)
Case 2: few blocks in datafile are corrupt

There can be a corrupt block in a large datafile in your database which RMAN can
easily report. Now it would take significant effort and time to perform the traditional
restore and recover of a large datafile. So instead we will just recover the corrupt
block and not the entire datafile.
For Oracle Database 10g or Oracle9i Database, use the blockrecover command
to perform block media recovery.
As for Oracle Database 11g or newer, we will use the recover datafile … block
command as shown below:
ONLY FOR TESTING FIRST WE CREATED SOME DB BLOCK CORRUTION :)
SYS@brij > SELECT header_block FROM dba_segments WHERE segment_name=’EMP';
HEADER_BLOCK
————
146
$ dd of=/u01/oracle/DB11G/oradata/brij/users01.dbf bs=8192 conv=notrunc

seek=147 corruption test
> EOF
0+1 records in
0+1 records out
16 bytes (16 B) copied, 0.000159796 s, 100 kB/s
SYS@brij > ALTER SYSTEM FLUSH BUFFER_CACHE;

System altered.
SYS@brij > select * from scott.emp;

select * from scott.emp
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block
# 147) ORA-01110: data file 4:
‘/u01/oracle/DB11G/oradata/brij/users01.dbf’
RMAN Page 6
Patil)
A) CHECK CORRUPTION USING RMAN
RMAN will automatically detect corruption in blocks whenever a backup or backup

validate command is issued. These blocks are reported as corrupt in the alert.log file
and the V$DATABASE_BLOCK_CORRUPTION view.
Using RMAN command:
RMAN> backup validate database archivelog all;
File Status Marked Corrupt Empty Blocks Blocks Examined

High SCN —- —— ————– ———— ————— ———-
4 FAILED 0 18 667 1086086
File Name:
/u01/oracle/DB11G/oradata/brij/users01.dbf
Block Type Blocks Failing Blocks Processed
———- ————– —————-
Data 0 90
Index 0 39
Other 1 493
In Alert Log:
Wed Feb 26 13:53:28 2014

Hex dump of (file 4, block 147) in trace file
/
u01/oracle/DB11G/diag/rdbms/brij/brij/trace/b
rij_ora_6734.trc Corrupt block relative dba:
0x01000093 (file 4, block 147) Bad header
found during validation
Data in bad block:
type: 99 format: 7 rdba: 0x69747075
last change scn: 0x7365.74206e6f seq:
0x74 flg: 0x0a spare1: 0x72 spare2:
0x72 spare3: 0x0
consistency value in
tail: 0x0eef0602 check
value in block header:
0xb843 block checksum
disabled
Reread of blocknum=147, file=/u01/oracle/DB11G/oradata/brij/users01.dbf.
found same corrupt data
RMAN Page 7
Patil)
In V$DATABASE_BLOCK_CORRUPTION view:
RMAN backup populates V$DATABASE_BLOCK_CORRUPTION.
SYS@brij > select * from V$DATABASE_BLOCK_CORRUPTION;
FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO

———- ———- ———- —————— ———
4 147 1 0 CORRUPT
Using DBV:
$ dbv file=/u01/oracle/DB11G/oradata/brij/users01.dbf blocksize=8192
DBVERIFY: Release 11.2.0.4.0 – Production on Wed Feb 26 14:06:26 2014
reserved.
DBVERIFY – Verification starting : FILE =

/u01/oracle/DB11G/oradata/brij/users01.dbf Page 147 is marked
corrupt
Corrupt block relative dba: 0x01000093 (file 4, block 147)
Bad header found
during dbv: Data
in bad block:
type: 99 format: 7 rdba: 0x69747075
last change scn: 0x7365.74206e6f seq: 0x74 flg: 0x0a
spare1: 0x72 spare2: 0x72
spare3: 0x0 consistency
value in tail: 0x0eef0602
check value in block
header: 0xb843 block
checksum disabled
DBVERIFY – Verification complete
Total Pages Examined : 640

Total Pages Processed (Data) : 90
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 39
Total Pages Failing (Index): 0
Total Pages Processed (Other): 492
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 18
Total Pages Marked Corrupt : 1
Total Pages Influx : 0
RMAN Page 8
Patil)
Total Pages Encrypted : 0

Highest block SCN : 1086086 (0.1086086)
B) CORRECT DATA BLOCK CORRUPTION
Database can be in mounted or open when you are performing block-level

recovery. Also you do not have to take the datafile being recovered offline. Block-
level media recovery allows you to keep your database available hence reducing the
mean time to recovery since only the corrupt blocks are offline during the recovery.
RMAN CAN NOT perform block-level recovery on block 1 (datafile header) of the
datafile.
RMAN> recover datafile 4 block 147;

ORA_DISK_1
channel ORA_DISK_1: restoring block(s)

channel ORA_DISK_1: specifying block(s) to restore
from backup set restoring blocks of datafile 00004
channel ORA_DISK_1: reading from backup piece
/backupset/2014_02_26/o1_mf_nnndf_TAG20140226T134738_9jwr7wj3_.bkp
014_02_26/o1_mf_nnndf_TAG20140226T134738_9jwr7wj3_.bkp
tag=TAG20140226T134738 channel ORA_DISK_1: restored block(s) from backup
piece 1
channel ORA_DISK_1: block restore complete, elapsed time: 00:00:01

C) VERIFY
SYS@brij > select * from V$DATABASE_BLOCK_CORRUPTION;
no rows selected
SYS@brij > select * from scott.emp;
EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO

———- ———- ——— ———- ——— ———- ———- ———-
RMAN Page 9
Patil)
7369 SMITH CLERK 7902 17-DEC-80 800 20
Case 3: only one data file is lost

You have one datafile that has experienced media failure. You don’t want to restore
and recover the entire database or all datafiles associated with the tablespace. You
just want to restore and recover the datafile that experienced media failure.
In this example we lost /u01/oracle/DB11G/oradata/brij/users01.dbf
Scenario 1: database is not open
Here you restore/recover datafile from backup
A) CHECK IF YOU HAVE BACKUP PRESENT
RMAN> list backup;
using target dtabase control file instead of recovery catalog
List of Backup Sets

===================
BS Key Type LV Size Device Type Elapsed Time
Completion Time ——- —- — ———- ———– ———— ——————–
1 Full 1.10G DISK 00:01:51 10-FEB-2014 07:43:40
BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20140210T074149
Piece Name:
/u01/oracle/DB11G/fast_recovery_area/BRIJ/backupset/2014_02_10/o1_mf_nnnd
f_TAG20140210T074149_9hkwsydt_.bkp
List of Datafiles in backup set 1
File LV Type Ckp SCN Ckp
Time Name —- — —- ———-
——————– —-
1 Full 1104989 10-FEB-2014 07:41:50
/u01/oracle/DB11G/oradata/brij/system01.dbf 2 Full 1104989 10-
RMAN Page 10
Patil)
FEB-2014 07:41:50 /u01/oracle/DB11G/oradata/brij/sysaux01.dbf 3

Full 1104989 10-FEB-2014 07:41:50
/u01/oracle/DB11G/oradata/brij/undotbs01.dbf 4 Full 1104989 10-
FEB-2014 07:41:50 /u01/oracle/DB11G/oradata/brij/users01.dbf
5 Full 1104989 10-FEB-2014 07:41:50
/u01/oracle/DB11G/oradata/brij/example01.dbf
BS Key Type LV Size Device Type Elapsed Time

Completion Time ——- —- — ———- ———– ———— ——————–
2 Full 9.36M DISK 00:00:04 10-FEB-2014 07:43:49
BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20140210T074149
Piece Name:
/u01/oracle/DB11G/fast_recovery_area/BRIJ/backupset/2014_02_10/o1_mf_ncsnf
_TAG20140210T074149_9hkwxnn9_.bkp
SPFILE Included: Modification time: 10-
FEB-2014 07:41:01 SPFILE db_unique_name:
BRIJ
Control File Included: Ckp SCN: 1105044 Ckp time: 10-FEB-2014 07:43:45
B) MOUNT DATABASE
$ rman
Recovery Manager: Release 11.2.0.4.0 – Production on Tue 04-MAR-2014

14:39:39
reserved.
RMAN> startup mount;
Oracle
instance
started
database
mounted

RMAN Page 11
Patil)
C) RESTORE DATAFILE
RMAN> restore datafile 4;
Starting restore at 04-MAR-

2014 14:41:11 allocated
channel: ORA_DISK_1

/u01/oracle/DB11G/oradata/brij/users01.dbf channel ORA_DISK_1: reading from
backup piece /u01/oracle/DB11G/fast_recovery_area/BRIJ
/backupset/2014_03_04/o1_mf_nnndf_TAG20140304T143708_9kdodwo1_.bkp
014_03_04/o1_mf_nnndf_TAG20140304T143708_9kdodwo1_.bkp
time: 00:00:01 Finished restore at 04-MAR-2014
14:41:14
D) RECOVER DATAFILE
RMAN> recover datafile 4;
Starting recover at 04-MAR-

ORA_DISK_1

Finished recover at 04-MAR-2014 14:41:51
E) OPEN DATABASE
database opened
RMAN Page 12
Patil)
Scenario 2: database is open
Scenario 2 case 1: Datafile image copy from FRA
Here we will use datafile image copy from Flash Recovery Area (FRA), if it is enabled.
This is FASTER WAY to recover a datafile.
A) check present files of the database:
RMAN> report schema;
using target database control file instead of recovery catalog

Report of database schema for database with db_unique_name BRIJ
List of Permanent Datafiles

===========================
File Size(MB) Tablespace RB segs
Datafile Name —- ——– ——————– ——-
————————
1 760 SYSTEM *** /u01/oracle/DB11G/oradata/brij/system01.dbf
2 560 SYSAUX *** /u01/oracle/DB11G/oradata/brij/sysaux01.dbf
3 100 UNDOTBS1 *** /u01/oracle/DB11G/oradata/brij/undotbs01.dbf
4 5 USERS *** /u01/oracle/DB11G/oradata/brij/users01.dbf
5 341 EXAMPLE *** /u01/oracle/DB11G/oradata/brij/example01.dbf
So ‘users’ datafile is file#4 and we are assuming that this file got damaged somehow.
B) Check image copies of the damaged datafile:
RMAN Page 13
Patil)
In our scenario datafile 4 is damaged.
RMAN> list copy of datafile 4;
List of Datafile Copies
=======================
Key File S Completion Time Ckp SCN

Ckp Time ——- —- – ——————– ———-
——————–
6 4 A 10-FEB-2014 12:05:11 1119428 10-FEB-2014 12:05:10
Name:
/u01/oracle/DB11G/fast_recovery_area/BRIJ/datafile/o1_mf_users_9hld7pv8_.db
f Tag: TAG20140210T120249
C) Take ‘damaged’ datafile ‘offline’
RMAN> sql ‘alter database datafile 4 offline';
sql statement: alter database datafile 4 offline
D) Switch to the copy of the file in the FRA
RMAN> switch datafile 4 to copy;
datafile 4 switched to datafile copy

“/u01/oracle/DB11G/fast_recovery_area/BRIJ/datafile/o1_mf_users_9hld
7pv8_.dbf”
E) Recover the datafile copy and make it online

2014 10:36:39 allocated
channel: ORA_DISK_1

RMAN> sql ‘alter database datafile 4 online';
RMAN Page 14
Patil)
sql statement: alter database datafile 4 online
F) Check the datafiles once again:

===========================
Datafile Name —- ——– ——————– ——-
————————
4 5 USERS ***
/
u01/oracle/DB11G/fast_recovery_area/BRIJ/datafile/o1_mf_users_
9hld7pv8_.dbf 5 341 EXAMPLE ***
You see the database is now using file#4 from the flash recovery area
AT THIS STAGE DATAFILE IS ONLINE AND DATABASE CAN BE USED

NORMALLY.
When you bring the datafile back online, the tablespace will be brought online as
well. The tablespace is now operational. But we don’t want to leave the database
using a file in the flash recovery area, though, especially not for the long term.
BELOW STEPS ARE ADVISED TO BE DONE CAN BE DONE LATER ON (say

weekend or off-business hours)
In below steps we will move back the data file to its original location.
G) Remove the ‘original damaged’ file at the OS level from the

original location, if present
$ /u01/oracle/DB11G/oradata/brij
$ mv users01.dbf users01.dbf.bkp
RMAN Page 15
Patil)
H) Create an image copy of the file & place it in the file’s original location
RMAN> backup as copy datafile 4 format

‘/u01/oracle/DB11G/oradata/brij/users01.dbf';
Starting backup at 11-FEB-

ORA_DISK_1
channel ORA_DISK_1: starting
datafile copy input datafile
file number=00004
name=/u01/oracle/DB11G/fast_recovery_area/BRIJ/datafile/o1_mf_users_9
hld7pv8_.dbf output file
name=/u01/oracle/DB11G/oradata/brij/users01.dbf
tag=TAG20140211T104743 RECID=12 STAMP=839242064
channel ORA_DISK_1: datafile copy complete, elapsed
time: 00:00:01 Finished backup at 11-FEB-2014
10:47:45
Starting Control File and SPFILE Autobackup at 11-FEB-2014 10:47:45

piece
handle=/u01/oracle/DB11G/fast_recovery_area/BRIJ/autobackup/2014_02_11/o1_m
f_s_ 839242065_9hnw2kwm_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 11-FEB-2014 10:47:48
I) Take the datafile offline:
RMAN> sql ‘alter database datafile 4 offline';
sql statement: alter database datafile 4 offline
J) Switch to the copy of the file
RMAN> switch datafile 4 to copy;
datafile 4 switched to datafile copy

“/u01/oracle/DB11G/oradata/brij/users01.dbf”
K) Recover the datafile copy and make it online

ORA_DISK_1
RMAN Page 16
Patil)

RMAN> sql ‘alter database datafile 4 online’;
sql statement: alter database datafile 4 online
L) Check the datafiles once again:

===========================
Datafile Name —- ——– ——————– ——-
————————
4 5 USERS *** /u01/oracle/DB11G/oradata/brij/users01.dbf
5 341 EXAMPLE *** /u01/oracle/DB11G/oradata/brij/example01.dbf
so datafile 4 is now back to its standard location.
As a best practice, you should now create a fresh image copy of the file and place it in
the flash recovery area:
RMAN> backup as copy datafile 4;
Starting backup at 11-FEB-

ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
input datafile file number=00004
name=/u01/oracle/DB11G/oradata/brij/users01.dbf output file
name=/u01/oracle/DB11G/fast_recovery_area/BRIJ/datafile/o1_mf_users_9h
nwcnbc_.dbf tag=TAG20140211T105236 RECID=14 STAMP=839242356
channel ORA_DISK_1: datafile copy complete, elapsed

time: 00:00:01 Finished backup at 11-FEB-2014
10:52:37
Starting Control File and SPFILE Autobackup at 11-FEB-2014 10:52:37
RMAN Page 17
Patil)
piece
handle=/u01/oracle/DB11G/fast_recovery_area/BRIJ/autobackup/2014_02_11/o1_m
f_s_ 839242357_9hnwcp10_.bkp comment=NONE
Finished Control File and SPFILE Autobackup at 11-FEB-2014 10:52:40
Scenario 2 CASE 2: Datafile restore from backup
For non-system and non-undo datafiles, you have the option of keeping the database
open while performing the recovery. When your database is open, you’re required to
take offline any datafiles you’re attempting to restore and recover.
$ RMAN
Recovery Manager: Release 11.2.0.4.0 – Production on Wed Feb 26 11:09:19

2014
reserved.
connected to target database: BRIJ

(DBID=1279650270) connected to recovery
catalog database
RMAN Page 18
Patil)
RMAN> sql “alter database datafile

”/u01/oracle/DB11G/oradata/brij/users01.dbf” offline”;
sql statement: alter database datafile

”/u01/oracle/DB11G/oradata/brij/users01.dbf” offline
RMAN> restore datafile ‘/u01/oracle/DB11G/oradata/brij/users01.dbf';
Starting restore at 26-FEB-

2014 11:10:13 allocated
channel: ORA_DISK_1

/u01/oracle/DB11G/oradata/brij/users01.dbf channel ORA_DISK_1: reading from
backup piece /u01/oracle/DB11G/fast_recovery_area/BRIJ
/backupset/2014_02_26/o1_mf_nnndf_TAG20140226T100410_9jwc4yg2_.bkp
014_02_26/o1_mf_nnndf_TAG20140226T100410_9jwc4yg2_.bkp
11:10:18
RMAN> recover datafile ‘/u01/oracle/DB11G/oradata/brij/users01.dbf';

ORA_DISK_1

RMAN> sql “alter database datafile

”/u01/oracle/DB11G/oradata/brij/users01.dbf” online”;
sql statement: alter database datafile

”/u01/oracle/DB11G/oradata/brij/users01.dbf” online
NOTE: When using the RMAN sql command, if there are single quote marks within
the SQL statement, then you are required to use double quotes to enclose the entire
SQL statement and then also use two single quote marks where you would ordinarily
just use one quote mark.
RMAN Page 19
Patil)
If you want to put the restored datafile to new location, use below RMAN commands
instead
RMAN>run
{
sql “alter database datafile
”/u01/oracle/DB11G/oradata/brij/users01.dbf” offline”; set newname
for datafile ‘/u01/oracle/DB11G/oradata/brij/users01.dbf’ to
‘/backups/users01.dbf';
restore datafile
‘/u01/oracle/DB11G/oradata/brij/users01.dbf';
switch datafile all;
recover datafile ‘/backups/users01.dbf';
sql “alter database datafile ”/backups/users01.dbf” online”;
}
Remember that set command needs to be used inside a run block
SYS@brij > select file_name from dba_data_files;
FILE_NAME
——————————————————–
/u01/oracle/DB11G/oradata/brij/users02.dbf
/u01/oracle/DB11G/oradata/brij/system02.dbf
/backups/users01.dbf
/u01/oracle/DB11G/oradata/brij/sysaux01.dbf
/u01/oracle/DB11G/oradata/brij/system01.dbf
8 rows selected.
Case 4: all datafiles of a tablespace got

corrupted/lost
One of the tablespace is giving errors. the tablespace has multiple datafiles and
all got corrupted.
If only one datafiles had error, we would have gone for datafile level recovery but
since all datafiles associated with have corruption so it is better to go for tablespace
level recovery.
Scenario 1: Database NOT Open

This solution works for any tablespace in your database (including system and undo
tablespaces).
RMAN Page 20
Patil)
In this example, we are restoring the user’s tablespace:
There are two data files in this tablespace and both got corrupted somehow.
datafile file number=00006 name=C/users02.dbf

datafile file number=00004 name=/u01/oracle/DB11G/oradata/brij/users01.dbf
Below were the errors that were encountered in alert log because of this corruption:
Wed Feb 26 10:16:49 2014
Read of datafile ‘/u01/oracle/DB11G/oradata/brij/users01.dbf’ (fno 4)

header failed with
ORA-01210
Hex dump of (file 4, block 1) in trace file
/u01/oracle/DB11G/diag/rdbms/brij/brij/trace/brij_or
a_4138.trc
Corrupt block relative dba: 0x01000001 (file
4, block 1) Bad header found during datafile
header read
Data in bad block:
type: 0 format: 0 rdba: 0xa20b0000
last change scn: 0x0100.00010000 seq: 0x0
flg: 0x00 spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail:
0x00000000 check value in
block header: 0x0 block
checksum disabled
Rereading datafile 4 header failed with ORA-01210
ORA-01122: database file 4 failed verification check

ORA-01110: data file 4:
‘/u01/oracle/DB11G/oradata/brij/users01.dbf’ ORA-01210: data
file header is media corrupt
Database was shutdown before correcting the corruption.
$ RMAN

2014
reserved.
connected to target database (not

started) connected to recovery
catalog database
RMAN Page 21
Patil)
RMAN> startup mount
Oracle instance started

database mounted

RMAN> restore tablespace users;

2014 10:20:10 allocated
channel: ORA_DISK_1

datafile 00006 to /u01/oracle/DB11G/oradata/brij/users02.dbf channel
ORA_DISK_1: reading from backup piece
10:20:27
RMAN> recover tablespace users;

ORA_DISK_1

RMAN Page 22
Patil)
database opened
Scenario 2: Database is Open
Sometimes it is not possible to take the database down. You can take a tablespace
offline, restore, and recover it while your database is open. This works for any
tablespace except the system and undo tablespaces.
This example takes users offline and then restores and recovers before bringing it
back online:
RMAN Page 23
Patil)
Here also we got the same error in users tablesace as showin in scenario 1 forcing us
to go for restore/recover of users tabespace.
$ RMAN

2014
reserved.
connected to target database: BRIJ

(DBID=1279650270) connected to recovery
catalog database
RMAN> SQL ‘ALTER TABLESPACE USERS OFFLINE IMMEDIATE';
sql statement: ALTER TABLESPACE USERS OFFLINE IMMEDIATE
RMAN> RESTORE TABLESPACE USERS;

2014 10:32:25 allocated
channel: ORA_DISK_1

datafile 00006 to /u01/oracle/DB11G/oradata/brij/users02.dbf channel
ORA_DISK_1: reading from backup piece
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
Finished restore at 26-FEB-2014 10:32:29
RMAN> RECOVER TABLESPACE USERS;

ORA_DISK_1
RMAN Page 24
Patil)
RMAN> sql ‘alter tablespace users online';
sql statement: alter tablespace users online
Below is how alert log will record above recovery activity
Wed Feb 26 10:32:12 2014

ALTER TABLESPACE USERS OFFLINE IMMEDIATE Completed:
ALTER TABLESPACE USERS OFFLINE IMMEDIATE Wed Feb 26
10:32:29 2014
Full restore complete of datafile 6
/u01/oracle/DB11G/oradata/brij/users02.dbf. Elapsed time: 0:00:00
checkpoint is 1349054
last deallocation scn is 925704
Full restore complete of datafile 4
/u01/oracle/DB11G/oradata/brij/users01.dbf. Elapsed time: 0:00:02
checkpoint is
1349054 last
deallocation scn
is 3 Wed Feb 26
10:32:38 2014
alter database recover datafile list
clear Completed: alter database
recover datafile list clear alter
database recover if needed
tablespace USERS Media Recovery Start
Serial Media Recovery started
Recovery of Online Redo Log: Thread 1 Group 5 Seq 5 Reading mem 0
Mem# 0: /u01/oracle/DB11G/oradata/BRIJ/onlinelog/o1_mf_5_9hl934pt_.log
Mem# 1:
/u01/oracle/DB11G/fast_recovery_area/BRIJ/onlinelog/o1_mf_5_9hl934xp_.l
og Recovery of Online Redo Log: Thread 1 Group 6 Seq 6 Reading mem 0
Mem# 0: /u01/oracle/DB11G/oradata/BRIJ/onlinelog/o1_mf_6_9hl972k3_.log
Mem# 1:
/u01/oracle/DB11G/fast_recovery_area/BRIJ/onlinelog/o1_mf_6_9hl972tr_
.log Recovery of Online Redo Log: Thread 1 Group 4 Seq 7 Reading mem
0
Mem# 0: /u01/oracle/DB11G/oradata/BRIJ/onlinelog/o1_mf_4_9hl96kyw_.log
Mem# 1:
/u01/oracle/DB11G/fast_recovery_area/BRIJ/onlinelog/o1_mf_4_9hl96l67_.
log Media Recovery Complete (brij)
Completed: alter database
recover if needed tablespace
USERS
Wed Feb 26
10:33:04 2014
RMAN Page 25
Patil)
alter tablespace
users online
Completed: alter tablespace users online
Case 5: spfile/pfile lost

Sometimes spfile gets accidentally deleted or you are not able to open database using
current spfile
RMAN Page 26
Patil)
Scenario 1: Using a Recovery Catalog
We will start Oracle instance without parameter file for retrieval of spfile
[stextbox id="grey"]
$ RMAN

2014
reserved.
connected to target database

(not started) connected to
recovery catalog database
RMAN> startup nomount
startup failed: ORA-01078: failure in processing

system parameters LRM-00109: could not open
parameter file
‘/u01/oracle/DB11G/product/11.2.0/dbhome_1/dbs/ini
tbrij.ora’
starting Oracle instance without parameter file

for retrieval of spfile Oracle instance started

RMAN> restore spfile;

2014 14:56:46 allocated
channel: ORA_DISK_1
channel ORA_DISK_1: starting datafile

backup set restore channel ORA_DISK_1:
restoring SPFILE
output file
name=/u01/oracle/DB11G/product/11.2.0/dbhome_1/dbs/spfilebrij.
RMAN Page 27
Patil)
ora channel ORA_DISK_1: reading from backup piece

/backups/brij/controlfile_brij_c-1279650270-20140226-06
channel ORA_DISK_1: piece handle=/backups/brij/controlfile_brij_c-
1279650270-20140226-06 tag=TAG20140226T134919
channel ORA_DISK_1: restored backup piece 1
14:56:48
RMAN> startup force;


Scenario 2: Not Using a Recovery Catalog
RMAN Page 28
Patil)
Here you must tell the DBID of database to RMAN process.
$ rman

2014
reserved.
RMAN> set dbid 1279650270;
executing command: SET DBID
RMAN> startup force nomount;
startup failed: ORA-01078: failure in processing

system parameters LRM-00109: could not open parameter
file
‘/u01/oracle/DB11G/product/11.2.0/dbhome_1/dbs/initbr
ij.ora’
starting Oracle instance without parameter file for

retrieval of spfile Oracle instance started

RMAN> restore spfile from ‘/backups/brij/controlfile_brij_c-1279650270-

20140226-06?;

ORA_DISK_1
channel ORA_DISK_1: restoring spfile from AUTOBACKUP

/backups/brij/controlfile_brij_c-1279650270-20140226-06
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP
complete Finished restore at 26-FEB-2014 15:04:33
RMAN> startup force;
RMAN Page 29
Patil)

NOTE: If our spfile autobackup was in default location, we could have used
below command:
RMAN> restore spfile from autobackup;
RMAN Page 30

RMAN Recovery Scenarios Related To Database

Uploaded by

Copyright:

Available Formats

RMAN Recovery Scenarios Related To Database

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RMAN Recovery Scenarios Related To Database

Uploaded by

Copyright:

Available Formats

RMAN Recovery All Scenarios (Santosh

Recovery Scenarios Related To Database

Some of the database recovery scenarios are listed below.

Below cases are discussed in this post:

Case 1: all data files are lost

Case 2: few blocks in datafile got corrupted

Case 3: only one data file is lost/corrupted

Case 4: all datafiles of a tablespace got corrupted/lost

Case 5: spfile/pfile lost

Case 1: all data files are lost

 You have good backups of your database

I) Using current control file

Recovery Manager: Release 11.2.0.4.0 – Production on Mon Feb 24 10:04:14

RMAN> connect target /

connected to target database (not started)

RMAN> startup mount

Total System Global Area 1068937216 bytes

Fixed Size 2260088 bytes

RMAN> restore database;

Starting restore at 24-FEB-2014 10:04:47

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

RMAN> recover database;

Starting recover at 24-FEB-

starting media recovery

Finished recover at 24-FEB-2014 15:23:26

RMAN> alter database open;

What about Read only and temporary tablespaces?

Read only tablespaces:

RMAN> restore database check readonly;

RMAN> restore database from tag WEEKLY_BACK

How to use until clause with RMAN restores command

RMAN> restore database until SCN 5634174;

RMAN> restore database until sequence 17;

C) Until restore point

RMAN> restore database until restore point WEEKLY_BACK;

RMAN> restore database until time “to_date(’08-jan-2014

ii) Using backup control file

RMAN> connect target /

Case 2: few blocks in datafile are corrupt

SYS@brij > SELECT header_block FROM dba_segments WHERE segment_name=’EMP';

$ dd of=/u01/oracle/DB11G/oradata/brij/users01.dbf bs=8192 conv=notrunc

SYS@brij > ALTER SYSTEM FLUSH BUFFER_CACHE;

SYS@brij > select * from scott.emp;

A) CHECK CORRUPTION USING RMAN

RMAN will automatically detect corruption in blocks whenever a backup or backup

Using RMAN command:

RMAN> backup validate database archivelog all;

File Status Marked Corrupt Empty Blocks Blocks Examined

Wed Feb 26 13:53:28 2014

RMAN backup populates V$DATABASE_BLOCK_CORRUPTION.

SYS@brij > select * from V$DATABASE_BLOCK_CORRUPTION;

FILE# BLOCK# BLOCKS CORRUPTION_CHANGE# CORRUPTIO

$ dbv file=/u01/oracle/DB11G/oradata/brij/users01.dbf blocksize=8192

DBVERIFY: Release 11.2.0.4.0 – Production on Wed Feb 26 14:06:26 2014

DBVERIFY – Verification starting : FILE =

DBVERIFY – Verification complete

Total Pages Examined : 640