Backup Procedures

Published on May 2016 | Categories: Documents | Downloads: 40 | Comments: 0 | Views: 632
of 247
Download PDF   Embed   Report

Comments

Content

1

ORACLE BACKUP STRATEGIES

BACKUP PROCEDURES
It is a very important aspect of any database which should be planned carefully as recovery depends
upon the back up strategy which are being followed. Backup strategy depends upon the mode of
database. Different methods are adopted for the database running in archivelog mode or database
running in no-archivelog mode .
Criteria:
[1] When database is running in archive-log mode.

1.Cold backup:
In init.ora, search for parameter control_files to find the name of control file for that database. Query
the v$datafiles and v$logfiles views to find the names of datafiles and redo logfiles associated with the
database. Use the operating system command to take the backup of these files. * In init.ora, search
for parameter log_archive_dest to find the location of archived files. Use the operating system
command to take the backup of these files.
Frequency: This backup has to be taken weekly.
Only Oracle database related file should be backedup. It will solve two problems
[a] Downtime of database will be less.
[b] Retrieval from cartridge will take less time.
[c] Less numbers of cartridges will be required.
File System Backup : Generally its frequency should be low. It will act as a backup for all the files
(Oracle+O.S.+Other). It will be needed if all the disks crash. If you are creating important files on
server then its frequency should be increased as decided by the site incharge.

2.Hot backup:
In init.ora, search for parameter control_files to find the name of control file for that database. Query
the v$datafiles views to find the names of datafiles associated with the database. Use the operating
system command to take the backup of these files.* In init.ora, search for parameter log_archive_dest
to find the location of archived files. Use the operating system command to take the backup of these
files. *

2

ORACLE BACKUP STRATEGIES

Frequency: This backup has to be taken daily.

3.Logical Backup:
[1] Ideally Complete database export should be taken daily.
It is also called base backup.
[2] Take incremental export daily except on weekends.
On weekends, cumulative database export should be taken. When cumulative export is taken, one
should remove incremental export to save space on disk.
On month end, take complete database export and remove previously stored cumulative export logical
backups.
[3] Take important user level export daily.
Either of the above option can be implemented at the site but order of prefrence should be first try
[1], if not then use [2] else last option should be [3]

Cartridges Strategy:
If you are taking complete database export then use three different sets of cartridges ( Grandfather ,
Father and Son concepts .) on three different days . And rotate these cartridges again .
For Incremental Backups use six different sets of cartridges on six different days . And rotate these
cartridges again after successfully completion of Cumulative database export backup .
For Cumulative Backups use different cartridges in every week and rotate those cartridges in the next
month after successfully completion of Complete database export backup.
Recovery:
In day to day operation the most common type of failure is table drop or partial data loss in any table
or instance failure. Using export backed up dump file (expdat.dmp) one can recover first two type of
problems.

3

ORACLE BACKUP STRATEGIES

For instance failure, simply restart the database, oracle will automatically recover the database
(Instance recovery).
For more complicated type of problems like media crash (data file loss etc.), please refer to annexure1.
[2] When database is running in no archive-log mode.

Cold backup :
In init.ora, search for parameter control_files to find the name of control file for that database. Query
the v$datafiles and v$logfiles views to find the names of datafiles and redo logfiles associated with the
database. Use the operating system command to take the backup of these files. Ideally this backup
should be taken daily.
Logical Backup:
[1] Ideally Complete database export should be taken daily.
It is also called base backup.
[2] Take incremental export daily except on weekends.
On weekends, cumulative database export should be taken. When cumulative export is taken, one
should remove incremental export to save space on disk.
On month end, take complete database export and remove previously stored cumulative export logical
backups.
[3] Take important user level export daily.
Either of the above option can be implemented at the site but order of prefrence should be first try
[1], if not then use [2] else last option should be [3]
Cartridges Strategy :
If you are taking complete database export then use three different sets of cartridges ( Grand father ,
Father and Son concepts .) on three different days . And rotate these cartridges again .

4

ORACLE BACKUP STRATEGIES

For Incremental Backups use six different sets of cartridges on six different days . And rotate these
cartridges again after successfully completion of Cummulative database export backup .
For Cummulative Backups use different cartridges in every week and rotate those cartridges in the
next month after successfully completion of Complete database export backup.

Recovery :
It is a very important process and it should be done very carefully. In day to day operation the most
common type of failure is table drop or partial data loss in any table or instance failure. Using export
backed up dump file (expdat.dmp) one can recover first two type of problems. For instance failure,
simply restart the database, oracle will automatically recover the database (Instance recovery). For
more complicated type of problems like media crash (data file loss etc.), please refer to annexure-1.
* Commands to be used in copying file(s) to backup device :
In Unix :
[a] cpio -ocBv < [name of file] > [/dev/rmt0.1|/dev/rmt0]
or
find / -name [pattern] -depth -print|cpio -ocBv > [/dev/rmt0.1|/dev/rmt0]
[b] tar -cvf [name of file] > [/dev/rmt0.1|/dev/rmt0]
or
tar -cvf /
Complete file system backup :
In Unix :
[a] find / -name -depth -print|cpio -ocBv > [/dev/rmt0.1|/dev/rmt0]
or
[b] To copy all files of unix to backup device
tar -cvf /

5

ORACLE BACKUP STRATEGIES

In Window NT :
Use backup utility to copy the necessary files.
Commands to be used in restoring file(s) from backup device :
In Unix :
[a] cpio -icBv < [/dev/rmt0.1|/dev/rmt0]
or
cpio -icBv “[pattern]” < [/dev/rmt0.1|/dev/rmt0]
[b] tar -xvf < [/dev/rmt0.1|/dev/rmt0]

Annexure – 1
1. LOSS OF NON-ESSENTIAL DATAFILE WHEN DATABASE IS DOWN
( DATABASE CAN BE IN ARCHIVELOG MODE OR NO ARCHIVELOG
MODE )
SCENARIO
[1] Database startup fails with errors :
ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing.
REQUIREMENT
[1] The script which will recreate the objects in the datafile like script which will create indexex.
TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN (5 MIN+ TIME TAKEN TO CREATE INDEXES)
NON-ESSENTIAL DATAFILES
DATAFILE OF INDEX TABLESPACE, TEMPORARY TABLESPACE.
SOLUTION
Shutdown the database.(shutdown immediate).
Take complete backup of current database.
Startup mount

6

ORACLE BACKUP STRATEGIES

Query the v$recover_file view along with v$datafile with a join on file# and note down the name of file
say it is /prodebs/test/ind.dbf.
Alter database datafile ‘/prodebs/test/ind.dbf’ offline;
(if database is in noarchivwlog mode command will be
Alter database datafile ‘/prodebs/test/ind.dbf’ offline drop; )
Alter database open;
Drop tablespace user_index including contents;
Create tablespace user_index
datafile ‘/prodebs/test/ind.dbf’ size 1M;
Run the script which will built indexes*.
Shutdown the database and take backup if necessary.
Startup.
* NB : For temporary tablespace skip this step.
2. MISSING MIRRORED ONLINE REDO LOG FILES (DATABASE IS UP/DOWN)
SCENARIO
Database opens neatly but in alert log two error messages are logged with errors :
(error from lgwr. Error is also written in lgwr trace file)
ora 313 open failed for members ..
ora 312 name of redo log memeber missing
ora 7360 OS error
ora 321 Can not update logfile header
TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN 5 MIN.
SOLUTION
Shutdown the database.(shutdown).
Startup mount
Query v$logfile view and find which member has become invalid.
Query v$log view and find which group is current and size of group members (say it is b).
If the member of current log group (say it is 1) is corrupted issue the following commands :
Alter system switch logfile
If you can add one more member to corrupted log group ie maximum log member is not reached add

7

ORACLE BACKUP STRATEGIES

one more
member to that group
Alter database add logfile member ‘filespec’ to group 1;
Shutdown the database
Startup the database
If you can not add one more member to corrupted log group
create one more log group with equal members and size of non corrupted log group.
Alter database group 3 (‘filespec’,'filespec’) size b;
Drop corrupted log group.
alter database drop logfile group 1;
Manually remove other members of this corrupted log group (ie rm in unix)
Shut down the database
Startup the database
3. RECOVER A LOST DATAFILE WITH NO BACKUP AND ALL ARCHIVED LOG FILES
SCENARIO
Database startup fails with errors :
ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing.
REQUIREMENT
For full recovery, database should be in archivelog mode.
TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN MIN 10 mins.
SOLUTION
Shutdown the database.(shutdown).
Startup mount;
Query v$recover_file
Query v$datafile and find the name of datafile which is missing.(say it is ‘/prodebs/test/user_odc.dbf’)
Now issue the following commands in the given order :
alter database datafile ‘/prodebs/test/user_odc.dbf’ offline;
alter database create datafile ‘/prodebs/test/user_odc.dbf’ as ‘/prodebs/test/user_odc1.dbf’;
(removed file) (new file)

8

ORACLE BACKUP STRATEGIES

alter database datafile ‘/prodebs/test/user_odc1.dbf’ online;
alter database recover datafile ‘/prodebs/test/user_odc1.dbf’; or recover database
It will generally recover the database if you have all the archived file with you
alter database open;
Shutdown the database and take necessary backup if required.
Start the database.

4. RECOVER A LOST DATAFILE WITH BACKUP AND ALL ARCHIVED LOG FILES
SCENARIO
Database startup fails with errors :
ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing.
REQUIREMENT
For full recovery, database should be in archivelog mode.
TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN 5 mins.
SOLUTION
Shutdown the database.(shutdown).
Startup mount;
Query v$recover_file
Query v$datafile and find the name of datafile which is missing.(say it is ‘/prodebs/test/user_odc.dbf’)
Copy the archived datafile (old one that is in backup) and give following commands :
recover database;
alter database open;
Shutdown the database and take necessary backup if required.
Start the database.
5. RECOVER A LOST DATAFILE WITH BACKUP AND MISSING ARCHIVED LOG FILES.
SCENARIO
Database startup fails with errors :

9

ORACLE BACKUP STRATEGIES

ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing.
REQUIREMENT
For recovery, database should be in archivelog mode.
CONDITION
Recovery will be incomplete.
TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN MIN 10 mins.
SOLUTION
Shutdown the database.(shutdown).
Copy all your datafiles from backup except control file.
Startup mount;
Copy the archived datafile (old one that is in backup) and give following commands :
recover database until cancel
alter database open resetlogs;
Shutdown the database and take necessary backup if required.
Start the database.
6. LOSS OF DATAFILE WHEN THE DATABASE IS IN NOARCHIVELOG MODE WITH NO
LOGICAL BACKUP AND RECOVERY.
SCENARIO
Database startup fails with errors : (a) on monday morning (b) on thursday
ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing and found to be user data file.
There is no export and import backup (Logical backup).
Cold backup is taken once in every week . Here backup is taken on every sunday and this is the last
activity
on sunday.
Problem has occured on (a) on monday morning (b) on thursday.
Here data file (s) associated with user tablespace is (are) lost.

10

ORACLE BACKUP STRATEGIES

TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN MIN 30 mins.
SOLUTION when Problem has occured on (a) on monday morning
Shutdown the database.(shutdown).
Take complete backup of current database.
Delete all the database files, redo log files and control files.
Copy the all the database files , redo log files and control files from the backup.
Start the database. There is no data loss.
SOLUTION when Problem has occured on (a) on thursday morning. Here data loss will occur.
Shutdown the database.(shutdown).
Take complete backup of current database.
Delete all the database files, redo log files and control files.
Copy the all the database files , redo log files and control files from the backup.
Start the database. There is data loss for monday, tuesday and wednessday.
Ask user to reenter the data.
7. LOSS OF DATAFILE WHEN THE DATABASE IS IN NOARCHIVELOG MODE WITH LOGICAL
BACKUP AND RECOVERY.
SCENARIO
Database startup fails with errors on thursday morning.
ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing and found to be user data file.
There is export and import backup. (Logical backup).
Strategy : So along with coldback up a complete database backup is also taken.
(i) After this on everyday, an incremental backup is also taken.
(ii) After this on everyday, complete database backup is also taken.
Cold backup is taken once in every week . Here backup is taken on every sunday and this is the last
activity
on sunday.
Here data file (s) associated with user tablespace is (are) lost.

11

ORACLE BACKUP STRATEGIES

TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN MIN 30 mins.
[i] SOLUTION when Problem has occured on thursday morning and incremental backup is taken.
Shutdown the database.(shutdown).
Take complete backup of current database.
Delete all the database files, redo log files and control files.
Copy the all the database files , redo log files and control files from the backup.
Start the database.
Apply incremental export using import file starting from monday to wednesday.There is no data loss.
[ii] SOLUTION when Problem has occured on thursday morning and daily complete database logical
backup is taken.
Shutdown the database.(shutdown).
Take complete backup of current database.
Delete all the database files, redo log files and control files.
Copy the all the database files , redo log files and control files from the backup.
Start the database.
Apply wednesday complete export backup. There is no data loss.
8. LOSS OF SYSTEM DATAFILE WHEN THE DATABASE IS IN ARCHIVE LOG MODE AND
RECOVERY.
SCENARIO
Database startup fails with errors on thursday morning.
ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing and found to be user data file.
Cold backup is taken once in every week . Here backup is taken on every sunday and this is the last
activity
on sunday.
Here data file (s) associated with system tablespace is (are) lost.
TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN MIN 30 mins.

12

ORACLE BACKUP STRATEGIES

SOLUTION
Shutdown the database.(shutdown).
Take complete backup of current database.
Copy the missing system database file(s).
Startup mount exclusive;
recover database;
alter database open;
Database is ready for use.
9. LOSS OF NON SYSTEM DATAFILE WITHOUT ROLLBACK SEGMENTS WHEN THE DATABASE
IS IN ARCHIVE LOG MODE AND RECOVERY.
SCENARIO
Database startup fails with errors on thursday morning.
ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing and found to be user data file.
Cold backup is taken once in every week . Here backup is taken on every sunday and this is the last
activity
on sunday.
Here data file (s) associated with user tablespace is (are) lost.
TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN MIN 30 mins.
SOLUTION -1 (DATABASE RECOVERY)
Shutdown the database.(shutdown).
Take complete backup of current database.
Copy the missing database file(s).
Startup mount exclusive;
recover database;
alter database open;
Database is ready for use.
SOLUTION -2 (DATAFILE RECOVERY)*

13

ORACLE BACKUP STRATEGIES

Shutdown the database.(shutdown).
Take complete backup of current database.
Copy the missing database file(s).
Startup mount exclusive;
Alter database datafile ” offline;
Alter database open;
recover datafile ”
Alter database datafile ” online;
Database is ready for use.
* If multiple datafiles are lost use parallel recovery method (from muliple terminal use the same
method for different files).
SOLUTION -3 (TABLESPACE RECOVERY)
Shutdown the database.(shutdown).
Take complete backup of current database.
Copy the missing database file(s).
Startup mount exclusive;
Alter database datafile ” offline;
Alter database open;
Alter tablespace offline temporary;
recover tablespace ;
Alter tablespace online ;
Database is ready for use.
10. LOSS OF NON SYSTEM DATAFILE WITH ROLLBACK SEGMENTS WHEN THE DATABASE IS
IN ARCHIVE LOG MODE AND RECOVERY.
SCENARIO
Database startup fails with errors on thursday morning.
ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing and found to be user data file.
Cold backup is taken once in every week . Here backup is taken on every sunday and this is the last
activity
on sunday.
Datafile(s) associated with rollback segment tablespace is (are) lost.

14

ORACLE BACKUP STRATEGIES

TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN MIN 30 mins.
SOLUTION –
Shutdown the database.(shutdown).
Take complete backup of current database.
Comment the ROLLBACK_SEGMENT parameter or assign ROLLBACK_SEGMENT=(SYSTEM)
in init.ora file before startup.
Copy the missing rollback segment database file(s).
Startup mount exclusive;
alter database datafile ” offline;
alter database open;
Alter tablespace offline temporary;
recover tablespace ;
Alter tablespace online;
Query dba_rollback_segs (column name segment_name, status) and note down the name of segment
name having status recovery (say they are r01, r02,r03).
alter rollback segment r01 online;
alter rollback segment r02 online;
alter rollback segment r03 online;
shutdown the database.
Remove comment from rollback_segment parameter or remove system value and give the name of
rollback
segments which you want to be online when database starts.
Start the database.
Database is ready for use.
11. LOSS OF UNARCHIVED ONLINE LOG FILES WHEN THEY ARE NOT MIRRORED WHEN THE
DATABASE IS IN ARCHIVE LOG MODE AND RECOVERY.
SCENARIO
Database startup fails with errors on thursday morning.
ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing and found to be user data file.
Cold backup is taken once in every week . Here backup is taken on every sunday and this is the last

15

ORACLE BACKUP STRATEGIES

activity
on sunday.
All the online redo log files are lost.
All the data files and current control files are intact.
TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN MIN 30 mins.
SOLUTION –
Shutdown the database.(shutdown).
Take complete backup of current database.
Copy the all the database files from latest offline or online backup.
Startup mount exclusive;
recover database until cancel;
alter database open resetlogs;
shutdown the database.
Take cold backup. It is strongely advised.
Start the database.
Database is ready for use.
12. DATABASE CRASH DURING HOT BACKUP WHEN THE DATABASE IS IN ARCHIVE LOG
MODE AND RECOVERY.
SCENARIO
While taking hot backup, database crashes.
(a) When Oracle Version is 7.2 or more.
(b) When Oracle Version is 7.1.
TIME TAKEN IN RECOVERY
[a] DATABASE WILL BE READY FOR USE IN MIN 2 mins.
[b] DATABASE WILL BE READY FOR USE IN MIN 30 mins.
SOLUTION – (Oracle Version is 7.2 or more)
Shutdown the database.(shutdown).
Take complete backup of current database.

16

ORACLE BACKUP STRATEGIES

Startup mount exclusive;
Query the view v$backup and get file # having status active. Now from v$datafile get the name of
file which is active in v$backup
alter database datafile ” end backup;
alter database open ;
shutdown the database.
Start the database.
Database is ready for use.
SOLUTION – (Oracle Version is 7.1 )
Shutdown the database.(shutdown).
Take complete backup of current database.
Startup mount exclusive;
recover database ;
( This may take significant amount of time if a large number of archived logs are to be applied)
alter database open ;
shutdown the database.
Start the database.
Database is ready for use.
13. LOSS OF CONTROL FILE AND WHEN THE DATABASE IS IN ARCHIVE LOG MODE AND
RECOVERY.
SCENARIO
[a] Loss of control file when it is mirrored.
[b] Loss of control file when there is a backup and it is not mirrored but not before last reset log
option.
[c] Loss of control file when there is no backup and it is not mirrored (total loss).
NB : Loss of control file when there is a backup and it is not mirrored but it is before last reset log
option.
(suppose database is open on day x with alter database startup resetlogs.So your control file should
be before xth day )
startup/recover database using backup controlfile
Oracle error no is ora 1190 :control file or data file 1 is from before the last RESETLOGS

17

ORACLE BACKUP STRATEGIES

ora 1110 :name of system datafile.
[b] Loss of control file when there is a backup and it is not mirrored but not before last reset log
option.
(suppose database is open on day x with alter database startup resetlogs.So your control file should
be after xth day )
ORA-01122: database file 1 failed verification check
ORA-01110: data file 1: ‘/prodebs/test/sys_odc.dbf’
ORA-01207: file is more recent than control file – old control file
TIME TAKEN IN RECOVERY
[a] DATABASE WILL BE READY FOR USE IN MIN 2 mins.
[b] DATABASE WILL BE READY FOR USE IN MIN 30 mins.
[c] DATABASE WILL BE READY FOR USE IN MIN 30 mins.
SOLUTION – (Loss of control file when it is mirrored)
Shutdown the database.(shutdown).
Copy the second control file to this disk.
Rename this control file to the lost one.
Start the database.
Database is ready for use.
SOLUTION – (Loss of all the control file(s) )
Shutdown the database.(shutdown).
run backup of controlfile which you might have taken using the following command :
alter database backup controlfile to trace;
It creates a script. After editing that script it looks like this :
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE “” NORESETLOGS ARCHIVELOG
MAXLOGFILES 16
MAXLOGMEMBERS 2
MAXDATAFILES 30
MAXINSTANCES 1
MAXLOGHISTORY 100
LOGFILE
GROUP 1 (

18

ORACLE BACKUP STRATEGIES

‘/prodebs/test/redo_odc11.dbf’,
‘/prodebs/test/redo_odc12.dbf’
) SIZE 50K,
GROUP 2 (
‘/prodebs/test/redo_odc21.dbf’,
‘/prodebs/test/redo_odc22.dbf’
) SIZE 50K
DATAFILE
‘/prodebs/test/sys_odc.dbf’,
‘/prodebs/test/sys_odc1.dbf’,
‘/prodebs/test/user_odc.dbf’,
‘/prodebs/test/temp_odc.dbf’,
‘/prodebs/test/rbs_odc.dbf’,
‘/prodebs/test/ind.dbf’
;
RECOVER DATABASE
ALTER SYSTEM ARCHIVE LOG ALL;
ALTER DATABASE OPEN;
shutdown the database.
Start the database.
Database is ready for use.
SOLUTION – (Loss of control file when there is a backup and it is not mirrored)
Shutdown the database.(shutdown).
Copy the old control file to this disk.
startup mount exclusive;
If you have any tablespace which is read only, take all the datafile offiline related to this tablespace.
recover database using backup controlfile;
Offline datafile should bring to online status. (alter database datafile ‘< name of datafile>’ online;)
(for read only tablespace)
alter database open resetlogs;
Shutdown the database.
Take cold backup. It is strongely advised.
Start the database.
Database is ready for use.

19

ORACLE BACKUP STRATEGIES

14. DATABASE SPACE MANAGEMENT WHEN THE DATABASE IS IN ARCHIVE LOG MODE AND
RECOVERY (RESIZING DATAFILE).
SCENARIO
Space management when :
(a) Oracle Version is 7.2 or more.
(b) Oracle Version is 7.1.
Oracle Error is : ora 00376 file # can not be read at this time.
ora 01110 name of datafile.
TIME TAKEN IN RECOVERY
[a] DATABASE WILL BE READY FOR USE IN MIN 5 mins.
[b] DATABASE WILL BE READY FOR USE IN MIN 30 mins.
SOLUTION – (Oracle Version is 7.2 or more)
Shutdown the database.(shutdown).
Take complete backup of current database.
Startup open;
Query the view v$datafile get the name of file which you want to resize.
alter database datafile ” resize [m/k];
shutdown the database.
Take backup if necessary.
Start the database.
Database is ready for use.
SOLUTION – (Oracle Version is 7.1 )
[a] Restore the datafile and apply recovery. Resizing is not possible.
Shutdown the database.(shutdown).
Take complete backup of current database.
Copy the deleted datafile
Startup mount exclusive;
recover database ;
( This may take significant amount of time if a large number of archived logs are to be applied)

20

ORACLE BACKUP STRATEGIES

alter database open ;
shutdown the database.
Start the database.
Database is ready for use.
[b] If deleted datafile is not available in backup .
Shutdown the database.(shutdown).
Take complete backup of current database.
Startup mount exclusive;
alter database add datafile ” as ”;
recover database ;
( This may take significant amount of time if a large number of archived logs are to be applied)
alter database open ;
shutdown the database.
Start the database.
Database is ready for use.
[c] Rebuild tablespace
Requirement : Logical backup is there.
Shutdown the database.(shutdown).
Take complete backup of current database.
Startup mount exclusive;
alter database datafile ” offline;
alter database open;
alter tablespace offline;
drop tablespace ;
create tablespace datafile ” size [m/k];
alter tablespace online;
use export / import method to recover the loss data.
shutdown the database.
Take backup if necessary.
Start the database.
Database is ready for use.
15. RECOVERY THROUGH RESETLOGS .

21

ORACLE BACKUP STRATEGIES

CONDITIONS :
[A] When online redo logs files are deleted.
[B] Loss of all control files.
[C] When recovery is done through old control files.
Events
[1]
a- Cold backup is taken.
b- Loss of redo log file.and media recovery. At this moment, a backup is taken.
c- Loss of data file
[2]
a- Cold backup is taken.
b- Loss of redo log file.and media recovery. At this moment, a backup is not taken.
c- Loss of data file .
SOLUTION – [1]
Shutdown the database.(shutdown).
Take complete backup of current database.
Copy the most recent cold backup of datafiles.
Startup mount exclusive;
Recover database;
alter database open;
shutdown the database.
Take a cold backup.
Start the database.
Database is ready for use.
Advantage : All the data will be recovered.
SOLUTION – [2]-i
Shutdown the database.(shutdown).
Take complete backup of current database.
Startup mount exclusive;
alter database datafile ” offline;

22

ORACLE BACKUP STRATEGIES

alter database open;
Export all the data from the tablespace (all objects in missing file will be inaccessible),
Drop and recreate the tablespace.
Import all the data taken from tablespace.
recover datafile ” ;
alter database open;
shutdown the database.
Take a cold backup.
Start the database.
Database is ready for use.
Disadvantage : All the data will be lost that was entered in datafile 5;
SOLUTION – [2]-ii
Shutdown the database.(shutdown).
Take complete backup of current database.
Copy the most recent cold backup of datafile and control file only. Do not copy redo log file.
Startup mount exclusive;
Recover database;
alter database open resetlogs;
shutdown the database.
Take a cold backup.
Start the database.
Database is ready for use.
Disadvantage : All the data will be lost that after event b.
16. LOSS OF DATA FILE WHEN THE DATABASE IS IN ARCHIVE LOG MODE AND RECOVERY.
SCENARIO
Database startup fails with errors on thursday morning.
ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing and found to be user data file.
Cold backup is taken once in every week . Here backup is taken on every sunday and this is the last
activity

23

ORACLE BACKUP STRATEGIES

on sunday.
Datafile(s) associated with user tablespace is (are) permanently lost.
TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN MIN 30 mins.
SOLUTION –
Shutdown the database.(shutdown).
Take complete backup of current database.
Startup mount exclusive;
alter database create datafile ” ;
recover datafile ” ;
alter database open;
shutdown the database.
Start the database.
Database is ready for use.
17. SYSTEM CLOCK CHANGE AND POINT-IN-TIME RECOVERY.
SCENARIO
Database startup fails with errors on thursday morning.
ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing and found to be user data file.
Cold backup is taken once in every week . Here backup is taken on every sunday and this is the last
activity
on sunday.
Datafile(s) associated with user tablespace is (are) permanently lost.
TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN MIN 30 mins.
SOLUTION –
Shutdown the database.(shutdown).
Take complete backup of current database.
Startup mount exclusive;

24

ORACLE BACKUP STRATEGIES

recover database until time ” ;
alter database open resetlogs;
shutdown the database.
Take a cold backup of database;
Start the database.
Database is ready for use.
18. OFFLINE TABLESPACES AND RECOVERY.
SCENARIO
Database startup fails with errors on thursday morning.
ora 1157 can not identify datafile
ora 1110 give the name of datafile which is missing and found to be user data file.
Cold backup is taken once in every week . Here backup is taken on every sunday and this is the last
activity
on sunday.
Datafile(s) associated with user tablespace is (are) permanently lost.
TIME TAKEN IN RECOVERY
DATABASE WILL BE READY FOR USE IN MIN 30 mins.
SOLUTION – 1
Shutdown the database.(shutdown).
Take complete backup of current database.
Startup mount exclusive;
recover database ;
alter database open ;
recover tablespace ;
alter tablespace online;
Shutdown the database.
Start the database.
Database is ready for use.
SOLUTION – 2 (better)

25

ORACLE BACKUP STRATEGIES

Shutdown the database.(shutdown).
Take complete backup of current database.
Startup mount exclusive;
Query the view v$datafile and note which datafile is offline say it is .
alter database datafile <’a'> online;
recover database;
alter database open ;
shutdown the database
Start the database.
Database is ready for use.

Backup and Recovery Strategies and Procedures – Part I
Backup Method

Type

Version Available

Recovery
(RMAN)

Physical

Oracle version 8.0 and Third-party media
higher
backing up to tape)

Physical

All versions

Manager

Operating System

Requirements

Operating system
example, UNIX cp)

manager
backup

(only

utility

if

(for

26

ORACLE BACKUP STRATEGIES

Export

All versions

Feature

N/A

Recovery Manager

Operating System

Export

Closed
backups

database Supported. Requires instance to
Supported.
be mounted.

Open
backups

Requires rollback or
database Do not use BEGIN/END BACKUP Use
BEGIN/END undo segments to
statements.
BACKUP statements generate
consistent
backups.

Incremental backups

Supported.

Corrupt
detection

Supported. Identifies corrupt
blocks
and
writes
to Not supported
V$DATABASE_CORRUPTION.

block

Not supported

Automatic backup

Supported. Establishes the name
and locations of all files to be
backed up (whole database,
tablespace, datafile or control
file backup).

Backup catalogs

Supported.
Backups
are
recorded in the recovery catalog
and in the control file, or Not supported
exclusively in the target control
file.

Backups
manager

to

Supported. Interfaces with a
media manager. RMAN also
media
supports proxy copy, a feature
that allows the media manager
to manage the transfer of data.

Backs up initialization
parameter files and Not supported
password files
Operating
independent
language

system

Supported
interface).

(uses

PL/SQL

Not supported

Not supported
Supported. Identifies
corrupt blocks in the
export log.

Not supported. Files
Supported. Performs
to be backed up must
either full, user, or
be
specified
table backups
manually.

Not supported

Supported. Backup to
tape is manual or
supported
controlled by a media
manager.

supported

Not supported

Not supported

supported

Oracle to start an instance depends on the Oracle background processes, system global area (SGA)
apart from Oracle kernel. SGA is a group of memory structures that contain data and control
information for one Oracle Instance. Oracle automatically allocates SGA when an instance is started.
When startup command is given to oracle to start up a particular instance pointed to a parameter file,
which is called init<sid>.ora file, the background processes associated with the parameters and SGA
are initialized. There are various stages in starting up an instance.
Command

What happens then….?

Startup no mount

Read init.ora, identify control files, create and initialize SGA and start background
processes (this stage is to create a database or to re-create control files after the
loss of current control file)

Startup mount

Opens control files and mounts database and acquires an instance lock

Startup open

Open and lock data files. If first instance, get startup lock and open inline redo

27

ORACLE BACKUP STRATEGIES

log files. If first instance also perform crash recovery if necessary to open the
database in a consistent state
From the above it is understood that oracle has an internal mechanism to check the consistency
basing on data files, control file and online redo log files. If any of these three structures are not in
consistency they need to be restored and/or recovered.
Like wise what happens during shutdown is also important to understand the way the consistency is
maintained and not maintained and when recovery is required.
Shutdown normal

Shutdown immediate

Shutdown abort

1. Stop access to database

1. Stop access to database

1. Stop access to database

2. Wait until users exit

—–

—–

—–

2. Cancel active transactions
—–
and rollback

3. Flush DB Buffer and Redo log 3. Flush DB Buffer and Redo

caches
log caches
4. Drop file locks
5.
Complete
transactions

4. Drop file locks
on

going 5.
Complete
transactions

2. Drop file locks
on

going

—-

6. Update file headers

6. Update file headers



7. Close threads

7. Close threads



8. Drop DB Instance Lock

8. Drop DB Instance Lock

3. Drop DB Instance Lock

9. Synchronize control files and 9. Synchronize control files and
—database files
database files
NO REVOVERY REQUIRED

NO REVOVERY REQUIRED

CRASH
RECOVERY
REQUIRED
DURING NEXT STARTUP

BACKUPS ARE CONSISTENT

BACKUPS ARE CONSISTENT

BACKUPS ARE NOT CONSISTENT

Backup
It is to maintain a copy the data for use. Incase the database crashes to avoid data loss the data is
backed up to another device or/and destination and protected. It is the basic material for the
reconstruction of the lost / crashed database for some reason.
Restore
It is replacement of lost or damaged file with a backup. The files can be restored using RMAN or using
OS commands like cp on UNIX machines copy on Windows machines.
Recover
It is the process of updating the data files and/or control files restored using the redo records and/or
saved to archived redo log files generated by oracle. This process is also called ‘rolling forward’.
What Oracle Does For You?
Oracle does crash recovery and instance recovery.
Crash Recovery:

28

ORACLE BACKUP STRATEGIES

Crash recovery is the process of applying the online redo log files to the database files and control files
to bring the database to a consistent state and then closing all threads that are open at the time of
crash. After every startup of the machine and after every startup of the instance which is not closed
with normal and immediate options, the crash recovery starts with the applying of the threads that are
not closed at the time of last closure and after applying all the open threads SMON enables crash and
transaction recovery and opens the database for use.
In crash recovery, an instance automatically recovers the database before opening it. In general, the
first instance to open the database after a crash or shutdown abort automatically performs crash
recovery in the case of Oracle Real application Clusters.
Instance recovery:
Crash Recovery and Instance Recovery are considered synonymous as long as the database has only
one Oracle Instance to recover.
In Oracle Parallel Server (OPS) or Oracle Real Application Clusters (ORAC) the database is accessed by
multiple instances.
In OPS/ORAC configuration, the application of redo data to an open database by an instance when this
instance discovers that another instance has crashed. A surviving instance automatically uses the redo
log to recover the data in the instance’s buffer cache. Oracle undoes any uncommitted transactions
that were in progress on the failed instance when it crashed and then clears any locks held by the
instance after recovery is complete.
If one or more instances die/crash the instance is recovered by the living instances following the crash
recovery methodology of applying the on line redo logs and closing the open redo threads to sync the
database with the data that was in the cache, in redo and in rollback. This is done by Oracle itself.
If all the instances die then the database is to be restarted by starting all the instances. During the
opening of the database Oracle instances do crash recovery and then if necessary instance recovery to
bring the other dead instances to life.
Media Recovery:
Media Failure is the result of a physical problem that arises when Oracle fails in its attempt to write or
read a file that is required to operate the database. A common example is a disk head crash that
causes the loss of all data on the disk drive. Disk failure can affect a variety of files; including data
files redo log files and control files. Because the database instance cannot continue to function
properly, it cannot write the data in the buffer cache of the SGA to the data files.
Then it is necessary for a media recovery. Media recover means the application of redo or incremental
backups to a restored backup datafile or individual data block to bring it to a specified time. Datafile
media recover always begins at the lowest SCN recorded in the datafile header.
When doing the media recovery:

29

ORACLE BACKUP STRATEGIES

(1) entire database or
(2) a tablespace or
(3) a set of blocks within datafile
can be recovered.
This media recovery is of two types: (1) Complete Recovery and (2) Incomplete Recovery. There is a
choice of performing complete or incomplete recover only when the database is operated in
ARCHIVELOG MODE. In NOARCHIVELOG MODE there is no incomplete recovery at all. This is due to no
availability of archived log files in NOARCHIVELOG MODE.
If all the redo data is used it is complete recovery. If only part of the redo is used it is Incomplete
Recovery.
Now that the important words in backup and recovery are known what they meant when dealing with
Oracle databases, the discussion is to be shifted to backup strategy.
Backup Strategy:
(1) Physical Backups
In the physical backups the datafiles associated with the database are backed up.
The backup strategy is dependent on the data loss tolerance level of the database owners and / or the
clients using the database.
If the data saved to the disks is high per every unit of time with some lean periods the data loss
tolerance level is always low and the shut down time is ‘zero’. This means the database is 24*7 by
nature. When the data loss tolerance level is zero, the database is to be put on media recovery mode.
This mode is also called ‘archive log mode’. In this mode the online redo log files when are filled are
moved to the archive log file destination as set in the parameter file for the database. The background
process ‘ARCH’ is enabled by setting (log_archive_start = true) archive parameter to true in the
parameter file. Additionally there parameters are set for the format of the archive log file name and
archive log file destination or location on the disk.
log_archive_dest_1 = “location=H:\Oracle\oradata\srinivas\archive”
log_archive_format = %%ORACLE_SID%%T%TS%S.ARC
The archive log mode is enabled at two levels. At the database level and at the system level. If the
database cannot be stopped altering the system a command is issued which is valid until the next
startup of the database. When such a command is issued the database parameter file is modified and
in the next startup the modified parameter becomes effective.
If the database is very large with many associated data files, they need more time to backup the
database. Such databases do not have down time also. The backup strategy is to be evolved to meet
such contingency where in we can recover the database within the lowest possible time and to the last
committed transaction to the database.

30

ORACLE BACKUP STRATEGIES

If there is down time for the database – we can have consistent backup of the database. If there is no
downtime for the database – the only alternative is to backup the database in inconsistent mode and
then there also backup archive logs which can be used in case of recovery.Consistent backup is called
‘cold backup‘ or ‘off-line‘ of the database after the database is shutdown with NORMAL OR IMMEDIATE
option but not ABORT option. In this the database is not open and no user is able to access the
database. The instance is shutdown and database is closed in normal mode and at the operating
system level the backup takes place.The following files are backed up in this type of backups:
1.

All datafiles

2. All controlfiles
3. All online redo log files
4. The init.ora file and config.ora file
5. Password file
Inconsistent backup
A backup in which some of the files in the backup contain changes made after they were check
pointed. This type of backup needs recovery before it can be made consistent. Taking online database
backups usually creates inconsistent backup. It means that the data files are backed up while they are
open and are used. Inconsistent backup can also be done while the database is closed. This is possible
in the following circumstances:
(1) A backup taken immediately after the instance crashed (or when all instances crashed in multiinstance environment like Oracle Parallel Server now called Oracle Real Application Clusters)
(2) When the instance was shutdown with ‘shutdown abort option’.
Utilities for the Backup
RMAN
Recovery Manager is a utility provided by Oracle for Backup and Recovery Procedures.
Oracle Recovery Manager User Manual says:
Recovery Manager is able to:
Use server sessions to back up and copy the database, tablespaces, datafiles, control files, and
archived redo logs. Compress backups of datafiles so that only those data blocks that have been
written to are included in a backup. Store frequently executed backup and recovery operations in
scripts. Perform incremental backups, which back up only those data blocks that have changed since a
previous backup. Recover changes to objects created with the NOLOGGING option by applying
incremental backups (recovery with redo logs does not apply these changes). Create a duplicate of
your production database for testing purposes. Use third-party media management software. Generate
a printable message log of all backup and recovery operations. Use the recovery catalog to automate
both restore and recovery operations. Perform automatic parallelization of backup and restore

31

ORACLE BACKUP STRATEGIES

operations. Restore a backup using a backup control file and automatically adjust the control file to
reflect the structure of the restored datafiles. Find datafiles that require a backup based on userspecified limits on the amount of redo that must be applied for recovery. Perform crosschecks to
determine whether archived materials in the media management catalog are still available. Test
whether specified backups can be restored.
(2) Logical Backups
These backups are to be performed only when the database is open and available. Export utility
provided by oracle enables the exports. The Export is done in (1) Full Mode (2) User Mode and (3)
Table Mode and the types of exports are (1) complete (2) cumulative and (3) incremental. These types
can be used only when full=y is set as a parameter and then inctype=complete or cumulative or
incremental can be set. When the export is performed using the inctype parameter, the database is to
be recovered by:
a.

Import the latest full export dump file

b.

Import the latest cumulative export dump file

c.

Then import all the incremental export files successively.

The database is recovered to the to point-in-time of the last incremental export and the data after that
point of time is lost as no archive log files are used for recovering the database and they become
useless.
Upside of Exports and Imports:
a.

Use the exports to clone the schema and database.

b.

Reorganization of the tablespace until 8.1 is introduced.

c.

Ability to export to multiple files of a prescribed size.

d.

Ability to export sub-sets of data from the tables of choice.

e.

Transportable Tablespaces. They are like plug-in tablespaces. This is a feature of 8.1. In this
the time taken to export the tablespace/s is just that of the time needed to copy a datafile
physically to another location. This facility has some limitations. Such as
1. The source and target databases should be running on the same hardware platforms.
2.

The

3.

The

source

4.

The

source

5.

source

and

target

databases

database
and

Must

must

target

not

databases

transport

should
have

be
a

should

using

the

tablespace
have

the

self-contained

same
by

same

set

character

the
data
of

same

set.

name.

block

size.

objects.

6. Snapshots, materialized views, function based indexes, domain indexes, scoped refs,
advanced

queues

with

more

than

one

recipient

cannot

be

transported.

7. The source database must set the tablespace to READ ONLY mode for a short period of time

32

ORACLE BACKUP STRATEGIES

i.e.,.

until

meta

data

of

the

tablespace

is

exported

and

data

file

is

copied.

8. SYS owned objects couldn’t be transported.
When a tablespace is intended to be transported, it is to be routinely checked for self-containment
using the built in package provided by Oracle.
Exec sys.dbms_tts.transport_set_check(‘tablespace_name’,true);
After the procedure is successfully executed
Select * from sys.transport_set_violations;
If no rows are selected that is fine. Check the same way for the other tablespace intended for export.
If any rows are returned against that tablespace you are to use multiple tablespace names in the
package until zero rows are returned to find of the sets of tablespaces that can be transported. This is
to be done as the table may be created in one tablespace and index is created in another tablespace.
All the tablespaces so connected are to be transported together else your export is not usable. For
multiple tablespaces the following example is may help:
Exec sys.dbms_tts.transport_set_check(‘tablespace_1, tablespace_2,tablespace_3′,true);
Example of exporting transportable tablespaces t1, t2, t3
Step 01.
Exec sys.dbms_tts.transport_set_check(‘t1, t2,t3′,true);
Step 02.
Select * from sys. transport_set_violations;
No rows selected.
Step 03.
Alter tablespace t1 read only;
Alter tablespace t2 read only;
Alter tablespace t3 read only;
Step 04.
At the command prompt:
Exp

userid=”"”sys/password

as

sysdba”"”

transaport_tablespace=y

tablespaces=(t1,

t2,

t3)

file=tr_tbsp.dmp
After the export is terminated successfully without warnings,
Step 05.
At the command prompt ‘copy’ or ‘xcopy’ the datafiles, associated with those tablespaces exported, to
the destination within the framework of hardware compatibility and software compatibility and data
block size compatibility etc discussed above.
Step 06.

33

ORACLE BACKUP STRATEGIES

After they are successfully copied verify the sizes with the original files and at Server Manager or SQL*
Plus issue the following commands at the source database where from the tablespaces are exported to
enable all DML transactions.
Alter tablespace t1 read write;
Alter tablespace t2 read write;
Alter tablespace t3 read write;
Step 07.
Now import the tablespaces into target database:
Imp

file=tr_tbsp.dmp

userid

=”"”

sys/password

as

sysdba

“”"

transport_tablespace=y

“datafiles=(filename1, filename2, filename3)”
Step 08.
After the import is terminated successfully, the last step is to change the mode of the tablespaces as
they are imported in read only mode.
Alter tablespace t1 read write;
Alter tablespace t2 read write;
Alter tablespace t3 read write;
Downside of Exports and Imports:
a. Still it is not possible to export on to a device not recognized when in Windows environment and it
is possible in UNIX environment as pipes can be used to export on to a tape.
b. The database suffers loss of data when exports and imports are used to recover the database, as
media recovery cannot be enabled to apply the archived redo log files.
c. Reorganization of tablespace is possible only when you have logically contiguous chunks of space
available on the tablespace. This is because the tables are exported as a single largest extent
combining all the extents the table had spanned before the export when compress=y parameter is
used to reorganize the tablespace. When the tables and indexes in a particular tablespace are to be
imported into more than one tablespace the DDL is to be edited carefully and pre-create tablespaces
and then tables and then set the parameter ignore=y and then import the data. Instead ‘alter table
<table_name> move <tablespace_name>;’ would take less time and efficient. But there are some
issues with this move command. All the indexes on that table become un-usable and they are to be
re-created or rebuilt.
d. Named versus Default -named constraints can cause some issues by spitting IMP-00003 and ORA02264 or ORA-02261 and like that indicate the existence of so named object that is attempted to be
imported.
e. National Language Support (NLS) Issues are to be taken care of. If they differ there is an issue. If
the NLS character sets of the export client are different from the database being exported or if the

34

ORACLE BACKUP STRATEGIES

import client character sets are different from the export clients or the import client character set is
different from the being imported into database character set, there are issues and they are to be
handled carefully by setting the local environment variables such as $NLS_LANG on UNIX boxes and
Registry entry in Windows environment.
f. Limitations to the transportable tablespaces concept.
To improve the performance of Exports and Imports the following may be considered:
1.

Set DIRECT parameter in the export parameter file and this enables to bypass the SQL
command processing layer.

2.

Set RECORDLENGTH parameter for the exports in multiples of db_block_size or in multiples of
OS block size and the max is 64 kilobytes.

3.

While importing set BUFFER parameter a little high to have array inserts and also use
COMMIT=Y as additional parameter. Too high BUFFER parameter can result in paging or
swaping which negatively effects the performance.

4.

Generate index file for the indexes to be separately after the data is imported with no indexes
on the tables. INDEXES=N and INDEXFILE=name and path of index file

Setting up RMAN
RMAN setup in 8.0 is different from 8.1
RMAN in Oracle 8 and 8.1 – with no catalog
Step 01 Create a rman backup command file for the datafiles (rman_bu.rcv)
run {
allocate channel t1 type ‘SBT_TAPE’;
setlimit channel t1 kbytes 2097150 maxopenfiles 32 readrate 200;
# Backup the database
backup
full
tag db_full_backup
filesperset 6
format ‘db_full_%d_t%t_s%s_p%p’
(database);
# Release the tape device
release channel t1;
}
# The following commands are run outside of the “run {}”
# command.
# Save control file to trace file.

35

ORACLE BACKUP STRATEGIES

sql ‘ALTER DATABASE BACKUP CONTROLFILE TO TRACE’;
Step 02 create a rman backup command file for the archive log files (rman_bu_log.rcv)
run {
allocate channel t1 type ‘SBT_TAPE’;
setlimit channel t1 kbytes 2097150 maxopenfiles 32 readrate 200;
# Archive the current online log
sql ‘alter system archive log current’;
# save archive logs…
backup
filesperset 20
format ‘al_%d_t%t_s%s_p%p’
(archivelog all delete input);
# Release the tape device
release channel t1;
}
These two files can be set in a batch file to be run at specific times of choice. The backups can be
monitored if Legato or Veritas or any other STORAGE MANAGER that is compatible and installed.
This is a common file for the data files as well as archive log files
run {
allocate channel t1 type ‘SBT_TAPE’;
setlimit channel t1 kbytes 2097150 maxopenfiles 32 readrate 200;
# Backup the database
backup
full
tag db_full_backup
filesperset 6
format ‘db_full_%d_t%t_s%s_p%p’
(database);
# Release the tape device
release channel t1;
}
# The following commands are run outside of the “run {}”
# command.
# Save control file to trace file.
sql ‘ALTER DATABASE BACKUP CONTROLFILE TO TRACE’;

36

ORACLE BACKUP STRATEGIES

run {
allocate channel t1 type ‘SBT_TAPE’;
setlimit channel t1 kbytes 2097150 maxopenfiles 32 readrate 200;
# Archive the current online log
sql ‘alter system archive log current’;
# save archive logs…
backup
filesperset 20
format ‘al_%d_t%t_s%s_p%p’
(archivelog all delete input);
# Release the tape device
release channel t1;
}
list backupset of database;
list backupset of archivelog all;
RMAN in Oracle 8.1 – with catalog
Step 01 create the tablespace for the RMAN schema and user
create tablespace rcvcat datafile ‘path\rcvcat.ora’ size 100M default storage (initial 1M next 1M
minextents 1 maxextents unlimited pctincrease 0);
Step 02 set auto extension on
alter database datafile ‘path\rcvcat.ora’ autoextend on;
Step 03 create user for owning rman schema
create user rman_<sid_name> identified by rman_<sid_name> temporary tablespace temp01 default
tablespace rcvcat quota unlimited on rcvcat;
Step 04 make grants
grant create session to rman_<sid_name>;
grant recovery_catalog_owner to rman_<sid_name>;
Step 05 at the command prompt in a single line
Rman target internal/oracle@connect_string rcvcat
rman_<sid_name>/rman_<sid_name>@connecting_string
Step 06 now create catalog by issuing the following command at RMAN prompt
create catalog;
Step 07 after the catalog is created register the database
register database;
that is it you are done

37

ORACLE BACKUP STRATEGIES

A piece of advice:
Create the RMAN catalog as a separate database. For this create a small database with about 500 MB
and create RMAN user and create catalog for him in that database and that database can be put on
cold backup daily after the RMAN backup is completed for the database and this protects the database
in case of disaster as RMAN database is immediately restorable and all the tapes or devices on to
which the backups are done can be used for recovery.

End backup

Oracle Backup and Recovery Description of Begin backup/

Introduction
ALTER TABLESPACE … BEGIN BACKUP and ALTER TABLESPACE … END BACKUP,
and why it is mandatory to use it when the online backup is done with a tool that is external
to Oracle ( such as OS backups using cp, tar, BCV, etc. )
It also gives an answer to those frequent questions:
• Does Oracle write to data files while in hot backup mode ?
• What about ALTER DATABASE BEGIN BACKUP ?
• Why it is not used with RMAN backups
• What if you do an online backup without setting tablespaces in backup mode ?
• What if the instance crashes while the tablespaces is in backup mode ?
• How to check which datafiles are in backup mode
• What are the minimal archive logs to keep with the hot backup ?
• Why use OS backups instead of RMAN ?
Description
Offline backup (Cold backup)

38

ORACLE BACKUP STRATEGIES

A cold OS backup is simple: the database has been cleanly shut down (not crashed, not shutdown
abort) so that:
• all datafiles are consistent (same SCN) and no redo is needed in case of restore
• the datafiles are closed: they will not be updated during the copy operation
Thus, it can be restored entirely and the database can be opened without the need to recover.
Online backup (Hot backup)
An hot backup does the copy while the database is running. That means that the copy is inconsistent
and will need redo applied to be usable.
Recovery is the process of applying redo log information in order to roll-forward file modifications as
they were done in the original files.
When the copy is done with Oracle (RMAN), Oracle copies the datafile blocks to backupset so that it
will be able to restore them and recover them.
When the copy is done from the OS (i.e with a tool that is not aware of the Oracle file structure),
several issues come up:
• Header inconsistency: Nothing guaranties the order in which the files are copied, thus the header of
the file may reflect its state at the beginning or at the end of the copy.
• Fractured blocks: Nothing guaranties that an Oracle block is read in one single i/o so that two halves
of a block may reflect its state at two different points in time.
• Backup consistency:As the copy is running while the datafile is updated, it reads blocks at different
point in time. The recovery is able to roll forward blocks from the past, but cannot deal with blocks
from the future, thus the recovery of the copy must be recovered at least up to the SCN that was at
the end of the copy.
So it is all about consistency in the copy: consistency between datafiles, consistency within datafiles
and consistency within data blocks, and keep this consistency in the current files (obviously) as well as
in the copy (as it will be needed for a restore/recovery)

39

ORACLE BACKUP STRATEGIES

Backup mode
The goal of ALTER TABLESPACE … BEGIN BACKUP and ALTER TABLESPACE … END BACKUP is to set
special actions in the current database files in order to make their copy usable, without affecting the
current operations.
Nothing needs to be changed in the current datafiles, but, as the copy is done by an external tool, the
only way to have something set in the copy is to do it in the current datafiles before the copy, and
revert it back at the end.
This is all about having a copy that can be recovered, with no control on the program that
does the copy, and with the minimal impact on the current database.
In order to deal with the 3 previous issues, the instance that will do the recovery of the restored
datafiles has to know:
• that the files need recovery
• from which SCN, and up to which SCN it has to be recovered at least
• enough information to fix fractured blocks
During backup mode, for each datafile in the tablespace, here is what happens:
1- When BEGIN BACKUP is issued:
• The hot backup flag in the datafile headers is set, so that the copy is identified to be a hot backup
copy.
This is to manage the backup consistency issue when the copy will be used for a recovery.
• A checkpoint is done for the tablespace, so that in case of recovery, no redo generated before that
point will be applied.
Begin backup command completes only when checkpoint is done.
2- During backup mode:

40

ORACLE BACKUP STRATEGIES

• The datafile header is frozen so that whenever it is copied, it reflects the checkpoint SCN that was at
the beginning of the backup.
Then, when the copy will be restored, Oracle knows that it needs to start recovery at that SCN to
apply the archived redo logs.
This is to avoid the header inconsistency issue.
That means that any further checkpoints do not update the datafile header SCN (but they do update a
‘backup’ SCN)
• Each first modification to a block in buffer cache will write the full block into the redo thread (in
addition to the default behaviour that writes only the change vector). This is to avoid the fractured
block issue. There may be a fractured block in the copy, but it will be overwritten during the recovery
with the full block image.
That means that everything goes as normal except for two operations:
- at checkpoint the datafile header SCN is not updated
- when updating a block, the first time it is updated since it came in the buffer cache,
the whole before image of the block is recorded in redo
- direct path writes do not go through the buffer cache, but they always write full
blocks and then full block is written to redo log (if not in nologging)
3- When END BACKUP is issued:
• A record that marks the end of backup is written to the redo thread so that if the copy is restored
and recovered, it cannot be recovered earlier than that point. This is to avoid the backup consistency
issue.
• The hot backup flag in the datafile headers is unset.
• The header SCN is written with the current one.
Remarks:

41

ORACLE BACKUP STRATEGIES

1. the fractured block is not frequent as it happens only if the i/o for the copy is done at the same
time on the same block as the i/o for the update. But the only mean to avoid the problem is to do that
full logging of block for each block, just in case.
2. if the OS i/o size is multiple of the Oracle block size (e.g backup done with dd bs=1M), that
supplemental logging is not useful as fractured blocks cannot happen.
3. the begin backup checkpoint is mandatory to manage the fractured block issue: as Oracle writes
the whole before image of the block, it needs to ensure that it does not overwrite a change done
previously. With the checkpoint at the beginning, it is sure that no change vector preceding the begin
backup has to be applied be applied.
4. The supplemental logging occurs when accessing the block for the first time in the buffer cache. If
the same block is reloaded again in the buffer cache, supplemental logging will occur again. I haven’t
seen that point documented, but a testcase doing a ‘flush buffer_cache’ proves that.
Consequence on the copy (the backup)
When the copy has been done between begin backup and end backup, the copy is fully available to be
restored and recovered using the archive log files that where generated since the begin backup.
After the files have been restored, Oracle sees that the SCN is older than the current one and says
that the database needs recovery.
The recovery must be done up to a point in time ulterior to the end backup point in time so that we
are sure that there is no blocks in the datafile that comes from the future.
Consequence on the current database
All operations can be done during the backup mode.
However, as more logging is written, it should be done during a low activity period. And for the same
reason, it is better to do the tablespaces one after one instead of putting all the database tablespaces
in backup mode.
In addition, it is not possible to shutdown the database while a tablespace is in hot backup. This is
because, as the datafile header is frozen with a non current SCN, the datafile would be seen as if it

42

ORACLE BACKUP STRATEGIES

requires recovery. However that cannot be avoided if the instance crashes (or shutdown abort), and
then the startup of the database will raise:
ORA-1113: file … needs media recovery
This is the only case I know where instance recovery is not automatic, you need to issue
‘alter database… end backup;’ before opening the database.
Frequent questions
Does Oracle write to data files while in hot backup mode ?
Yes of course, it would not be called ‘online’ backup if it were not the case.
What about ALTER DATABASE BEGIN BACKUP ?
That command put all database tablespaces in backup mode at the same time. As seen previously, it
is a bad idea to put all tablespaces in backup mode, as it is better to do it one by one in order to
minimize the supplemental redo logging overhead.
Oracle introduces this ‘shortcut’ for one reason only: when doing backup with a mirror split (BCV,
Flashcopy, etc), the copy gets all the datafiles at the same time, and the copy lasts only few seconds.
In that case, it is easier to use that command to put all tablespaces in backup mode during the
operation.
Why it is not used with RMAN backups
RMAN is an Oracle tool, that is totally aware of the datafile structure, and the way they are
written. Then, it knows how it can read the datafiles in a way the copy is consistent: write the good
version of datafile header, read the blocks with an i/o size that is multiple of the Oracle block size so
that there is no fractured blocks, and check head and tail of the block to see if block is fractured (in
that case, it re-reads the block to get a consistent image). That is one advantage among many others
of using RMAN for backups.
What if you do an online backup without setting tablespaces in backup mode ?

43

ORACLE BACKUP STRATEGIES

If you don’t put the tablespace in backup mode, we can’t be sure that the copy is recoverable. It may
be fine, but it may have inconsistencies. We can suppose that the copy is consistent if we make the
copy with the following
conditions
• Header inconsistency: If the file copy is done from beginning to end, then the datafile header should
reflect the right SCN
• Fractured blocks: If the copy does i/o with a size that is multiple of the Oracle block size, then you
should not have fractured blocks
• Backup consistency:If you take care to recover later than the point in time of the end of the copy,
you should not have inconsistency
But there may be other internal mechanisms that are not documented so that we can’t be sure that
this list of issues is exhaustive. And, as it is not supported, we cannot rely on a backup done like that.
Note that you will have no message
What if the instance crashes while the tablespaces is in backup mode ?
When you start the database after that, Oracle will say that it requires recovery. This is because the
SCN was frozen and it is the expected behaviour because if you restore the copied file, it has to be
recovered. (and the only way Oracle has to set its value in the copy is to set it in the current file while
it is copied) In that case you can can issue:
ALTER DATABASE END BACKUP;
ALTER DATABASE OPEN;
to open the database.
But your backup is not usable, you have to do it again.
How to check which datafiles are in backup mode
The V$BACKUP view shows the datafiles that are currently in backup mode (status ACTIVE). Some old
documentation says to check V$DATAFILE_HEADER column FUZZY. This is because in previous

44

ORACLE BACKUP STRATEGIES

versions (<9i) the begin backup unsets the online fuzzy bit in the datafile header, and set it back at
when end backup is issued. Since 9i, the online fuzzy bit is unset only when datafile is offline or readonly, not for backup mode.
What are the minimal archive logs to keep with the hot backup ?
The backup done online is unusable if there is not at least the possibility to restore archive logs
- from the archive log that was the current redo log when the backup started,
- up to the archive log that was archived just after the backup (of the whole database) ended.
That is sufficient to do an incomplete media recovery up to the point of ‘end backup’. Subsequent
archive logs will be needed to recover up to the point of failure.
Why use OS backups instead of RMAN
The best way to do online backups is using RMAN as it has a tons of features that you cannot have
with OS backups. Yet, the OS backup are still used when using OS tools that can copy an entire
database in seconds, using mirror split (BCV, Flashcopy, etc), for very large databases.

Backup and Recovery Strategies and Procedures – Part II
Media Recovery Scenarios
Gather the information
Before the recovery strategies are drawn it is necessary to create record for the tablespaces,
associated data files, listing control files and on-line redo log files.

The following SQL statement helps gather records for recovery:
SELECT NAME FROM V$DATAFILE
UNION ALL
SELECT MEMBER FROM V$LOGFILE
UNION ALL
SELECT NAME FROM V$CONTROLFILE;
Recording the Locations of Archived Redo Logs
SELECT NAME, VALUE
FROM V$PARAMETER

45

ORACLE BACKUP STRATEGIES

WHERE NAME LIKE ‘log_archive_dest%’
AND VALUE IS NOT NULL
/
Determine the format for archived logs by running SHOW as follows:
SHOW PARAMETER LOG_ARCHIVE_FORMAT
To see a list of all the archived logs recorded in the control file, issue this query:
SELECT NAME FROM V$ARCHIVED_LOG;
Recording the Locations of Backup Files
It is not enough to merely record the location of backup files: you must correlate the backups with the
original files. If possible, name the backups with the same relative filename as the primary file.
Whatever naming system you use, keep a table containing the relevant information.
Determining Which Data files Require Recovery
SELECT * FROM V$RECOVER_FILE;
With the output of the above query, query V$DATAFILE and V$TABLESPACE to obtain filenames and
tablespace names for data files requiring recovery.
SELECT d.NAME, t.NAME AS tablespace_name
FROM V$DATAFILE d, V$TABLESPACE t
WHERE t.TS# = d.TS#
AND d.FILE# IN (select file# from v$recover_file);
Recovery Strategies and Procedures in Media Recovery Scenarios:
(1) Using Non-RMAN methods or User Managed Backups
Recovery under noarchivelog mode
01 after deleting all the database files restore complete set of database files from the latest offline
backup or cold backup
02. start the database using startup open pfile=<init.ora file with path>;
In this type of recovery you will be loosing data logged into the database after the last backup.
Recovering Lost Data Files in noarchivelog mode
01.Mount the database
startup mount pfile=<init.ora file with path>;
02.alter database open;
The database complains about the missing data file.
If that data file is to be taken off line that is not permitted as the database is in ‘noarchivelog’ mode.
Even if it tried to switch the database mode to ‘archivelog’ it is not permitted.
So
03.alter datafile ‘<data file complained above with path>’ offline drop;

46

ORACLE BACKUP STRATEGIES

04. alter database open;
05. drop tablespace <tablespace_name> drop including contents;
06. create tablespace <tablespace_name> datafile ‘<data file name with path>’ size 100M;
07. recreate the objects in that tablespace if any. In this context export dumps are useful to recreate
the objects with data or without data.
To offline a data file the database is to be in archive log mode. If the database is in noarchive log
mode you can offline drop the data file, which is equivalent to the offline method, and actually the
datafile is not dropped or deleted as that data file is already missing or dropped.
Recovering Lost Data Files in archivelog mode
(1) Identify the data files that are damaged or lost. This is known when a table is accessed which
resides in that tablesapce that is associated with that missing/damaged datafile or when instance is
started while opening the database the database complains of the physical structures of the database
identified as data files, control files and redo log files.
The recover can be done in two ways. Shutdown database, restore the datafile file from the latest
back up and also all the archived redo log files from the from the latest backup of the database to the
point of time at which the database is mounted and not opened for the simple reason the datafile is
not available.
SVRMGR> connect internal as sysdba
Connected.
SVRMGR> startup
ORACLE instance started.
Total System Global Area 137020380 bytes
Fixed Size 70620 bytes
Variable Size 77750272 bytes
Database Buffers 59121664 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock data file 3 – see DBWR trace file
ORA-01110: data file 3: ‘H:\ORACLE\ORADATA\SRINIVAS\USERS01.DBF’
SVRMGR> shutdown immediate;
At the OS level restore the data file reported not able to identify. Then connect to server manager and
mount database and then recover database or the data file.
Recovering the Database
SVRMGR> connect internal/oracle@srinivas

47

ORACLE BACKUP STRATEGIES

Connected.
SVRMGR> startup mount
ORACLE instance started.
Total System Global Area 137020380 bytes
Fixed Size 70620 bytes
Variable Size 77750272 bytes
Database Buffers 59121664 bytes
Redo Buffers 77824 bytes
Database mounted.
SVRMGR> recover database;
Media recovery complete.
SVRMGR> alter database open;
Statement processed.
SVRMGR>
Recovering the Datafile
SVRMGR> connect internal/oracle@srinivas
Connected.
SVRMGR> startup mount
ORACLE instance started.
Total System Global Area 137020380 bytes
Fixed Size 70620 bytes
Variable Size 77750272 bytes
Database Buffers 59121664 bytes
Redo Buffers 77824 bytes
Database mounted.
SVRMGR>
SVRMGR>alter database datafile ‘H:\ORACLE\ORADATA\SRINIVAS\USERS01.DBF’ offline;
Statement processed.
SVRMGR> alter database open;
Statement processed.
SVRMGR> alter tablespace users offline;

alter tablespace users offline
*ORA-01191: file 3 is already offline – cannot do a normal offline
ORA-01110: data file 3: ‘H:\ORACLE\ORADATA\SRINIVAS\USERS01.DBF’

48

ORACLE BACKUP STRATEGIES

SVRMGR> alter tablespace users offline immediate;
Statement processed.
SVRMGR> recover tablespace users;
ORA-00283: recovery session canceled due to errors
ORA-00264: no recovery required
SVRMGR> alter tablespace users online;
Statement processed.
SVRMGR> connect scott/tiger@srinivas
Connected.
SVRMGR> select * from case_1;
COL1
———1
2
3
3 rows selected.
Restoring and recreating control files
There are three situations where control files are to be restored and recovered.
(1) Loosing a member of the multiplexed control files
(2) Loosing all the members of the control files when the back up of the control files is available
(3) Loosing all Current and Backup Control Files.
Loosing a member of the multiplexed control files
In this case it is not a big problem to restore the member control file. The following steps are required
to recreate the lost member control file.
There are again two scenarios in this case.
a. Restoring the control file to the default destination
There are control_1.ctl, control_2.ctl and control_3.ctl files and control_2.ctl is lost. Then,
01. If the instance is still running shutdown abort;
02. If there is any hardware problem correct that problem and then
for UNIX platforms
cp control_3.ctl control_2.ctl
03. start the new instance
startup
b. Restoring the control file to the non-default destination

49

ORACLE BACKUP STRATEGIES

The default destination directory for control_2.ctl is %ORACLE_HOME%\dbs and the control file is to
be created / restored in a non- default destination like %ORACLE_HOME%\database.
01. If the instance is still running
shutdown abort;
02. If there is any hardware problem correct that problem and then
for UNIX platforms
cp control_3.ctl \oracle\database\control_2.ctl
03. Edit the init.ora file for the instance
old parameter:
UNIX:
controlfiles=/oracle/dbs/control_1.ctl’,'/oracle/dbs/control_2.ctl’,'/oracle/dbs/control_3.ctl’
new parameter:
controlfiles=’d:\oracle\dbs\control_1.ctl’,'e:\oracle\database\control_2.ctl’,'f:\oracle\dbs\control_3.ctl’
UNIX:
controlfiles=/oracle/dbs/control_1.ctl’,'/oracle/database/control_2.ctl’,'/oracle/dbs/control_3.ctl’
04. start the new instance
startup
Loosing all the members of the control files when the back up of the control files is available
When a control file is inaccessible, then you can start the instance, but not mount the database. If you
attempt to mount the database when the control file is unavailable, you see this error message:
ORA-00205: error in identifying controlfile, check alert log for more info
If the control files are restored from the backup the database can not be opened without resetlogs
option.
There are 4 scenarios on which the recovery procedure is dependent.
Status of Online Logs

Status of Datafiles

Response

Current

If the online logs contain redo
necessary for recovery, then restore
a backup control file apply the logs
during recovery. Hence, you must
specify the filename of the online
logs containing the changes in order
to
open
the
database.
After
recovery, open RESETLOGS.

Unavailable

Current

If the online logs contain redo
necessary for recovery, then you
must re-create the control file.
Because the logs are inaccessible,
open RESETLOGS.

Available

Backup

Available

Restore a backup control file,
perform complete recovery, and then

50

ORACLE BACKUP STRATEGIES

open RESETLOGS.
Unavailable

Backup

Restore a backup control file,
perform incomplete recovery, and
then open RESETLOGS.

If the control files are being restored to the default locations the initialization parameter file need not
be edited.
Procedure:
01. Shutdown abort; — if the instance is still running.
02. Correct if there are any hardware problems
03. Restore the backup control files to the respective destinations. Use cp for UNIX platforms and copy
for the windows platforms.
04. Startup mount;
05. Issue the following command to recover the database
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
(select auto while applying the redo log files and when prompted that that it can not find any redo log
files for application then type cancel to cancel the recovery process. At the end of the process ‘Media
recovery complete.’ is spit out)
06. Then issue the following statement at SQL or svrmgrl prompt:
ALTER DATABASE OPEN RESETLOGS;
07. Backup the database afresh and keep that copy safe.
If the control files are being restored to the non-default locations the initialization
parameter file need not be edited.
Procedure:
01. Shutdown abort; — if the instance is still running.
02. Correct if there are any hardware problems
03. Restore the backup control files to new locations/destinations. Use cp for UNIX platforms and copy
for the windows platforms.
04. Edit the initialization parameter file suitably to reflect the new locations for the ‘controlfiles’
parameter
05. Startup mount;
06. Issue the following command to recover the database
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
(select auto while applying the redo log files and when prompted that that it can not find any redo log
files for application then type cancel to cancel the recovery process. At the end of the process ‘Media
recovery complete.’ is spit out)
07. Then issue the following statement at SQL or svrmgrl prompt:

51

ORACLE BACKUP STRATEGIES

ALTER DATABASE OPEN RESETLOGS;
08. Backup the database afresh and keep that copy safe.
Loosing all Current and Backup Control Files.
If you . . .

Then . . .

Executed
ALTER
DATABASE
BACKUP
CONTROLFILE TO TRACE NORESETLOGS
Use the CREATE CONTROLFILE statement from the trace
after you made the last structural change
output as-is.
to the database, and if you have saved the
SQL command trace output
Edit the output of ALTER DATABASE BACKUP
Performed your most recent execution of
CONTROLFILE TO TRACE to reflect the change. For
ALTER DATABASE BACKUP CONTROLFILE
example, if you recently added a datafile to the
TO TRACE before you made a structural
database, then add this datafile to the DATAFILE clause
change to the database
of the CREATE CONTROLFILE statement.
Backed up the control file with the ALTER
DATABASE BACKUP CONTROLFILE TO
filename statement (not the TO TRACE
option)

Use the control file copy to obtain SQL output. Copy the
backup control file and execute STARTUP MOUNT before
ALTER DATABASE BACKUP CONTROLFILE TO TRACE
NORESETLOGS. If the control file copy predated a recent
structural change, then edit the trace output to reflect
the structural change.

Do not have a control file backup in either
Create the CREATE CONTROLFILE statement manually
TO TRACE format or TO filename format
Note
If your character set is not the default US7ASCII, then you must specify the character set as an
argument to the CREATE CONTROLFILE statement. The database character set is written to the alert
log at startup. The character set information is also recorded in the BACKUP CONTROLFILE TO TRACE
output.
Recover Procedure:
01. STARTUP NOMOUNT
02. issue the create control file statement manually:
CREATE CONTROLFILE REUSE DATABASE “SRINIVAS” NORESETLOGS ARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 32

MAXINSTANCES 16
MAXLOGHISTORY 1815
LOGFILE
GROUP 1 (

52

ORACLE BACKUP STRATEGIES

‘H:\ORACLE\ORADATA\SRINIVAS\REDO03.LOG’,
‘H:\ORACLE\ORADATA\SRINIVAS\REDO_3.LOG’
) SIZE 1M,
GROUP 2 (
‘H:\ORACLE\ORADATA\SRINIVAS\REDO02.LOG’,
‘H:\ORACLE\ORADATA\SRINIVAS\REDO_2′
) SIZE 1M
DATAFILE
‘H:\ORACLE\ORADATA\SRINIVAS\SYSTEM01.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\RBS01.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\USERS01.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\TEMP01.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\TOOLS01.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\INDX01.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\DR01.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\USERS02.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\TEST_TBSP_01.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\TTS_EX2.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\OEM_REPOSITORY.ORA’,
‘H:\ORACLE\ORADATA\SRINIVAS\PERFSTAT.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\P1.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\P2.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\USER01.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\TEST.DBF’,
‘H:\ORACLE\ORADATA\SRINIVAS\TEST_TBSP_02.DBF’
CHARACTER SET WE8ISO8859P1 ;
03.After control file is created Oracle MOUNTS the database. Then issue the following statement.
RECOVER DATABASE
04.Open the database when it is recovered.
Alter database open; — note that reset logs option is not necessary.
05. after the database is open backup control file to trace and another destination with reuse clause.
alter database backup controlfile to trace;
for UNIX platforms
alter database backup controlfile to ‘/oracle/database/bkup_control.ctl’ reuse;
Preparing for Closed Database Recovery

53

ORACLE BACKUP STRATEGIES

In this stage, you shut down the instance and inspect the media device that is causing the problem.
To prepare for closed database recovery:
If the database is open, then shut it down with the ABORT option:
SHUTDOWN ABORT
If recovering from a media error, then correct it if possible. If the hardware problem that caused the
media failure was temporary, and if the data was undamaged (for example, a disk or controller power
failure), then no media recovery is required: simply start the database and resume normal operations.
If you cannot repair the problem, then proceed to the next step.
Restoring Backups of the Damaged or Missing Files
In this stage, restore all necessary backups.
To restore the necessary files:
Determine

which

datafiles

to

recover

by

querying

the

v$recover_file.

If the files are permanently damaged, then identify the most recent backups for the damaged files.
Restore only the datafiles damaged by the media failure: do not restore any undamaged datafiles or
any online redo log files.
For example, if /oracle/dbs/tbs_10.f is the only damaged file, then you may consult your records and
determine that /oracle/backup/tbs_10.backup is the most recent backup of this file. If you do not have
a backup of a specific datafile, then you may be able to create an empty replacement file that can be
recovered.
Use an operating system utility to restore the files to their default location or to a new location. For
example,

a

UNIX

user

restoring/oracle/dbs/tbs_10.f

to

its

default

location

might

enter:

% cp /oracle/backup/tbs_10.backup /oracle/dbs/tbs_10.f
Follow these guidelines when determining where to restore datafile backups:
If . . .

Then . . .

The hardware problem is repaired and you can Restore the datafiles to their default locations and
restore the datafiles to their default locations
begin media recovery.
The hardware problem persists and you cannot The hardware problem persists and you cannot
restore datafiles to their original locations
restore datafiles to their original locations.
Recovering the Database
In

the

final

stage,

you

recover

the

datafiles

that

you

have

restored.

To recover the restored datafiles:

Connect to the database with administrator privileges, then start a new instance and mount, but do
not open, the database. For example, enter:
STARTUP MOUNT

54

ORACLE BACKUP STRATEGIES

Obtain the datafile names and statuses of all datafiles by checking the list of datafiles that normally
accompanies the current control file or querying the V$DATAFILE view. For example, enter:
SELECT NAME,STATUS FROM V$DATAFILE;
Ensure that all datafiles of the database are online. All datafiles of the database requiring recovery
must be online unless an offline tablespace was taken offline normally or is part of a read-only
tablespace. For example, to guarantee that a datafile named /oracle/dbs/tbs_10.dbf is online, enter
the following:
ALTER DATABASE DATAFILE ‘/oracle/dbs/tbs_10.dbf’ ONLINE; – UNIX
If a specified datafile is already online, then Oracle ignores the statement. If you prefer, create a script
to bring all datafiles online at once as in the following:
SPOOL onlineall.sql
SELECT ‘ALTER DATABASE DATAFILE ”’||name||”’ ONLINE;’ FROM V$DATAFILE;
SPOOL OFF
SQL> @onlineall
Issue the statement to recover the database, tablespace, or datafile. For example, enter one of the
following RECOVER command:
RECOVER DATABASE # recovers whole database
RECOVER TABLESPACE users # recovers specific tablespace
RECOVER DATAFILE ‘/oracle/dbs/tbs_10′; # recovers specific datafile
Follow these guidelines when deciding which statement to execute:
To . . .

Then . . .

Recover all damaged files in one step

Execute RECOVER DATABASE

Recover an individual tablespace

Execute RECOVER TABLESPACE

Recover an individual damaged datafile

Execute RECOVER DATAFILE

If you choose not to automate the application of archived logs, then you must accept or reject each
required redo log that Oracle prompts you for. If you automate recovery, then Oracle applies the
necessary logs automatically. Oracle continues until all required archived and online redo log files have
been applied to the restored datafiles.
Oracle notifies you when media recovery is complete:
Media recovery complete

If no archived redo log files are required for complete media recovery, then Oracle applies all
necessary online redo log files and terminates recovery.
After

recovery

ALTER DATABASE OPEN;

terminates,

then

open

the

database

for

use:

55

ORACLE BACKUP STRATEGIES

Preparing for Open Database Recovery
In this stage, you take affected tablespaces offline and inspect the media device that is causing the
problem.
To prepare for datafile recovery when the database is open:
If the database is open when you discover that recovery is required, take all tablespaces containing
damaged datafiles offline. For example, if tablespace users contains damaged datafiles, enter:
ALTER TABLESPACE users OFFLINE TEMPORARY;
Correct the hardware problem that caused the media failure. If the hardware problem cannot be
repaired quickly, proceed with database recovery by restoring damaged files to an alternative storage
device.
Restoring Backups of the Damaged or Missing Files
In this stage, restore all necessary backups in the offline tablespaces.
To restore datafiles in an open database:
If files are permanently damaged, then restore the most recent backup files of only the datafiles
damaged by the media failure. Do not restore undamaged datafiles, online redo log files, or control
files.
If the hardware problem has been repaired and the datafiles can be restored to their original locations,
then do so. If the hardware problem persists, then restore the datafiles to an alternative storage
device.
If damaged datafiles are restored to alternative locations, rename the datafiles in the control file of the
database.
For example, to change the filename of the datafile in tablespace users you might enter:
for UNIX platforms:
ALTER DATABASE RENAME FILE ‘/d1/oracle/dbs/tbs1.dbf’ TO ‘/d3/oracle/dbs/tbs1.dbf’;
Recovering Offline Tablespaces in an Open Database
In the final stage, you recover the datafiles in the offline tablespaces.
To recover offline tablespaces in an open database:
Connect to the database with administrator privileges. For example, connect as SYSTEM or SYS to
database:
sqlplus SYS/PASSWORD@DBNAME_ALIAS AS SYSDBA
Start offline tablespace recovery of all damaged datafiles in one or more offline tablespaces using one
step.

For

example,

recover

the

users

and

sales

tablespaces

RECOVER TABLESPACE users, sales; # begins recovery on datafiles in users and sales
If the damaged datafiles are associated with one tablespace only then:
RECOVER TABLESPACE users;

as

follows:

56

ORACLE BACKUP STRATEGIES

Oracle begins the roll forward phase of media recovery by applying the necessary redo log files
(archived and online) to reconstruct the restored datafiles. Unless the applying of files is automated
with RECOVER AUTOMATIC or SET AUTORECOVERY ON, Oracle prompts for each required redo log file.
Oracle continues until all required archived redo log files have been applied to the restored datafiles.
The online redo log files are then automatically applied to the restored datafiles to complete media
recovery.
If no archived redo log files are required for complete media recovery, then Oracle does not prompt for
any. Instead, all necessary online redo log files are applied, and media recovery is complete.
When the damaged tablespaces are recovered up to the moment that media failure occurred, bring
the offline tablespaces online. For example, to bring tablespaces users and sales online, issue the
following statements:
ALTER TABLESPACE users ONLINE;
Issue the statement for each tablespace that is to be brought online separately. There is no possibility
to issue a single statement for multiple tablepsaces as is done in the case of ‘RECOVER’ statement.
Backup and Recovery Strategies and Procedures – Part III
Loss of Online Redo Files
When media failure has effected the online redo log files appropriate recovery procedure is to be
adopted. The adoption of the recovery procedures is dependent on:
(1) How the online redo log files are configured. That means whether the online redo log files are
mirrored or not.
(2)

What

type

of

media

failure

is

there?

Temporary

or

permanent.

(3) Types of the online redo log file that are affected by the media failure.
To identify the configuration of the redo log files the following query is to be issued at SQL prompt
logging in as a user with administrative privileges.
select group#, members, status from v$log;
If each group has more than one member online redo log files are mirrored. The media failure is to be
identified and fixed.
After the media failure is identified and fixed the status of the online redo log files is to be examined
by accessing the v$log file. The table given below describes the status of online redo log file and their
meanings.
Status

Description

UNUSED

The online redo log has never been written to.

CURRENT

The log is active, that is, needed for instance recovery, and it is the log to
which Oracle is currently writing. The redo log can be open or closed.

ACTIVE

The log is active, that is, needed for instance recovery, but is not the log to
which Oracle is currently writing.It may be in use for block recovery, and may

57

ORACLE BACKUP STRATEGIES

or may not be archived.
CLEARING

The log is being re-created as an empty log after an ALTER DATABASE CLEAR
LOGFILE statement. After the log is cleared, then the status changes to
UNUSED.

The current log is being cleared of a closed thread. The log can stay in this
CLEARING_CURRENT status if there is some failure in the switch such as an I/O error writing the
new log header.
INACTIVE

The log is no longer needed for instance recovery. It may be in use for media
recovery, and may or may not be archived

The status of online redo log files in v$logfile should not be mistaken with the status of the online redo
log files in v$log.
Status

Description

Inactive

It is not needed for crash recovery

Active

It is needed for crash recovery

Current

It is the log that Oracle is currently writing to

When one of the multiplexed online redo log file is lost and there is at least one member in the group
then:
(1) The log group is not affected by the media failure and Oracle allows the database to function as
normal.
(2) Oracle writes error messages to the LGWR trace file and the alert log of the database.
If the hardware problem is temporary, then correct it. LGWR accesses the previously unavailable
online redo log files as if the problem never existed.
If the hardware problem is permanent the redo log group member is to be dropped and recreated.
The procedure for that is:
(1) Locate the file name from v$logfile with the status ‘INVALID’
select group#, status, member from v$logfile where status = ‘INVALID’;
(2) drop the damaged member
ALTER DATABASE DROP LOGFILE MEMBER ‘<redo log file name with path>’;
(3) Add new member to that group
ALTER DATABASE ADD LOGFILE MEMBER ‘<new redo log file name with path>’ TO GROUP <group
number>;
The group number is the group number obtained using the query in (1)
or
(3) Add a existing member which is of same size as the other member/s in the group

58

ORACLE BACKUP STRATEGIES

ALTER DATABASE ADD LOGFILE MEMBER ‘<existing member redo log file name>’ REUSE TO GROUP
<group number>;
When all the members of a group are lost there are three scenarios:
(1)

When

(2)

When

an
an

INACTIVE
ACTIVE

group
group

is

lost.

is

lost.

(3) When a CURRENT group is lost.
(1) When an INACTIVE group is lost:
If the media failure is temporary is fixed LGWR can reuse that group and there is nothing to be done
at this juncture.
If the media failure is permanent and is fixed it is to be investigated whether that INACTIVE group is
archived or not and also whether there is any data file that has gone offline that requires the inactive
redo log file. To find answers for these queries follow the procedure laid down.
(a) select * from v$log where status=’INACTIVE’ and arc=’NO’;
If you any rows returned the inactive redo log group is not archived. At this juncture we are not sure
whether data in that inactive redo log group is required for any offline data file or not is to be
ascertained. To ascertain that
(b) Select file#, name, status from v$datafile where status<>’ONLINE’;
If this query return values then there are data files that may require the redo log information. Then
the procedure is
(1) Mount database
startup mount;
(2) (i) if query (a) has rows returned and query (b) has no rows returned:
Clear the log using the UNARCHIVED keyword. For example, to clear log group 2, issue
ALTER DATABASE CLEAR LOGFILE UNARCHIVED GROUP 2;
(2) (ii) if query (a) and query (b) return rows:
ALTER DATABASE CLEAR LOGFILE UNARCHIVED GROUP 2 UNRECOVERABLE DATAFILE;
(3) Backup entire database and also backup control file to trace or different destination. If the control
file is backed up to trace ‘create control file’ command is generated and when backed up to different
destination entire control file is copied and the size of the control file is verifiable with the existing
control files.
There is possibility of failure of CLEAR LOGFILE operation. If this operation fails the following
procedure is to be adopted.
(a) Relocate the redo log file onto alternative media by re-creating it under the currently
configured redo log filename

59

ORACLE BACKUP STRATEGIES

(b) Reuse the currently configured log filename to re-create the redo log file because the name
itself is invalid or unusable (for example, due to media failure).

(2) When an ACTIVE group is lost the procedures are different in NOARCHIVELOG and
ARCHIVELOG modes.
(2) When an ACTIVE group is lost in NOARCHIVELOG mode:
(1) if the media failure is temporary and is corrected when instance is restarted Oracle reuses the
group as if nothing had happened.
(2) if the media failure is permanent and is corrected the database is to be restored from the latest
backup available ( in noarchivelog mode only consistent backups are possible and no online backup
can be done as media recovery is not enabled). If the online redo log files are also backed up, restore
them to their default locations and start the database. there is no necessacity to recover the database.
But if the online redo log files are not backed up then,
(3) mount the database
startup mount;
(3) mimic the recovery until cancel.
RECOVER DATABASE UNTIL CANCEL
and issue CANCEL to cancel the recovery.
(4) Open the database using reset logs option
ALTER DATABASE OPEN RESETLOGS;
(6) backup the database completely including the online redo log files after shutting down the
database with normal or immediate option as the database is in noarchivelog mode.
Note: The database restored contains data until the latest backup which is used to restore the
database. All the data is to be re-entered after that point of restoration.
(3) When an ACTIVE group is lost in ARCHIVELOG mode:
If the media failure is temporary, Oracle will start writing to the redo log files when the instance is
restarted.
But, in the case of permanent failure of media the following procedure is to be adopted.
(1) do an incomplete media recovery by canceling the recovery at that point where online redo logs
files are lost. This results in loss of the data that the redo log file contains.
(2) Ensure that the current name of the lost redo log can be used for a newly created file. If not, then
rename the members of the damaged online redo log group to a new location. The procedure to add
online redo log group and member are already discussed above. But, to rename the redo log files
issue the following statement:

60

ORACLE BACKUP STRATEGIES

ALTER DATABASE RENAME FILE ‘<old redo log file name with path> TO < new redo log file name with
path>;
This statement is to be issued to each member in that group that has been lost.
(3) Open the database with reset logs option
ALTER DATABASE OPEN RESETLOGS;
All updates executed from the endpoint of the incomplete recovery to the present must be reexecuted. Else there is loss of data.
When a CURRENT group is lost, there will be data loss, in ARCHIVELOG mode or
NOARCHIVELOG mode. This is an un avoidable situation.
In NOARCHIVELOG mode if online redo log files are also backed up and when the database is restored
including the online redo log files – no more data is recovered and all the data is to be re-entered after
that point of time.
In ARCHIVELOG mode the database is restored from the latest backup and roll forward of archived
redo logs is done, but the recover is incomplete as the current redo log files are not available and the
recovery is to be on UNTIL CANCEL basis. The loss of data is minimized to the extent of the data lost
with the current online redo log file.
Recovering After the Loss of Archived Redo Log Files:
If the database is operating in ARCHIVELOG mode, and if the only copy of an archived redo log file is
damaged, then the damaged file does not affect the present operation of the database. The following
situations can arise, however, depending on when the redo log was written and when you backed up
the datafile.
If you backed up . . .

Then . . .

All datafiles after the filled online
The archived version of the filled online redo log group is not
redo log group (which is now
required for complete media recovery operation.
archived) was written
If the corresponding datafile is damaged by a permanent media
A specific datafile before the filled
failure, use the most recent backup of the damaged datafile and
online redo log group was written
perform incomplete recovery up to the damaged log.
Caution:
If you know that an archived redo log group has been damaged, immediately back up all data files so
that you will have a whole database backup that does not require the damaged archived redo log.

Oracle Backup & Recovery Overview
1. What is a BACKUP ? What is a RESTORE ? What is RECOVERY ?

61

ORACLE BACKUP STRATEGIES

A "backup" is a copy of the database. This copy could be a physical copy of the
database (the database files are copied, so this is a physical backup) or alogical
copy (the database information is copied in another format which can be "imported"
again into the database to get back the old data). A logical copy of the database (or a
part of it) is named logical Backup.

When the physical files (from a backup) are copied back to the initial location is
named a "restore" operation.

When a database is restored, sometimes we need to apply last changes (from archive
log files/ log files) to bring the database data up-to-date. This operation is
named "recovery", because the last information is recovered.
2. How we can take a physical Backup ?

a) At the Operating System level using "copy" command ( cp for UNIX, Solaris,
Linux ).
b) using Oracle RMAN, or other backup tools.
3. How can we take a logical backup ?

a) using Oracle exp/ imp utility
b) the data/ code objects could be copied in a text file using different tools (like
TOAD, SQL Developer)
c) using Oracle Data Pump (10g and + )
4. Which are the steps in recovery process ?

1st: Roll forward (cache recovery) : is carried out by applying all
(committed and un committed) redo log records to the data files.

2nd: Roll back (transaction recovery) : all uncommitted transactions are
reverted to its original state. This is done by reading the rollback (undo)
segments.
All this process is based on the SCN (System Change Number) which acts as an
internal clock.
5. How could I calculate the Database Availability ?
Database Availability = MTBF/ (MTBF+MTTR), where:

62

ORACLE BACKUP STRATEGIES
MTBF = Mean Time Between Failures
MTTR = Mean Time To Recover
6. How we can increase the Database Availability ?
This could be done technically by using:

A Real Application Cluster (RAC) environment: Many instances on several
computers access the same database. If one node or a server fails, other
nodes perform a recovery for that node. Such a configuration will have load
distribution along with the added advantage of high availability.

An Oracle Standby Database: The Oracle Standby database is a copy of the
production database. When the production database fails, the standby
database will be used.
7. Comparison of Backup Methods
Backup
type

RMAN Backup

User-Managed Backup

Export

Closed
database
backups

Supported. Requires instance to be
mounted.

Supported.

Not
supported.

Supported. No need to
useBEGIN/END BACKUP statements.

Requires
rollback or
Supported. Must
undo
use BEGIN/ENDBACKUP statements segments to
.
generate
consistent
backups.

Open
database
backups

Incremental
Supported.
backups

Not supported.

Not
supported.

Corrupt
block
detection

Supported. Identifies corrupt blocks
and logs
Not supported.
inV$DATABASE_BLOCK_CORRUPTION.

Supported.
Identifies
corrupt
blocks in the
export log.

Automatic
record
keeping of
files in
backups

Supported. Establishes the name and
locations of all files to be backed up
Not supported. Files to be backed
(whole database, tablespace, datafile up must be specified manually.
or control file backup).

Supported.
Performs
either full,
user, or
table
backups.

Recovery
catalogs

Supported. Backups are recorded
inthe RMAN repository, which is
contained in the control file and
optionally in the recovery catalog
database.

Not supported. DBA must keep own Not
records of backups.
supported.

Backups to
media
manager

Supported. Interfaces with a media
manager. RMAN also supports proxy
copy, a feature that allows the media
manager to manage the transfer of
data.

Supported. Backup to tape is
manual or controlled by a media
manager.

Supported.

Backs up

Supported.

Supported.

Not

63

ORACLE BACKUP STRATEGIES
initialization
parameter
file
Backs up
password
and
networking
files

supported.

Not supported.

Platformindependent
Supported.
language for
backups

Supported.

Not
supported.

Not supported.

Supported.

8. What kind of backups are available for Oracle Database ?
->> Cold (Off-line Backup) - Shut the database down and backup up ALL data,
log, control files, password file, pfile (spfile).
->> Hot (On-line Backup) - If the database is available and in ARCHIVELOG mode,
set the tablespaces into backup mode and backup their files. The control files, redo
log files are copied as well.
->> logical backup (using Export/Import Utility or Data Pump (10g and +) ):
The database is running and a copy of the database (or a part of the database) is
exported/ imported into/from a system file.
9. What is the difference between a consistent & inconsistent backup ?
In a consistent backup, all headers of datafiles that belong to a WRITABLE
tablespaces have the SAME checkpoint SCN.
In a inconsistent backup, NOT all headers of datafiles that belong to a WRITABLE
tablespaces have the SAME checkpoint SCN. An inconsistent backup is created by a
hot backup. A recovery is needed in order to make the backup consistent. Only a
consistent database could be up and running.
RMAN OVERVIEW

1. What is RMAN ?

RMAN (Recovery Manager) is the recommended tool for Oracle database backup,
restore and recovery operations. RMAN is an Oracle product.

2. Why use RMAN ?

64

ORACLE BACKUP STRATEGIES


RMAN supports both cold (offline) and hot (online) backup



The RMAN online backup is easier to take than an online user-managed
backup



Does block level backup and recovery



RMAN command language is platform independent



The online backup doesn't put the tablespace in "backup mode", so no extra
redo logs are not generated

3. Where does RMAN store the metadata information about the backups ?

In RMAN Catalog Repository (created on a database schema) or in the control files of
the target database. Personally, I prefer to use the control file because the result is
the same, but there is less administrative work for this.

4. Which are the components of RMAN ?


RMAN software: RMAN executable software could be find in
$ORACLE_HOME/bin directory



Processes: RMAN creates processes to perform different activities, such as
backups, restore and recovery



Target database: The target database is the database RMAN connect to
backup, restore, recover information from (in)



Recovery Catalog Database: Store the metadata for the RMAN activities. It
doesn't store the backup of the target database. The target control files also
could keep the RMAN metadata.



RMAN channel: The RMAN Channel provide a mean of communication
between the server and the operating system. Using more channels increase
the speed of the RMAN activities.



Backup Set: A Backup Set store one or more physical files or backup
pieces. You cannot split a file across different backup sets or mix archived
logs and datafiles into one backup set.



Image Copy: Is a replica of the physical files in uncompressed form. Because
of this the images copies could be used to restore the data files using RMAN
or operating system commands.

65

ORACLE BACKUP STRATEGIES
5. Which are the advantages of each RMAN metadata repositories ?
RMAN Catalog Repository Advantages


One repository for many
databases



RMAN scripts could be used to
manage the RMAN utility



The control files has a normal
I/O activity during the RMAN
operations



The control files are smaller in
size and we don't need to take care
of
CONTROL_FILE_RECORD_KEEP_TIM
E initialization parameter

Using Control file : Advantages


Less administrative tasks



We don't need another instance installation for
this

NOTE: CONTROL_FILE_RECORD_KEEP_TIME init.or
a parameter must be set to a value no less than the
database backup retention period. This parameter
applies only to records in the control file that are
circularly reusable (such as archive log). It does not
apply to records such as data files or tablespaces. You
can read the Metalink Note 47322.1.

6. Which are the disadvantages of each RMAN metadata repositories ?
RMAN Catalog Repository Disadvantages

Using Control file : Disadvantages



More administrative tasks



Many repositories for many databases



We need another instance installation for
this



RMAN scripts could NOT be used to
manage the RMAN utility



The control files has a high I/O
activity during the RMAN operations



The control files are bigger in size and
we need to take care of
CONTROL_FILE_RECORD_KEEP_TIME
initialization parameter

Create the Oracle RMAN Catalog
Choosing a database for hosting the RMAN

RMAN catalog must be installed in an Oracle database (new or existing). As rule, the
RMAN catalog mustn't be created on the same database as the target database, for
data security reason (once the database is used, the RMAN catalog cannot be used
and so, the database cannot be restored & recovered). Even if the RMAN catalog is
installed on the same database as the target database (but is strongly recommended
not to do it), RMAN Catalog must be created on a different disk.
Planning the size of the Recovery Catalog

66

ORACLE BACKUP STRATEGIES

Here are the Oracle requirements for 1 Year utilization :
SYSTEM tablespace

90 MB

Temp tablespace

5 MB

Rollback or undo tablespace

5 MB

Recovery catalog tablespace

15 MB for each database registered in the
recovery catalog

Online redo logs

1 MB each (3 groups, each with 2 members)

Create a RMAN user owner

This oracle database user will store all the data/ information for the RMAN Recovery
Catalog. The name of this user is not important, however rman is the best name we
can use for this purpose (will tell us exactly the usage of this schema).4

1. Create the tablespace for RMAN user (the TOOLS tablespace could be used as well):

CREATE TABLESPACE RMAN_DATA_1_TBS
DATAFILE '/ORA_RMAN/RMAN_data/rman_data_1.dbf'

SIZE 200M AUTOEXTEND ON;

2. Create the RMAN user:

CREATE USER rman IDENTIFIED BY r
TEMPORARY TABLESPACE temp
DEFAULT TABLESPACE RMAN_DATA_1_TBS
QUOTA UNLIMITED ON RMAN_DATA_1_TBS;
Grant the RECOVERY_CATALOG_OWNER role to the schema owner (RMAN in our case)

GRANT RECOVERY_CATALOG_OWNER TO rman;

67

ORACLE BACKUP STRATEGIES

Create the RMAN Recovery Catalog

1. From the OS level execute
rman CATALOG rman/r

(to connect to the database)

2. Create the catalog
CREATE CATALOG;

Register a database into Recovery Catalog

In order to connect and work with a target database, RMAN must be connected to the
catalog and to the target database.

To connect to the target database and the recovery catalog we have to use this
command (run on the RMAN database server):

68

ORACLE BACKUP STRATEGIES

rman TARGET sys/s@db1 CATALOG rman/r

To register the target database with the RMAN catalog the command we have to use
is REGISTER DATABASE;

Now we can see that the DB table in RMAN schema has one database register (In this
table we can see the database identifier of the new registered database). To check
this we can run (connected as RMAN) SELECT DB_ID from DB;

Verify the database registration

We can verify the database registration by running REPORT SCHEMA command.

69

ORACLE BACKUP STRATEGIES

Oracle RMAN Cumulative backup and restore
1. Cumulative Backup Overview

Sometimes we need to backup the database changes only from the last backup (only
the last changes are backed up). This is an incremental backup. There are 2 types of
incremental backup: DIFFERENTIAL (by default) & CUMULATIVE.
NOTE: The incremental backups are only for the DATA files.

CUMULATIVE backup = which backs up all blocks changed after the most recent
incremental backup at level 0. See the picture bellow.

The following RMAN command is used to take a CUMULATIVE database backup:

70

ORACLE BACKUP STRATEGIES
RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
2. Cumulative Restore Overview

Because a CUMULATIVE backup is taken each day during the week, we need to
restore 2 times: 1st we have to restore the full backup and after that the last
cumulative backup (for a complete restore). If differential backups are taken we have
to restore all the differential backups until the database crash.

3. Simulate a disk crash on Tuesday at noon

Now delete a datafile, /DB1/oradata/db1/users01.dbf for instance, SHUTDOWN
the database using ABORT option and restart the database.

The following message will appear:

7. Restore & Recover the lost file

a) connect to the RMAN:

71

ORACLE BACKUP STRATEGIES
rman catalog rman/r@dbr target /

b) restore the /DB1/oradata/db1/users01.dbf from the full backup:
RMAN> restore datafile ''/DB1/oradata/db1/users01.dbf';'

So, this command restores the file from the full backup.

c) apply the last changes from the cumulative backup:
RMAN> recover datafile ''/DB1/oradata/db1/users01.dbf';' from
tag='DAY_BK_CUMULATIVE1';

How to validate a backup in an Oracle database

72

ORACLE BACKUP STRATEGIES
1. Validating a logical export (taken using exp utility)

First we have to take a look to the export log file. Also, we can import the data in
another database to see if the import is done without errors.
2. Validate a physical backup (taken using RMAN "image copy" option or by copying the files
at the OS level)

In this case we have to validate the .dbf files. This is done by using DBVERIFY Utility.

Total Pages Examined: Number of blocks in the file
Total Pages Processed: Number of blocks verified
Total Pages Failing: Number of blocks that failed the data/ index/ segment block
check
Total Pages Marked Corrupt: Number of corrupted blocks
Total Pages Influx: Number of blocks being read and written to in parallel.

73

ORACLE BACKUP STRATEGIES

If there are no errors during the recovery ... validate, the backup is good. This
command (recovery database validate) doesn't recover the database; only the check
is done.

b) RMAN> VALIDATE BACKUPSET <backupset_nr>

To find the backup set of the backups we can run the RMAN command LIST BACKUP;

74

ORACLE BACKUP STRATEGIES
c) using RMAN report options, like REPORT UNRECOVERABLE DATABASE; (examine all
datafiles, but not the archivelog files !!!)

Oracle export / import utility (exp / imp)
1. What is the Import/ Export Utility ?

Export (exp), Import (imp) are Oracle utilities which allow you to write data in an
ORACLE-binary format from the database into operating system files and to read data
back from those operating system files.
2. Which are the Import/ Export modes ?

a) Full export/export
The EXP_FULL_DATABASE & IMP_FULL_DATABASE, respectively, are needed to
perform a full export. Use the full export parameter for a full export.
b) Tablespace
Use the tablespaces export parameter for a tablespace export.

c) User
This mode can be used to export and import all objects that belong to a user. Use the
owner export parameter and the fromuser import parameter for a user (owner)
export-import.

d) Table
Specific tables (or partitions) can be exported/imported with table export mode. Use
the tables export parameter for a table export/ import mode.

3. Is it possible to exp/ imp to multiple files ?
Yes, is possible. Here is an example:
exp SCOTT/TIGER FILE=C:\backup\File1.dmp,C:\backup\File2.dmp LOG=C:\backup\scott.log
4. How we can use exp/ imp when we have 2 different Oracle database versions?

exp must be of the lower version


imp must match the target version

5. What I have to do before importing database objects ?
Before importing database objects, we have to drop or truncate the objects, if not,
the data will be added to the objects. If the sequences are not dropped, the sequences will generate
inconsistent values. If there are any constraints on the target table, the constraints should be

75

ORACLE BACKUP STRATEGIES
disabled during the import andenabled after import.
6. Is it possible to import a table in a different tablespace ?
By default, NO. Because is no tablespace parameter for the import operation.
However this could be done in the following manner:

(re)create the table in another tablespace (the table will be empty)



import the table using INDEXFILE parameter (the import is not done, but a file which contains
the indexes creation is generated)
modify this script to create the indexes in the tablespace we want



import the table using IGNORE=y option (because the table exists)



recreate the indexes
Here is an example of INDEXFILE:

7. In which cases imp/exp is used ?

Eliminate database fragmentation


Schema refresh (move the schema from one database to another)




Detect database corruption. Ensure that all the data can be read (if the data can be read
that means there is no block corruption)
Transporting tablespaces between databases



Backup database objects

8. How we can improve the EXP performance ?

Set the BUFFER parameter to a high value (e.g. 2M)


If you run multiple export sessions, ensure they write to different physical disks.

9. How we can improve the IMP performance ?

Import the table using INDEXFILE parameter (the import is not done, but a file which contains
the indexes creation is generated), import the data and recreate the indexes

Store the dump file to be imported on a separate physical disk from the oracle data files





If there are any constraints on the target table, the constraints should be disabled during
the import and enabled after import
Set the BUFFER parameter to a high value (ex. BUFFER=30000000 (~30MB) ) and COMMIT
=y or set COMMIT=n (is the default behavior: import commits after each table is loaded,
however, this use a lot of the rollback segments or undo space for huge tables.)
use the direct path to import the data (DIRECT=y)

76

ORACLE BACKUP STRATEGIES



(if possible) Increase DB_CACHE_SIZE (DB_BLOCK_BUFFERS prior to 9i) considerably in the
init<SID>.ora file
(if possible) Set the LOG_BUFFER to a big value and restart oracle.

10. Which are the EXP options ?
EXP Option

Default
value

Description

buffer

Specifies the size, in bytes, of the buffer (array) used to
insert the data

compress

N

When “Y”, export will mark the table to be loaded as one
extent for the import utility. If “N”, the current storage options
defined for the table will be used. Although this option is only
implemented on import, it can only be specified on export.

consistent

N

Specifies the set transaction read only statement for
export, ensuring data consistency. This option should be set to
“Y” if activity is anticipated while the exp command is executing.
If ‘Y’ is set, confirm that there is sufficient undo segment space
to avoid the export session getting the ORA-1555 Snapshot too
old error.

constraints

Y

Specifies whether table constraints should be exported
with table data.

direct

N

Determines whether to use direct or conventional path
export. Direct path exports bypass the SQL command, thereby
enhancing performance.

0

Determines how often feedback is displayed. A value of
feedback=n displays a dot for every n rows processed. The
display shows all tables exported not individual ones.

feedback

The name of the export file. Multiple files can be listed,
separated by commas. When export fills thefilesize, it will begin
writing to the next file in the list.

file
filesize

The maximum file size, specified in bytes.

flashback_scn

The system change number (SCN) that export uses to
enable flashback.

flashback_time

Export will discover the SCN that is closest to the
specified time. This SCN is used to enable flashback.

full
grants

The entire database is exported.
Y

help
indexes

Shows command line options for export.
Y

log
object_consistent
owner
parfile

Specifies object grants to export.
Determines whether index definitions are exported. The
index data is never exported.
The filename used by export to write messages.

N

Specifies whether export uses SET TRANSACTION READ
ONLY to ensure that the data being exported is consistent.
Only the owner’s objects will be exported.
The name of the file that contains the export parameter
options. This file can be used instead of specifying all the

77

ORACLE BACKUP STRATEGIES
options on the command line for each export.
query

Allows a subset of rows from a table to be exported,
based on a SQL where clause.

recordlength

Specifies the length of the file record in bytes. This
parameter affects the amount of data that accumulates before it
is written to disk. If not specified, this parameter defaults to the
value specific to that platform. The highest value is 64KB.

resumable

Enables and disables resumable space allocation. When
“Y”, the
parameters resumable_name andresumable_timeout are
utilized.

N

User defined string that helps identify a resumable
statement that has been suspended. This parameter is ignored
unless resumable = Y.

resumable_name

resumable_timeout
rows
statistics

The time period in which an export error must be fixed.
This parameter is ignored unless resumable = Y.

2h
Y
ESTIMATE

Indicates whether or not the table rows should be
exported.
Indicates the level of statistics generated when the data
is imported. Other options include COMPUTE and NONE.

tables

Indicates that the type of export is table-mode and lists
the tables to be exported. Table partitions and sub partitions
can also be specified.

tablespaces

Indicates that the type of export is tablespace-mode, in
which all tables assigned to the listed tablespaces will be
exported. This option requires the EXP_FULL_DATABASE role.

transport_tablespace
triggers
tts_full_check

N

Enables the export of metadata needed for transportable
tablespaces.

Y

Indicates whether triggers defined on export tables will
also be exported.

FALSE

When TRUE, export will verify that when creating a
transportable tablespace, a consistent set of objects is exported.
Specifies the userid/password of the user performing the

userid

export.
Specifies the maximum number of bytes in an export file
on each tape volume.

volsize

Example: exp system/s
file=C:\emp.dmp tables=scott.emp log=C:\emp.log
(Windows)
or
exp userid=system/s file=C:\emp.dmp tables=scott.emp log=C:\emp.log
(Windows)
USERID must be the first parameter on the command line.
11. Which are the IMP options ?
IMP Option
buffer

Default
value

Description
Specifies the size, in bytes, of the buffer (array) used to

78

ORACLE BACKUP STRATEGIES
insert the data

commit

N

Specifies whether import should commit after each array
insert. By default, import commits after each table is loaded,
however, this use a lot of the rollback segments or undo space
for huge tables.

compile

Y

Tells import to compile procedural objects when they are
imported.

constraints

Y

Specifies whether table constraints should also be
imported with table data.

datafiles
(only with
transport_tablespace)
destroy

feedback

This parameter lists data files to be transported to the
database.

N

0

Determines how often feedback is displayed. A value of
feedback=100 displays a dot for every 100 rows processed. This
option applies to the total tables imported, not individual ones.
Another way to measure the number of rows that have been
processed is to execute the following query while the import is
active:
SELECT rows_processed
FROM v$sqlarea
WHERE sql_text like 'INSERT %INTO "%'
AND command_type = 2
AND open_versions > 0;

The name of the export file to import. Multiple files can
be listed, separated by commas. When export reaches the
filesize it will begin writing to the next file in the list.

file

filesize

Maximum size of each dump file
A comma delimited list of schemas from which to
import. If the export file contains many users or even the entire
database, the fromuser option enables only a subset of those
objects (and data) to be imported.

fromuser

full
grants

Overwrite tablespace data file

The entire export file is imported.
Y

Specifies to import object grants.
Shows command line options for import
imp -help or imp help=y

help

ignore

N

indexes

Y

Specifies how object creation errors should be handled.
If a table already exists and ignore=y, then the rows are
imported to the existing tables, otherwise errors will be reported
and no rows are loaded into the table.
Determines whether indexes are imported.

79

ORACLE BACKUP STRATEGIES
Specifies a filename that contains index creation
statements. This file can be used to build the indexes after the
import has completed.

indexfile
log

The filename used by import to write messages.

parfile

The name of the file that contains the import parameter
options. This file can be used instead of specifying all the
options on the command line.

recordlength

Specifies the length of the file record in bytes. This
parameter is only used when transferring export files between
operating systems that use different default values.

resumable

N

User defined string that helps identify a resumable
statement that has been suspended. This parameter is ignored
unless resumable = Y.

resumable_name

resumable_timeout

When “Y”, the parameters resumable_name and
resumable_timeout are utilized.

The time period in which an error must be fixed. This
parameter is ignored unless resumable=Y.

2h

rows

Y

Indicates whether or not the table rows should be
imported.

show

N

When show=y, the DDL within the export file is
displayed.

N

Determines whether import skips the building of indexes
that are in an unusable state.

skip_unusable_indexes

statistics

ALWAYS

Determines the level of optimizer statistics that are
generated on import. The options include ALWAYS, NONE, SAFE
and RECALCULATE. ALWAYS imports statistics regardless of their
validity. NONE does not import or recalculate any optimizer
statistics. SAFE will import the statistics if they appear to be
valid, otherwise they will be recomputed after import.
RECALCULATE always generates new statistics after import.

streams_configuration

Y

Determines whether or not any streams metadata
present in the export file will be imported.

streams_instantiation

N

Specifies whether or not to import streams instantiation
metadata present in the export file

tables

Indicates that the type of export is table-mode and lists
the tables to be exported. Table partitions and sub partitions can
also be specified.

tablespaces

When transport_tablespace=y, this parameter provides a
list of tablespaces.

to_user

Specifies a list of user schemas that will be targets for
imports.

transport_tablespace
tts_owners
userid

N

When Y, transportable tablespace metadata will be
imported from the export file.
When transport_tablespace=Y, this parameter lists the
users who own the data in the transportable tablespace set.
Specifies the userid/password of the user performing the

80

ORACLE BACKUP STRATEGIES
import.
Example: imp system/manager file=/APPS/x.dmp tables=x fromuser=cs touser=cs
(Unix)
or
imp userid=system/manager file=/APPS/x.dmp tables=x fromuser=cs touser=cs
(Unix)
Note: USERID must be the first parameter on the command line.
12. Which are the common IMP/EXP problems?

ORA-00001: Unique constraint ... violated - Perhaps you are importing duplicate rows.
Use IGNORE=N to skip tables that already exist (imp will give an error if the object is recreated) or the table could be dropped/ truncated and re-imported if we need to do a table
refresh..

IMP-00015: Statement failed ... object already exists... - Use the IGNORE=Y import
parameter to ignore these errors, but be careful as you might end up with duplicate rows.

ORA-01555: Snapshot too old - Ask your users to STOP working while you are exporting or
use parameter CONSISTENT=NO (However this option could create possible referential
problems, because the tables are not exported from one snapshot in time).

ORA-01562: Failed to extend rollback segment - Create bigger rollback segments or set
parameter COMMIT=Y (with an appropriate BUFFER parameter ) while importing.
RMAN incremental backup for an Oracle DB
1. Incremental database backup Overview

Sometimes we need to backup the database changes only from the last backup (only
the last changes are backed up). This is an incremental backup. There are 2 types of
incremental backup: DIFFERENTIAL (by default) & CUMULATIVE.
NOTE: The incremental backups are only for the DATA files.
2. Incremental DIFFERENTIAL backup

DIFFERENTIAL backup = which backs up all blocks changed after the most recent
incremental backup at level 1 or 0. (See Picture 1). The following RMAN command is used to take a
DIFFERENTIAL database backup:
RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE;

81

ORACLE BACKUP STRATEGIES
3. Incremental CUMULATIVE backup

CUMULATIVE backup = which backs up all blocks changed after the most recent incremental
backup at level 0. (See Picture 2)
The following RMAN command is used to take a CUMULATIVE database backup:
RMAN> BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;
4. The advantages of each types of incremental backup
Here are the advantages of each types of incremental backup:
Advantages of the DIFFERENTIAL backup
1.
2.
3.

Less space disk used
Less network traffic
Less time to take a backup

Advantages of the CUMULATIVE backup
1.

Less time to recover

RMAN Configuration
1. Which is the default RMAN configuration ?
show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #
default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/oracle/10gOHome/dbs/snapcf_db10.f'; # default

82

ORACLE BACKUP STRATEGIES



NOTES:
The parameters which are currently modified are in bold.



The changes in the RMAN configuration are saved automatically in the control file/ RMAN
catalog.
2. How could I restore the actual configuration to the default value ?
CONFIGURE RETENTION POLICY CLEAR;
CONFIGURE BACKUP OPTIMIZATION CLEAR;
CONFIGURE DEFAULT DEVICE TYPE CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT CLEAR;
CONFIGURE DEVICE TYPE DISK CLEAR;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK CLEAR;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT CLEAR;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK CLEAR;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT CLEAR;
CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR;
CONFIGURE CHANNEL DEVICE TYPE SBT CLEAR;
CONFIGURE MAXSETSIZE CLEAR;
CONFIGURE SNAPSHOT CONTROLFILE NAME CLEAR;
3. Using substitution variables
RMAN can make use of substitution variables in creating format strings to generate UNIQUE
file names. If the file names are not unique the files will be overwritten and the data will be lost.
Format

Description

%d

specifies the database name.

%u

specifies an 8-character name constituted by compressed representations of the backup set
number and the time the backup set was created.

%p

specifies the backup piece number within the backup set. This value starts at 1 for each backup
set and is incremented by 1 as each backup piece is created.

%c

Specifies the copy number of the backup piece within a set of duplexed backup pieces. If you did
not issue the set duplex command, then this variable will be 1 for regular backup sets and 0 for proxy
copies. If you issued set duplex, the variable identifies the copy number: 1, 2, 3, or 4.

%U

Specifies a convenient shorthand for %u_%p_%c that guarantees uniqueness in generated backup
filenames. If you do not specify a format, RMAN uses %U by default.

%t

specifies the backup set timestamp. The combination of %s and %t can be used to form a unique
name for the backup set.

%s

specifies the backup set number. This number is a counter in the control file that is incremented
for each backup set. The counter value starts at 1 and is unique for the lifetime of the control file. If you
restore a backup control file, then duplicate values can result. Also, CREATE CONTROLFILE initializes the
counter back to 1.
4. Configure RETENTION POLICY
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 30 DAYS;
>> After 30 days the backup will become OBSOLETE.
CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
>> The latest 3 backups will NOT be OBSOLETE. The others will be.
When configuring a retention policy, RMAN will NOT cause backups to be automatically
deleted.

83

ORACLE BACKUP STRATEGIES
REPORT OBSOLETE; -> List the backups (on disk) that have become obsolete with the current
retention policy.
DELETE OBSOLETE; -> Delete the obsolete backup files.
delete noprompt obsolete;
NOTES:

crosscheck backup; -> check if the backup files exist physically on the disk


crosscheck copy; -> check if the files of a copy operation exist physically on the disk



list backup;



list expired backup; -> To identify those backups that were not found during a crosscheck

-> To list all backup sets, backup pieces



DELETE EXPIRED BACKUP; -> To delete the information about the expired backups in the
RMAN repository

DELETE EXPIRED COPY; -> To delete the information about the expired copies in the RMAN
repository
5. Configure DEFAULT DEVICE TYPE
CONFIGURE DEFAULT DEVICE TYPE TO DISK; --> by default
CONFIGURE DEFAULT DEVICE TYPE TO SBT;
This is overridden by the RUN command, or by DEVICE TYPE on the BACKUP command itself.
6. Configure CONTROLFILE AUTOBACKUP (starting from 9i)
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP OFF; --> by default
RMAN writes both the CONTROLFILE and the SPFILE (if the database was started with an SPFILE) to
the same backup piece.
To set the location of the Control file backup:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'/oracle/RMAN_backup/%F';
The %F tag is essential for RMAN to be able to restore the file without a recovery catalog.

RMAN incomplete recovery (in ARCHIVELOG mode)
- Using the TIME parameter:
run {
shutdown immediate;
startup mount;
set until time "to_date('May 17 2008 10:20:09 pm','Mon DD YYYY HH:MI:SS am')";
restore database;
recover database;
alter database open resetlogs;
}
- Using the SCN parameter:
run {
shutdown immediate;
startup mount;
set until scn 3400;
restore database;
recover database;
alter database open resetlogs;
}

84

ORACLE BACKUP STRATEGIES
- Using the SEQUENCE parameter:
run {
shutdown immediate;
startup mount;
set until sequence 12903;
restore database;
recover database;
alter database open resetlogs;
}
NOTE: The incomplete recovery requires the database to be opened using the RESETLOGS option.

RMAN incomplete recovery (in NOARCHIVELOG mode)
RMAN Incomplete Recovery Overview
An Incomplete Recovery is a Recovery which is done without restoring the database up to the failure
time. A typical case incomplete recovery is when the database is not in ARCHIVELOG. In this article I
will show how a backup could be taken for a database in NOARCHIVELOG mode and how a database
could be restored in case of failure.
Take a Full Backup with RMAN (database in NOARCHIVELOG)

Because the database is in NOARCHIVELOG mode, there is no need to take the
archive log files and the log files in backup. To take a backup with RMAN for a
database in NOARCHIVELOG, the instance must be in MOUNT state. However, if the
database is OPEN state, the instance could be put in mount state for the backup, and
after that the database will be opened. Here is the script
(RMAN_NOARCHIVELOG_backup.sh) we can use to take an backup for a database in
NOARCHIVELOG mode:
#/usr/bin/ksh
ORACLE_HOME=/DB1
export ORACLE_HOME
ORACLE_SID=db1
export ORACLE_SID
RMAN_LOG_FILE=/home/oracle/Desktop/Backup_rman/log/hot_database_backup.`date +%y%m%d
%H%M`.out
echo >> $RMAN_LOG_FILE
chmod 666 $RMAN_LOG_FILE
echo Script $0 >> $RMAN_LOG_FILE
echo ==== started on `date` ==== >> $RMAN_LOG_FILE

85

ORACLE BACKUP STRATEGIES
echo >> $RMAN_LOG_FILE
ORACLE_USER=oracle
TARGET_CONNECT_STR=sys/s
RMAN=$ORACLE_HOME/bin/rman

BACKUP_TYPE="INCREMENTAL LEVEL 0"

echo >> $RMAN_LOG_FILE
echo "RMAN: $RMAN" >> $RMAN_LOG_FILE
echo "ORACLE_SID: $ORACLE_SID" >> $RMAN_LOG_FILE
echo "ORACLE_USER: $ORACLE_USER" >> $RMAN_LOG_FILE
echo "ORACLE_HOME: $ORACLE_HOME" >> $RMAN_LOG_FILE
echo "BACKUP_TYPE: $BACKUP_TYPE" >> $RMAN_LOG_FILE
echo >> $RMAN_LOG_FILE
CMD_STR=""

$RMAN target $TARGET_CONNECT_STR catalog rman/r@dbr << EOF
shutdown immediate;
startup mount;

RUN {
ALLOCATE CHANNEL ch00 TYPE disk ;
ALLOCATE CHANNEL ch01 TYPE disk ;
ALLOCATE CHANNEL ch02 TYPE disk ;
BACKUP
$BACKUP_TYPE

86

ORACLE BACKUP STRATEGIES
SKIP INACCESSIBLE
TAG hot_db_bk_level0
FILESPERSET 5
# recommended format
FORMAT '/home/oracle/Desktop/Backup_rman/backup/bk_%s_%p_%t'
DATABASE;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
RELEASE CHANNEL ch02;
ALLOCATE CHANNEL ch00 TYPE disk;
BACKUP
# recommended format
FORMAT '/home/oracle/Desktop/Backup_rman/backup/cntrl_%s_%p_%t'
CURRENT CONTROLFILE;
RELEASE CHANNEL ch00;
}

alter database open;

EOF
When the RMAN_NOARCHIVELOG_backup.sh script will run, it will generate the following
log information:
[oracle@PROD scripts]$ ./RMAN_NOARCHIVELOG_backup.sh
Recovery Manager: Release 10.2.0.1.0 - Production on Wed Mar 26 22:59:41 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: DB1 (DBID=1244100437)
connected to recovery catalog database

87

ORACLE BACKUP STRATEGIES
RMAN>
database closed
database dismounted
Oracle instance shut down
RMAN>
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area 922746880 bytes
Fixed Size 1222624 bytes
Variable Size 268437536 bytes
Database Buffers 645922816 bytes
Redo Buffers 7163904 bytes
RMAN>
RMAN> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21> 22>
23>
allocated channel: ch00
channel ch00: sid=157 devtype=DISK
allocated channel: ch01
channel ch01: sid=155 devtype=DISK
allocated channel: ch02
channel ch02: sid=154 devtype=DISK
……………………………………………………
Starting backup at 26-MAR-08
channel ch00: starting incremental level 0 datafile backupset
channel ch00: specifying datafile(s) in backupset
channel ch01: backup set complete, elapsed time: 00:00:01
……………………………………………………
Finished backup at 26-MAR-08
released channel: ch00
released channel: ch01
released channel: ch02
allocated channel: ch00
channel ch00: sid=157 devtype=DISK
Starting backup at 26-MAR-08
channel ch00: starting full datafile backupset
channel ch00: specifying datafile(s) in backupset
including current control file in backupset
channel ch00: starting piece 1 at 26-MAR-08
channel ch00: finished piece 1 at 26-MAR-08
piece handle=/home/oracle/Desktop/Backup_rman/backup/cntrl_50_1_650415621

88

ORACLE BACKUP STRATEGIES
tag=TAG20080326T230021 comment=NONE
channel ch00: backup set complete, elapsed time: 00:00:01
Finished backup at 26-MAR-08
released channel: ch00
RMAN>
RMAN>
database opened
RMAN>
RMAN>
Recovery Manager complete.
[oracle@PROD scripts]$

Restore the database backup

Here is the way the database could be restored if all the files (+control files)
are lost:

$rman target / catalog rman/r@dbr;

RMAN> startup nomount;
connected to target database (not started)
Oracle instance started
Total System Global Area 922746880 bytes
Fixed Size 1222624 bytes
Variable Size 272631840 bytes
Database Buffers 641728512 bytes
Redo Buffers 7163904 bytes
RMAN> restore controlfile;
Starting restore at 26-MAR-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: restoring control file

89

ORACLE BACKUP STRATEGIES
channel ORA_DISK_1: reading from backup piece
/home/oracle/Desktop/Backup_rman/backup/cntrl_50_1_650415621
…………………………………………………………………………………….
Finished restore at 26-MAR-08
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN> restore database;
Starting restore at 26-MAR-08
Starting implicit crosscheck backup at 26-MAR-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
Crosschecked 36 objects
Finished implicit crosscheck backup at 26-MAR-08
…………………………………………………………………..
……………………………………………………………………
Finished restore at 26-MAR-08
RMAN> alter database open resetlogs;
database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN> exit;
NOTE: For a database which is in NOARCHIVELOG mode a cold backup by copying
the file is more appropriate. This example is just to illustrate how RMAN work.
RMAN Maintenance
1. How to register a new database with the RMAN Catalog

To register a new database to the RMAN catalog we have to be connected to the
RMAN catalog and to the new (target) database. After that we will use theREGISTER
DATABASE; command. See below:

90

ORACLE BACKUP STRATEGIES

During the database registration a full resynchronization is done automatically.
2. Resynchronization of the Database
RMAN catalog must keep all the metadata information about the target database upto-date. And every time some RMAN commands (like BACKUP & COPY) are executed
the RMAN catalog is synchronized with the database (controlfile).
There are 2 types of synchronization:

FULL : all the controlfile information is synchronize with the catalog

PARTIAL: the physical schema information (data files, tablespaces, online
files) is not synchronized; the information about the backups and new archive
log is synchronized.
When you run RESYNC CATALOG, RMAN creates a snapshot control file in order to obtain a
read-consistent view of the
control file, then updates the recovery catalog with any new information from the snapshot.
The RESYNC CATALOG command
updates the classes or records described in the following table.
Record Type

Description

Log history

Records that are created whenever a log switch occurs. Note that log history records
describe an online log switch, not a log archival.

Archived redo logs

Records associated with archived logs that were created by archiving an online redo log,
copying an existing archived redo log, or restoring backups of archived redo logs.

Backups

Records associated with backup sets, backup pieces, proxy copies, and image copies.

Physical schema

Records associated with datafiles and tablespaces. If the target database is open, then
rollback segment information is also updated.

(Only in FULL SYNC)
3. Resetting a Database

91

ORACLE BACKUP STRATEGIES

When ALTER DATABASE OPEN RESETLOG is run a new database incarnation is
created. This could be see in the V$DATABASE_INCARNATIONview of the target
database.

>> If this is done using RMAN, the RMAN will recognize the new database as a
new one and will use this new incarnation number for the following backups/ restore.
>> If this is NOT done using RMAN, the RMAN will NOT recognize the new
database as a new one. To let RMAN know that this is a new incarnation we have to
reset the database using the command: RESET DATABASE;

If we want to restore backups of a prior incarnation of the database, we can use
RESET DATABASE TO INCARNATION <incarnation_number>; command.

4. Generate Reports & Lists

RMAN> list backup;

-> To list all backup sets, backup pieces

RMAN> list expired backup; -> To identify those backups that were not found during
a
Crosscheck
RMAN> list backup by file;

-> List Backup by File

RMAN> list archivelog all; -> List all archived log files
RMAN> list backup summary; -> Backups summary

RMAN> crosscheck backup; -> check if the backup files exist physically on the disk

Use the need backup option to identify which datafiles need a new backup:
RMAN> report need backup days = 9 database; # needs at least 9 days of logs to
recover

92

ORACLE BACKUP STRATEGIES
RMAN> report need backup days = 23 tablespace system;
RMAN> report need backup days = 12 datafile '/oracle/oradata/data_file_15.dbf';

If complete recovery of a datafile requires more than the specified number of
incremental backups, then RMAN considers it in need of a new backup.

RMAN> report need backup incremental = 3 database;
RMAN> report need backup incremental = 6 tablespace system;
RMAN> report need backup incremental = 8 datafile
'/oracle/oradata/data_file_15.dbf';

Use the obsolete option to identify which backups are obsolete because they are no
longer needed for recovery. The redundancy parameter specifies the minimum level
of redundancy considered necessary for a backup or copy to be obsolete (if you do
not specify the parameter, redundancy defaults to 1).

RMAN> report obsolete redundancy = 2;
least 2 more recent backups or copies

-> Lists backups or copies that have at

For more information about REPORT command click here.
For more information about RMAN maintenace click here.

5. Unregister a Database from the Catalog

To unregister a a database from a RMAN catalog we have to use the
command UNREGISTER DATABASE; We must be connected to the RMAN Catalog and
also to the target database. See bellow:

93

ORACLE BACKUP STRATEGIES

6. Backup the Catalog

To be sure that the RMAN Catalog is not lost, the RMAN database must be in
ARCHIVELOG and maintained as an Oracle production database (must be backed up
daily). Also, logical backups for RMAN schema could be taken with imp/exp utility.
7.Delete the database files

To test the backup, I stop the database (even if is not mandatory :) ), I delete all the
database files (control files, log file, data files) and after that I restore the files using
RMAN.

If I want to startup the database I receive a message of error because the control
files are not present:

94

ORACLE BACKUP STRATEGIES

Restore & Recover the database using RMAN

To restore the database (physically the files are restored, but the files = the
database) we have to connect to the target database and recovery catalog, to startup
the database in nomount state, restore the control file and alter the database to be in
mount state.

95

ORACLE BACKUP STRATEGIES

In the mount state we have to run:

RMAN> RESTORE DATABASE;

(We can run RMAN> RESTORE DATABASE VALIDATE, as well to check that all is ok
and database could be opened.)

RMAN> RECOVER DATABASE;

And after that we can open the database (in RESETLOG mode)

96

ORACLE BACKUP STRATEGIES
RMAN> ALTER DATABASE OPEN RESETLOGS;

The new database will be registered with the RMAN catalog automatically:

Oracle MBR (Media Block Recovery in Oracle)
1. Test that there are no data block corruption in scott.EMP table

alter system flush buffer_cache; force to get the data from the data file and not from
the buffer cache.

97

ORACLE BACKUP STRATEGIES
2. Generate a data block corruption for EMP table

>> Find a block which keep EMP data :

SQL> col HEADER_BLOCK format 99999999
SQL> col SEGMENT_NAME format a12
SQL> col NAME format a35

SQL> select d.name, s.header_block, s.segment_name
from dba_segments s,
v$datafile_header d
where s.TABLESPACE_NAME = d.TABLESPACE_NAME
and s.segment_name = 'EMP'
and owner='SCOTT';

>> Write something wrong to the block 28 (the next block after the header) to
corrupt the block (at the OS level):
$ dd if=/dev/zero of=/DB1/oradata/db1/users01.dbf bs=8192 conv=notrunc seek=28
count=1

98

ORACLE BACKUP STRATEGIES

bs = block size
conv = convert the file ( In this case = do not truncate the output file)
seek = which block will be corrupt
count = how many blocks

>> Verify the data block corruption:

SQL> select * from emp;
select * from emp
*
ERROR at line 1:
ORA-08103: object no longer exists
NOTE: Select count(*) from emp; could be used also if there are no indexes on the
emp table;

3. Recover the corrupted block with RMAN

RMAN> blockrecover datafile 4 block 28;
Starting blockrecover at 03-FEB-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=144 devtype=DISK
channel ORA_DISK_1: restoring block(s)

99

ORACLE BACKUP STRATEGIES
………………………………………………………………………………
handle=/home/oracle/Desktop/Backup_rman/backup/bk_34_1_645659824 tag=HOT
_D B_BK_LEVEL0
channel ORA_DISK_1: block restore complete, elapsed time: 00:00:01
starting media recovery
archive log thread 1 sequence 3 is already on disk as file /DB1/flash_recovery_a
rea/DB1/archivelog/2008_02_02/o1_mf_1_3_3tb95vdp_.arc
archive log thread 1 sequence 4 is already on disk as file /DB1/flash_recovery_a
rea/DB1/archivelog/2008_02_02/o1_mf_1_4_3tbbkzk3_.arc
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=1
channel ORA_DISK_1: reading from backup piece
/home/oracle/Desktop/Backup_rman/b ackup/al_38_1_645659875
channel ORA_DISK_1: restored backup piece 1
……………………………………………………………………………………………….
……………………………………………………………………………………………….
media recovery complete, elapsed time: 00:00:01
Finished blockrecover at 03-FEB-08

4. Test that there are no data block corruption in scott.EMP table

select EMPNO,ENAME,JOB,MGR, HIREDATE from emp; will returm the emp data:

100

ORACLE BACKUP STRATEGIES

Cold Backup in Oracle (User Managed Backup)
1. User Managed Backup Overview

A user-managed backup is made by performing a physical copy of data files using the
OS commands. These copies are moved to a separate location using OS commands.
The user maintains a record of the backups. For the recovery operation we have to
move back (or to the new location of the database) the files and perform the
recovery.
The user-managed backups could be take at the following levels:


Data file level



Tablespace level



Database level

2. How could I take an online TABLESPACE level backup ?


the database should be in ARCHIVELOG mode



put the tablespace in "Begin Backup" mode
(example: ALTER TABLESPACE users BEGIN BACKUP; )



copy the physical files associated with this tablespace on another location
using OS commands



put the tablespace in "End Backup" mode
(example: ALTER TABLESPACE users END BACKUP; )



Archive the unachieved redo logs so that the redo required to recover the
tablespace backups is archived
( SQL> ALTER SYSTEMARCHIVE LOG CURRENT; )



Take a backup of all archived redo log files generated between Begin Backup
and End Backup using OS commands

NOTES:


Many tablespaces could be backed up in parallel. However, online redo logs
can grow large if multiple users are updating these tablespaces because the
redo must contain a copy of each changed data block. Oracle doesn't
recommend this.

101

ORACLE BACKUP STRATEGIES


When a tablespace is in backup mode, Oracle will stop updating its file
headers, but will continue to write to the data files. When in backup mode,
Oracle will write complete changed blocks to the redo log files. Normally
only deltas (change vectors) are logged to the redo logs. This is done to
enable reconstruction of a block if only half of it was backed up (split blocks).
Because of this, one should notice increased log activity and archiving during
on-line backups. To fix this problem, simply switch to RMAN backups.



If the tablespace is in READ ONLY mode, we don't need to put the tablespace
in Backup Mode.

3. Which are the files which could be backed up ?

SELECT name FROM v$datafile;
SELECT member FROM v$logfile;
SELECT name FROM v$controlfile;

To view which file correspond to which tablespace you can run:
SELECT t.NAME "Tablespace", f.NAME "Datafile"
FROM

V$TABLESPACE t,
V$DATAFILE f

WHERE

t.TS# = f.TS#

ORDER BY t.NAME;

4. How could I take an online FILE level backup ?


the database should be in ARCHIVELOG mode



put the datafile in OFFLINE mode
(example: ALTER DATABASE DATAFILE 'C:\oradata\file1.dbf' OFFLINE; )



copy the physical file on another location using OS commands



put the datafile in ONLINE mode
(example: ALTER DATABASE DATAFILE 'C:\oradata\file1.dbf' ONLINE; )



backup the control file as the database has gone through structural changes

102

ORACLE BACKUP STRATEGIES

5. TABLESPACE Recovery

This is done with SQL> RECOVER TABLESPACE command. It is possible to perform a
tablespace recovery while the rest of the database is online.

The prerequisites for a tablespace recovery are:


The tablespace must be OFFLINE (the database could be online)



Only COMPLETE recovery is possible



SYSTEM tablespace never can be recovered because is online all the time.

6. DATAFILE Recovery

This is done with SQL> RECOVER DATAFILE command. It is possible to perform a
data file recovery while the rest of the database is online or offline.

The prerequisites for a data file recovery are:


The data file must be OFFLINE (the database could be online)



SYSTEM data files never can be recovered because SYSTEM tablespace is
online all the time.

7. Closed Database Backup

If the database is down (shutdown IMMEDIATE, NORMAL) was used, we have only to
copy the data files, redo log files and control files to a new location. This kind of
backup is used for a database in NOARCHIVELOG which is not used for a 24x7
business.

103

ORACLE BACKUP STRATEGIES
8. Open Database Backup

An Open Database Backup is a backup taken when the database is up and running.
This is done by putting the tablespace in Backup mode and copying the data files and
control files. All the latest archived log files must be copied as well. The V$BACKUP
and V$DATAFILE_HEADER should be queried after the database backup to see if all
the data files are in online mode.

9. Backup the CONTROL file
Backup the binary file:
ALTER DATABASE BACKUP CONTROLFILE TO 'C:\backups\control1.bkp';
Generate the script to recreate the control file:
ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS 'C:\backups\control1.txt';
or
ALTER DATABASE BACKUP CONTROLFILE TO TRACE
USER_DUMP_DEST )

( the file will be created in

10. Perform Cleanup after a Failed Online Backup

An Online Backup failure can occurs if:


An instance failure occurs



An OS failure occurs



The database is accidentally shut down.

The database could be stopped by using shutdown abort. See the picture below:

104

ORACLE BACKUP STRATEGIES

When the database is brought up a media recovery is needed and the database will be
in mount state:

In mount state we can query the files to see what is happening (optional):

105

ORACLE BACKUP STRATEGIES

In Oracle 9i and + we can use RECOVER DATABASE to do an automatic recovery (the
database will be consistent again and the tablespace will not be in Backup mode).
After this recovery a new backup could be taken.

To see the status of the files during the online user-managed backups the following
select could be used:

106

ORACLE BACKUP STRATEGIES
SELECT decode(b.status, 'ACTIVE', 'BACKUP_IS_RUNNING',b.status) "Backup_Status",
b.time "Backup_Start_Time",
fh.status "File status",
fh.tablespace_name "Tablespace_Name",
fh.name "File_Name"
FROM v$backup b,
v$datafile_header fh
WHERE b.file#=fh.file#;

RMAN & SMR (Server-Managed Recovery)
1. What is RMAN?
RMAN can be used to backup and restore database files, archive logs, and control files. It can also be
used to perform complete or incomplete database recovery. Note that RMAN cannot be used to backup
initialization files or password files.
RMAN starts Oracle server processes on the database to be backed up or restored. The backup,
restore, and recovery is driven through these processes hence the term ‘server-managed recovery’.
Note that SMR can also be controlled from OEM’s Backup Manager GUI. This
article will not discuss Backup Manager.
2. Terminology
2.1. Backup sets
A backup set is characterised by the following:
- Contains one or more datafiles or archivelogs
- Stored in an Oracle proprietary format
- Comprises a complete set of backup pieces

107

ORACLE BACKUP STRATEGIES

- Constitutes a full or incremental backup
2.2. Backup pieces
A backup set is comprised of a number of backup pieces. Each backup piece is a single output file. The
size of a backup piece can be restricted; if the size is not restricted, the backup set will comprise one
backup piece. Backup piece size should be restricted to no larger than the maximum file size that your
filsystem will support.
2.3. Image copies
An image copy is a copy of a single file (datafile, archivelog, or controlfile). It is very similar to an O/S
copy of the file. It is not a backupset or a backup piece. No compression is performed.
2.4. Full backup sets
A full backup is a backup of one or more datafiles that contains all used blocks in the datafile. Blocks
that have never been used are not backed up i.e. oracle performs backup set compression.
2.5. Incremental backup sets
An incremental backup is a backup of one or more datafiles that contains only those blocks that have
been modified since a previous backup at the same or lower level. As with full backups, compression is
performed.
2.6. File multiplexing
Datablocks from multiple datafiles can be multiplexed in the same backupset.
2.7. Recovery catalog resyncing
Resyncing the recovery catalog involves synchronising the recovery catalog with the target database
controlfile. Certain operations perform this implicitly. To resync manually, issue the ‘resync catalog;’
command from RMAN. The catalog should be resynced frequently, especially if the target database
generates many archive logs. It should also be resynced after making any structural changes to the
target database. Although the target database’s controlfile is automatically updated whenever new
controlfile records are created (for example, creation of new archived logs or new datafiles), if the

108

ORACLE BACKUP STRATEGIES

target is not resync’d and a backup controlfile is restored, the new records must be cataloged
manually (catalog archivelog ‘<logname>’;).
2.8. Snapshot Controlfile
When RMAN needs to resynchronize from a read-consistent version of the control file, it creates a
temporary snapshot control file. The default name for the snapshot control file is port-specific. Use the
‘set snapshot controlfile name to file_name’ command to change the name of the snapshot control
file; subsequent snapshot control files that RMAN creates use the name specified in the command. The
snapshot control file name can also be set to a raw device. This operation is important for OPS
databases in which more than one instance in the cluster use RMAN because server sessions on each
node must be able to create a snaphost control file with the same name and location.
2.9. Resetlogs Operation
Whenever you open the database with the RESETLOGS option, all datafiles get a new RESETLOGS SCN
and timestamp. Archived redo logs also have these two values in their header. Because Oracle will not
apply an archived redo log to a datafile unless the RESETLOGS SCN and timestamps match, the
RESETLOGS operations prevents you from corrupting your datafiles with old archived logs.
2.1.0 Database Incarnation
Whenever you perform incomplete recovery or perform recovery using a backup control file, you must
reset the online redo logs when you open the database. The new version of the reset database is
called a new incarnation. All archived redo logs generated after the point of the RESETLOGS on the
old incarnation are invalid in the new incarnation.
2.1.1. Resetting the Recovery Catalog
Before you can use RMAN again with a target database that you have opened with the RESETLOGS
option, notify RMAN that you have reset the database incarnation. The reset database command
directs RMAN to create a new database incarnation record in the recovery catalog. This new
incarnation record indicates the current incarnation. RMAN associates all subsequent backups and log
archiving done by the target database with the new database incarnation. If you issue the ALTER
DATABASE OPEN RESETLOGS statement but do not reset the database, then RMAN cannot access the
recovery catalog because it cannot distinguish between a RESETLOGS command and an accidental
restore of an old control file. By resetting the database, you inform RMAN that the database has been

109

ORACLE BACKUP STRATEGIES

opened with the RESETLOGS option. In the rare situation in which you wish to undo the effects of
opening with the RESETLOGS option by restoring backups of a prior incarnation of the database, use
the ‘reset database to incarnation key’ command to change the current incarnation to an older
incarnation.
3. The recovery catalog
The recovery catalog is a repository of information that is used and maintained by RMAN. RMAN uses
the information in the recovery catalog to determine how to execute requested backup and restore
actions..’. The recovery catalog can be in a schema of an existing Oracle8 database. However if RMAN
is being used to backup multiple databases, it is probably worth creating a dedicated recovery catalog
database. THE RECOVERY CATALOG DATABASE CANNOT BE USED TO CATALOG BACKUPS OF ITSELF.To
set up the recovery catalog, firstly ensure that catalog and catproc have been run, then execute the
following:
SVRMGR> spool create_rman.log
SVRMGR> connect internal
SVRMGR> create user rman identified by rman
temporary tablespace temp
default tablespace rcvcat quota unlimited on rcvcat;
SVRMGR> grant recovery_catalog_owner to rman;
SVRMGR> grant connect, resource to rman;
Note: Following steps only apply for an Oracle8 8.0.x catalog creation.
SVRMGR> connect rman/rman
SVRMGR> @?/rdbms/admin/catrman
Check create_rman.log for errors. The above commands assume that the
TEMP and RCVCAT tablespaces have been created.
In Oracle8i the catalog is created a little differently.
Note: Following steps only apply to Oracle8i 8.1.5 and greater.
From the UNIX shell run:

110

ORACLE BACKUP STRATEGIES

% set ORACLE_SID=RCAT
% rman catalog rman/rman
RMAN> create catalog;
This will generate the recovery catalog schema in the default tablespace for
RMAN.
Also ensure that catproc has been run on the target database as SYS
(do _not_ use SYSTEM); RMAN makes extensive use of RPCs.
It is very important that the recovery catalog database is backed up
regularly and frequently.
Note: Although you are not required to use a recovery catalog with RMAN,

it is

recommended. Because most of the information in the recovery catalog is available via the
target database’s controlfile, RMAN can use this information for recovery purposes.
4. Starting RMAN
RMAN has a command line interface, or can be run from Enterprise Manager. For the purposes of this
document, only the CLI will be covered. The command line interface has following syntax:
rman target <qstring> [rcvcat <qstring> | cmdfile <qstring> |
msglog <qstring> | append | trace <qstring>]
Argument

Quoted String Description

TARGET A connect string containing a userid and password for the database on which Recovery
Manager is to operate.
rman target system/manager@target
RCVCAT A connect string that contains a userid and password for the database that contains the
recovery catalog.
rman rcvcat rman/rman@rcvcat

111

ORACLE BACKUP STRATEGIES

CMDFILE The name of a file that contains the input commands for RMAN. If this argument is specified,
RMAN operates in batch mode; otherwise, RMAN operates in interactive line mode. MSGLOG The name
of a file where RMAN records commands and output Results. If not specified, RMAN outputs to the
screen. APPEND This parameters causes the msglog file to be opened in append mode. If this
parameter is not specified and a file with the same name as the msglog file already exists, it is
overwritten.
TRACE

A file name where RMAN will dump a trace information.

(useful feature for RMAN jobs debugging)
For the purposes of the following examples, assume that
- the target database is called “targdb” and has the same TNS alias
- “targdba” has been granted SYSDBA privileges
- the recovery catalog database is called “rcat” and has the same TNS alias
- the schema containing the recovery catalog is “rman” (same password)
Before invoking RMAN, set the NLS_DATE_FORMAT and NLS_LANG environment variables. Much of the
RMAN LIST output is date/time related. It is often necessary to have this information displayed as
accurately as possible when performing time-based recovery. Example NLS settings:
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
NLS_DATE_FORMAT=DD-MON-YYYY HH24:MI:SS
For RMAN to connect to the recovery catalog and the target database, the recovery catalog database
must be OPEN, while the target instance must be at least STARTED. If not, RMAN will give an error. To
perform backups with the target database open, the target MUST be in archivelog mode.
4.1. Connecting to RMAN without a recovery catalog
Set ORACLE_SID to be the target database, and issue the following:
% rman nocatalog
RMAN> connect target
or if the target database uses a password file,
RMAN> connect target targdba/<password>@targdb
4.2. Connecting to RMAN with a recovery catalog

112

ORACLE BACKUP STRATEGIES

% rman rcvcat rman/rman@rcat
RMAN> connect target
or if the target database uses a password file,
% rman rcvcat rman/rman@rcat target targdba/<password>@targdb
Note: Recovery Manager automatically requests a connection to the target database as
SYSDBA. In order to connect to the target database as SYSDBA, you must either:
1. Be part of the operating system DBA group with respect to the target database. This
means that you have the ability to CONNECT INTERNAL to the target database without a
password.
-or 2. Have a password file setup. This requires the use of the “orapwd” command and the
initialization parameter “remote_login_passwordfile”.
Note: The connect string (for example, @targdb) should be a valid TNS alias, as specified in
the local to the rman utility tnsnames.ora file .
4.3. Using RMAN
Once connected to the target database, you can specify RMAN commands either interactively or by
using stored scripts. An example of using RMAN interactively would be:
RMAN> resync catalog;
An example of calling a stored script would be:
RMAN> execute script alloc_1_disk;
To create/replace a stored script:
RMAN> replace script alloc_1_disk {
2> allocate channel d1 type disk;
3> }
5. Register the target database

113

ORACLE BACKUP STRATEGIES

Database status:
Recovery catalog: open
Target: mounted or open
The target database must be registered with the recovery catalog before using RMAN against the
database for the first time:
RMAN> register database;
6. Adding existing backups to the recovery catalog
Database status:
Recovery catalog: open
Target: mounted or open
If user-created backups existed under version 8.x prior to registering with the target database, these
can be added to the recovery catalog as follows:
RMAN> catalog datafilecopy ‘/supp/ …. /systargdb.dbf’;
To view this file in the catalog, use the following command:
RMAN> list copy of database;
7. Backing up in noarchivelog mode
Database status:
Recovery catalog: open
Target: database mounted
Recovery catalog database is OPEN, target database is started (optionally mounted). Because the
target database is not in archivelog mode, it must not be open when performing backups of datafiles.
This would be equivalent of making filesystem copies of datafiles without putting tablespaces into
hot backup mode. If the database is open and not in archivelog mode, RMAN will generate an error
when you attempt to perform a datafile backup
7.1. Example of how to back up a complete database

114

ORACLE BACKUP STRATEGIES

RMAN> run {
2> # backup the complete database to disk
3> allocate channel dev1 type disk;
4> backup
5> full
6> tag full_db_sunday_night
7> format ‘/oracle/backups/db_t%t_s%s_p%p’
8> (database);
9> release channel dev1;
10> }
Line#
2: Comment line (anything after the ‘#’ is a comment)
3&9: See section 15 – Channels
5: Full backup (default if full or incremental not specified)
6: Meaningful string (<=30 chars)
7: Filename to use for backup pieces, including substitution variables.
8: Indicates all files including controlfiles are to be backed up
To view this backup in the catalog, use the following command:
RMAN> list backupset of database;
7.2. Example of how to back up a tablespace
RMAN> run {
2> allocate channel dev1 type disk;
3> backup
4> tag tbs_users_read_only
5> format ‘/oracle/backups/tbs_users_t%t_s%s’
6> (tablespace users);
7> release channel dev1;
10> }
Line#
6: Specifying only the USERS tablespace for backup

115

ORACLE BACKUP STRATEGIES

To view this tablespace backup in the catalog, use the following command:
RMAN> list backupset of tablespace users;
If for example the USERS tablespace is going to be put READ ONLY after being backed up, subsequent
full database backups would not need to backup this tablespace. To cater for this, specify the ‘skip
readonly’ option in subsequent backups.
Note that although this is a tablespace backup, the target database does NOT have to be
open, only mounted. This is because tablespace information is stored in the controlfile in
o8.
7.3. Example of how to backup individual datafiles
RMAN> run {
2> allocate channel dev1 type ‘SBT_TAPE’;
3> backup
4> format ‘%d_%u’
5> (datafile ‘/oracle/dbs/sysbigdb.dbf’);
6> release channel dev1;
7> }
Line#
2: Allocates a tape drive using the media manager layer (MML)
Note that no tag was specified and is therefore null.
To view this tablespace backup in the catalog, use the following command:
RMAN> list backupset of datafile 1;
7.4. Copying datafiles
RMAN> run {
2> allocate channel dev1 type ‘SBT_TAPE’;
3> copy datafile ‘/oracle/dbs/temp.dbf’ to ‘/oracle/backups/temp.dbf’;
4> release channel dev1;
5> }

116

ORACLE BACKUP STRATEGIES

To view this file copy in the catalog, use the following command:
RMAN> list copy of datafile ‘/oracle/dbs/temp.dbf’;
Copying a datafile is different to backing up a datafile. A datafile copy is an image copy of the file. A
backup of the file creates a backupset.
7.5. Backing up the controlfile
RMAN> run {
2> allocate channel dev1 type ‘SBT_TAPE’;
3> backup
4> format ‘cf_t%t_s%s_p%p’
5> tag cf_monday_night
6> (current controlfile);
7> release channel dev1;
8> }
Note that a database backup will automatically back up the controlfile.
8. Backing up in archivelog mode
Database status:
Recovery catalog: open
Target: instance started, database mounted or open
The commands are identical to those in section 7 except that the target database is in archivelog
mode.
8.1. Backing up archived logs
The following script backs up all archive logs:
RMAN> run {
2> allocate channel dev1 type disk;
3> backup
4> format ‘/oracle/backups/log_t%t_s%s_p%p’
5> (archivelog all);

117

ORACLE BACKUP STRATEGIES

6> release channel dev1;
7> }
The following script backs up archive logs from sequence# 90 to 100:
RMAN> run {
2> allocate channel dev1 type disk;
3> backup
4> format ‘/oracle/backups/log_t%t_s%s_p%p’
5> (archivelog from logseq=90 until logseq=100 thread 1);
6> release channel dev1;
7> }
The following script backs up all archive logs generated in the past 24 hours. Furthermore it actually
deletes the logs after backing them up. If the backup fails, logs will NOT be deleted:
RMAN> run {
2> allocate channel dev1 type disk;
3> backup
4> format ‘/oracle/backups/log_t%t_s%s_p%p’
5> (archivelog from time ‘sysdate-1′ all delete input);
6> release channel dev1;
7> }
To view the archive logs in the catalog, use the following command:
RMAN> list backupset of archivelog all;
Note that RMAN will backup specified logs if it finds them. If it can’t find a log, it will report
rman-6089 error: “archived log %s not found or out of sync with catalog”, and it will abort
a backup session.
8.2. Backing up the online logs
Online logs CANNOT be backed up using RMAN; they must be archived first. To do this, you can issue
SQL commands from RMAN e.g.

118

ORACLE BACKUP STRATEGIES

RMAN> run {
2> allocate channel dev1 type disk;
3> sql “alter system archive log current”;
4> backup
5> format ‘/oracle/backups/log_t%t_s%s_p%p’
6> (archivelog from time ‘sysdate-1′ all delete input);
7> release channel dev1;
8> }
The above script might be run after performing a full ‘database open’ backup. It would ensure that all
redo to recover the database to a consistent state would be backed up.
Note, you cannot tag archive log backupsets.
9. Incremental backups
A level N incremental backup backs up blocks that have changed since the most recent incremental
backup at level N or less.
9.1. Level 0 – the basis of the incremental backup strategy
RMAN> run {
2> allocate channel dev1 type disk;
3> backup
4> incremental level 0
5> filesperset 4
6> format ‘/oracle/backups/sunday_level0_%t’
7> (database);
8> release channel dev1;
9> }
Line#
4: Level 0 backup – backups of level > 0 can be applied to this
5: Specifies maximum files in the backupset
A list of the database backupsets will show the above backup. The ‘type’
column is marked ‘Incremental’; the ‘LV’ column shows ’0′.

119

ORACLE BACKUP STRATEGIES

9.2. Example backup strategy using incremental backups
A typical incremental backup cycle would be as follows:
- Sun night – level 0 backup performed
- Mon night – level 2 backup performed
- Tue night – level 2 backup performed
- Wed night – level 2 backup performed
- Thu night – level 1 backup performed
- Fri night – level 2 backup performed
- Sat night – level 2 backup performed
If the database suffered a failure on Sat morning and this resulted in a restore operation, RMAN could
recover to the point of failure by restoring the backups from Sunday, Thursday, and Friday. This is
because Thursdays level 1 backup contains all changes since Sunday, and Friday’s level 2 backup
contains all changes since Thursday. Whether the database could be completely recovered would
depend on whether archive logging is enabled.
10. Cumulative incremental backups
A cumulative incremental backup backs up all blocks that have changed since the the most recent
incremental backup at level N-1 or less (contrast with non-cumulative incremental backups that
backup blocks that have changed since the the most recent incremental backup at level N or less).
This means that more work is done in performing the backup (duplication of backup effort), but time
may be saved when restoring (potentially fewer backupsets to restore).
RMAN> run {
2> allocate channel dev01 type disk;
3> backup incremental level 1 cumulative database;
4> release channel dev01;
5> }
11. Checking backup progress
To check the backup progress run the following sql against the target database:
select sid, serial#, context
round(sofar/totalwork*100,2) “% Complete”,

120

ORACLE BACKUP STRATEGIES

substr(to_char(sysdate,’yymmdd hh24: mi:ss’),1,15) “Time Now”
from v$session_longops
where compnam = ‘dbms_backup_restore’; — for 8.0
where substr(opname,1,4) = ‘RMAN’;

— for 8.1

This will produce an output such as:
SID

SERIAL#

———- ———-

CONTEXT

———-

% Complete

—————–

12

Time Now

—————

56

980408 14:21:07

12. Recovery
As with backup, recovery is probably best explained with a few examples
12.1. Database open, datafile deleted
Datafile has been deleted from a running database. There are two methods of open database
recovery: restore the datafile and recover either the datafile, or the tablespace. The next two
examples show both methods:
(a) Datafile recovery
RMAN> run {
2> allocate channel dev1 type disk;
3> sql “alter tablespace users offline immediate”;
4> restore datafile 4;
5> recover datafile 4;
6> sql “alter tablespace users online”;
7> release channel dev1;
8> }
(b) Tablespace recovery
RMAN> run {
2> allocate channel dev1 type disk;
3> sql “alter tablespace users offline immediate”;
4> restore tablespace users;

121

ORACLE BACKUP STRATEGIES

5> recover tablespace users;
6> sql “alter tablespace users online”;
7> release channel dev1;
8> }
Note that if it is the system tablespace datafiles to be restored, the database must be
closed. It is not possible to offline the system tablespace.
12.2. Complete restore (lost online redo) and rollforward – database closed
RMAN> run {
2> allocate channel dev1 type disk;
3> set until logseq=105 thread=1;
4> restore controlfile to ‘/oracle/dbs/ctrltargdb.ctl’;
5> replicate controlfile from ‘/oracle/dbs/ctrltargdb.ctl’;
6> restore database;
7> sql “alter database mount”;
8> recover database;
9> sql “alter database open resetlogs”;
10> release channel dev1;
11> }
RMAN> reset database;
Notes:
- The ‘set until’ command dictates at which log sequence recovery will stop. It is critical
that this command is issued BEFORE datafiles are restored, otherwise RMAN will attempt to
restore the most recent set of datafiles, which could be ahead of the specified log
- The ‘replicate controlfile’ copies the restored controlfile to the controlfiles referenced in
init.ora
- Because the database is opened with resetlogs, it is necessary to register the new
incarnation of the database with the RESET DATABASE command. As with v7, it is important
to take a full backup of the database immediately after a resetlogs
12.3. Restore of a subset of datafiles, complete recovery
RMAN> run {
2> allocate channel dev1 type disk;
3> sql “alter database mount”;

122

ORACLE BACKUP STRATEGIES

4> restore datafile 2;
5> restore datafile 3;
6> restore archivelog all;
7> recover database;
8> sql “alter database open”;
9> release channel dev1;
10> }
13. Scripts
It is very easy to create and replace stored scripts with RMAN. E.g.
RMAN> create script alloc_disk {
2> # Allocates one disk
3> allocate channel dev1 type disk;
4> setlimit channel dev1 kbytes 2097150 maxopenfiles 32 readrate 200;
5> }
RMAN> replace script rel_disk {
2> # releases disk
3> release channel dev1;
5> }
RMAN> replace script backup_db_full {
2> # Performs a complete backup
3> execute script alloc_disk;
4> backup
5> …..<backup commands here>
6> execute script rel_disk;
7> }
The first 2 scripts allocate and deallocate channels respectively. The alloc_disk script additionally
specifies the maximum size of backup pieces created on this channel (kbytes), the maximum number
of input files that a backup will have open (maxopenfiles), and the maximum number of buffers per
second which will be read from each of the input datafiles. The 3rd script calls the previously stored
scripts either side of performing a backup.

123

ORACLE BACKUP STRATEGIES

Example of executing a stored script:
RMAN> run {
2> execute script backup_db_full;
3> }
Note that a stored scripts must be called from within a job command list i.e. run { ….
execute <script>; ….}.
It is possible to create a job command list in a flat file and call that script from the O/S command line
as an RMAN option. E.g. to call scripts stored in a file called ‘weekly_cold_backup’: % rman <other
RMAN options> cmdfile weekly_cold_backup
14. Parallelization
RMAN can parallelize it’s operations. When creating backup sets, the granule of parallelization is the
backup set. E.g. if your backup consists of 10 backup sets, RMAN will potentially use 10 channels. To
create an environment for this to take place, you must allocate sufficient channels and dictate the
number of backup sets created (using the filesperset parameter). E.g. if you are backing up a
database consisting of 50 datafiles and you allocate 20 channels and specify ‘filesperset 10′,
only 5 channels will be used. This is because only 5 backup sets (50/10) will be created. It is also
possible to parallelize datafile copy backups by allocating multiple channels, and specifying multiple
datafiles in one copy command.
15. Corruption detection
SMR will back up datafiles that contain corrupt blocks. However it is possible to set a limit on the
number of datablock corruptions; if this limit is exceeded the backup terminates. The limit is set using
the ‘set maxcorrupt’ clause.
E.g.
RMAN> replace script backup_db_full {
2> # Performs a complete backup
3> execute script alloc_disk;
4> set maxcorrupt for datafile 1 to 0;
5> backup
6> …..<backup commands here>

124

ORACLE BACKUP STRATEGIES

7> execute script rel_disk;
8> }
When the above script the backup will fail if ANY corrupt blocks are found in datafile 1. Block
corruptions are detected by checksum mismatches during backups. The checksum option is enabled
by default but can be disabled by specifying the ‘nochecksum’ option.
16. Channels
A channel is a connection from RMAN to a target database. The ‘allocate channel’ command starts a
server process on the target instance. It also specifies the type of I/O device that the server process
will use to perform the backup or restore operation.
Channel control commands can be used to:
- Control the O/S resources RMAN uses
- Affect the degree of parallelism (see section 13)
- Specify limits on I/O bandwidth (set limit read rate)
- Specify limits on the size of backup pieces (set limit kbytes)
- Specify limits on the number of concurrently open files (set limit maxopenfiles)
17. Report & list commands
17.1. List
The list command queries the recovery catalog to produce a formatted listing of contents. E.g.
RMAN> list backupset of datafile 1;
Output:
Key File Type LV Completion_time Ckp SCN Ckp Time
——- —- ———— — ————— ———- ——–
165 1 Full Oct 03 11:24 32022 Oct 03 11:24
208 1 Full Oct 24 14:27 52059 Oct 24 14:26
219 1 Full Oct 24 14:31 52061 Oct 24 14:31
<< other entries here >

125

ORACLE BACKUP STRATEGIES

RMAN> list backupset of archivelog all;
Output:
Key Thrd Seq Completion time
——- —- ——- —————
179 1 94 Oct 03 11:26
179 1 95 Oct 03 11:26
<< other entries here >
17.2. Report
The report command also queries the recovery catalog, However, the report command syntax is
constructed in such a way to produce a more useful listing. E.g. the following command can be used to
list all datafiles in a database that have had UNRECOVERABLE operations performed on objects in
those datafiles since the last backup:
RMAN> report unrecoverable database;
18. Hints, tips, & best practices
18.1. Resyncing the recovery catalog
It is very important that the recovery catalog be as up to date as possible i.e. it should reflect the
state of the target database. This is achieved by resyncing the catalog from the target controlfile.
There are two types of resync operation: full and partial. Furthermore a resync can be explicit or
implicit. A full resync updates the catalog with ALL controlfile information that has changed since the
last resync. This includes changes to the physical structure of the database. A manual (explicit) resync
performs a full resync, whilst full (implicit) resyncs are performed after an SMR backup. A partial
resync only updates the catalog with redo log, backupset, and datafile copy information i.e. physical
structure changes are NOT refreshed. A partial (implicit) resync is performed before an SMR backup.
At a MINIMUM, you should resync the recovery catalog at intervals less than the init.ora parameter
CONTROL_FILE_RECORD_KEEP_TIME. After this number of days, controlfile information will be
overwritten. Because resyncing is a relatively cheap operation, it is advisable to resync as often as
possible, especially if the database switches logs frequently. The following sample shell script could be
scheduled to run hourly:

126

ORACLE BACKUP STRATEGIES

rman target un/pw@<target alias> rcvcat un/pw@<rcvcat alias> << EOF
resync catalog;
exit;
EOF
18.2. Deleting archive logs
As can be seen from an earlier example, it is possible to direct an SMR server session to delete
archived redo logs once they have been backed up. This option should obviously be used with extreme
caution! Only ever delete archivelogs if you are 100% satisfied that you have good copies/backups
elsewhere.
18.3. Keep it simple
As with all backup & recovery strategies, they should be as simple as possible, and should be tested
thoroughly. A few simple stored scripts should be adequate for the vast majority of backup & recovery
requirements.
18.4. RMAN errors
When RMAN goes wrong it’s spectacular! The error stacks are usually very long. If an error is
reported, it is worth getting the complete stack sent to support as most of the errors will not help in
diagnosing the problem.
19. Limitations
19.1 Enterprise Edition
Only the following features are available with the Enterprise Edition software:
Multiple Channels
Incremental Backups
Duplexed Backups
Top 10 Backup and Recovery best practices.
This document assumes that you are doing the Backup and Recovery basics
- Running in Archivelog mode
- multiplexing the controlfile

127

ORACLE BACKUP STRATEGIES

- Taking regular backups
- Periodically doing a complete restore to test your procedures.
Questions and Answers
1. Turn on block checking.
REASON: The aim is to detect, very early the presence of corrupt blocks in the database. This has a
slight performance overhead, but will allow Oracle to detect early corruption caused by underlying
disk, storage system, or I/O system problems.
SQL> alter system set db_block_checking = true scope=both;
2. Turn on block tracking when using RMAN backups (if running 10g)
REASON: This will allow RMAN to backup only those blocks that have changed since the last full
backup, which will reduce the time taken to back up, as less blocks will be backed up.
SQL> alter database enable block change tracking using file ‘/u01/oradata/ora1/change_tracking.f’;
3. Duplex log groups and members and have more than one archive log dest.
REASON: If an archivelog is corrupted or lost, by having multiple copies in multiple locations,
the other logs will still be available and could be used. If an online log is deleted or becomes corrupt,
you will have another member that can be used to recover if required.
SQL> alter system set log_archive_dest_2=’location=/new/location/archive2′ scope=both;
SQL> alter database add logfile member ‘/new/location/redo21.log’ to group 1;
4. When backing up the database use the ‘check logical’ parameter
REASON: This will cause RMAN to check for logical corruption within a block as well as the normal
head/tail checksumming. This is the best way to ensure that you will get a good backup.
RMAN> backup check logical database plus archivelog delete input;
5. Test your backup.
REASON: This will do everything except actually restore the database. This is the best method to
determine if your backup is good and usable before being in a situation where it is critical and issues
exist.
RMAN> restore validate database;
6.Have each datafile in a single backup piece
REASON: When doing a partial restore RMAN must read through the entire piece to get the
datafile/archivelog requested. The smaller the backup piece the quicker the restore can
complete. This is especially relevent with tape backups of large databases or where the restore
is only on individual / few files.
RMAN> backup database filesperset 1 plus archivelog delete input;
7. Maintain your RMAN catalog/controlfile
REASON: Choose your retention policy carefully. Make sure that it compliments your tape subsystem

128

ORACLE BACKUP STRATEGIES

retention policy, requirements for backup recovery strategy. If not using a catalog, ensure that your
controlfile record keep time instance parameter matches your retention policy.
SQL> alter system set control_file_record_keep_time=21 scope=both;
This will keep 21 days of backup records.
Run regular catalog maintenance.
REASON: Delete obsolete will remove backups that are outside your retention policy. If obsolete
backups are not deleted, the catalog will continue to grow until performance becomes an issue.
RMAN> delete obsolete;
REASON: crosschecking will check that the catalog/controlfile matches the physical backups.
If a backup is missing, it will set the piece to ‘EXPIRED’ so when a restore is started, that it will not be
eligible, and an earlier backup will be used. To remove the expired backups from the catalog/controlfile
use the delete expired command.
RMAN> crosscheck backup;
RMAN> delete expired backup;
8. Prepare for loss of controlfiles.
set autobackup on
REASON: This will ensure that you always have an up to date controlfile available that has been
taken at the end of the current backup not during.
RMAN> configure controlfile autobackup on;
keep your backup logs
REASON: The backup log contains parameters for your tape access, locations on controlfile backups
that can be utilised if complete loss occurs.

9. Test your recovery
REASON: During a recovery situation this will let you know how the recovery will go without
actually doing it, and can avoid having to restore source datafiles again.
SQL> recover database test;
10. Do not specify ‘delete all input’ when backing up archivelogs
REASON: Delete all input’ will backup from one destination then delete both copies of the archivelog
where as ‘delete input’ will backup from one location and then delete what has been backed up. The
next backup will back up those from location 2 as well as new logs from location 1, then delete all that
are backed up. This means that you will have the archivelogs since the last backup available on disk in
location 2 (as well as backed up once) and two copies backup up prior to the previous backup.
RMAN

129

ORACLE BACKUP STRATEGIES

Server Machine(The Database Which has to be BackUp):
Set The Listener in the default path
[oracle@REDDY ~]$ vi
/home/oracle/oracle/product/10.2.0/db_1/network/admin/listener.ora
Using netmgr
Listener must be started
[oracle@REDDY admin]$ lsnrctl
LSNRCTL for Linux: Version 10.2.0.1.0 – Production on 19-NOV-2008 11:47:14
Copyright (c) 1991, 2005, Oracle. All rights reserved.
Welcome to LSNRCTL, type “help” for information.
LSNRCTL> start
——————–
——————–
LSNRCTL> exit
Password File is created in the default path
[oracle@REDDY admin]$ cd $ORACLE_HOME/dbs
[oracle@REDDY dbs]$ orapwd file=orapwtarun password=tarun entries=5
Set in the parameter file
[oracle@REDDY dbs]$ vi inittarun.ora
——————-

130

ORACLE BACKUP STRATEGIES

——————*.remote_login_passwordfile=’exclusive’
————————————:wq!
Enable the archivelog
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /home/oracle/tarun/archive
Oldest online log sequence 41
Next log sequence to archive 42
Current log sequence 42
Client Machine(Catalog database is placed,RMAN configuration is done):
Create separate tablespace for rman
SQL> create tablespace rman_tbs datafile’/home/oracle/tarun4/datafiles/rman01.dbf’ size 20m;
Tablespace created.
Create user rman
SQL> create user rman identified by rman
2 default tablespace rman_tbs

131

ORACLE BACKUP STRATEGIES

3 quota unlimited on rman_tbs;
User created.
Grant permission for rman user
SQL> grant connect,resource,recovery_catalog_owner to rman;
Grant succeeded.
Set the tnsnames in default path(Server IP)
[oracle@REDDY ~]$ vi
/home/oracle/oracle/product/10.2.0/db_1/network/admin/tnsnames.ora
Using netmgr
Set The Listener in the default path
[oracle@REDDY ~]$ vi
/home/oracle/oracle/product/10.2.0/db_1/network/admin/listener.ora
Using netmgr
Set the tnsnames in default path(CLIENT IP)
[oracle@REDDY ~]$ vi
/home/oracle/oracle/product/10.2.0/db_1/network/admin/tnsnames.ora
Using netmgr
Connect to the target database
[oracle@REDDY ~]$ rman
Recovery Manager: Release 10.2.0.1.0 – Production on Wed Nov 19 14:11:32 2008

132

ORACLE BACKUP STRATEGIES

Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> connect target sys@REDDY (netservice name,tns name of the client)
target database Password:
connected to target database: TARUN (DBID=2429858623)
Connect to the catalog database
RMAN> connect catalog rman/rman@REDDY1;
connected to recovery catalog database
(Both the target database and catalog database must be connected at the same time)
Create the catalog
RMAN> create catalog;
recovery catalog created
Register the database
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
Configure the channel
RMAN>configure channel device type disk format ‘/home/oracle/rmanbackup_%
u’;
new RMAN configuration parameters:

133

ORACLE BACKUP STRATEGIES

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/rmanbackup_%u’;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
RMAN> report schema;
Report of database schema
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
—- ——– ——————– ——- ————————
1 500 SYSTEM YES /home/oracle/tarun/datafiles/system01.dbf
2 500 UNDOTBS1 YES /home/oracle/tarun/datafiles/undotbs1.dbf
3 500 SYSAUX NO /home/oracle/tarun/datafiles/sysaux01.dbf
List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name
—- ——– ——————– ———– ——————–
1 200 TEMP 200 /home/oracle/tarun/datafiles/temp01.dbf
RMAN> show all;
RMAN configuration parameters are:

134

ORACLE BACKUP STRATEGIES

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/rmanbackup_%u’;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ‘AES128′; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
‘/home/oracle/oracle/product/10.2.0/db_1/dbs/snapcf_tarun.f’; # default
RMAN> backup database;
Starting backup at 19-NOV-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
………………………………………………………………………………………………….

135

ORACLE BACKUP STRATEGIES

piece handle=/home/oracle/rmanbackup_06k03q6i tag=TAG20081119T161422 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 19-NOV-08
RMAN> backup current controlfile;
Starting backup at 19-NOV-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
channel ORA_DISK_1: starting piece 1 at 19-NOV-08
channel ORA_DISK_1: finished piece 1 at 19-NOV-08
piece handle=/home/oracle/rmanbackup_09k03r9f tag=TAG20081119T163455 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 19-NOV-08
RMAN> list backup;
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
——- ———- ———– ———— —————
92 7.24M DISK 00:00:01 19-NOV-08

136

ORACLE BACKUP STRATEGIES

BP Key: 96 Status: EXPIRED Compressed: NO Tag: TAG20081119T155202
Piece Name: /home/oracle/rmanbackup_01k03op3
List of Archived Logs in backup set 92
Thrd Seq Low SCN Low Time Next SCN Next Time
—- ——- ———- ——— ———- ———
1 42 170695 18-NOV-08 197833 19-NOV-08
1 43 197833 19-NOV-08 198964 19-NOV-08
——- —- — ———- ———– ———— —————
189 Full 6.55M DISK 00:00:01 19-NOV-08
BP Key: 192 Status: AVAILABLE Compressed: NO Tag: TAG20081119T163455
Piece Name: /home/oracle/rmanbackup_09k03r9f
Control File Included: Ckp SCN: 199989 Ckp time: 19-NOV-08
RMAN> crosscheck backup;
using channel ORA_DISK_1
crosschecked backup piece: found to be ‘EXPIRED’
backup piece handle=/home/oracle/rmanbackup_01k03op3 recid=1 stamp=671212324
crosschecked backup piece: found to be ‘EXPIRED’
backup piece handle=/home/oracle/rmanbackup_02k03op5 recid=2 stamp=671212325
crosschecked backup piece: found to be ‘EXPIRED’
backup piece handle=/home/oracle/rmanbackup_03k03ose recid=3 stamp=671212432

137

ORACLE BACKUP STRATEGIES

crosschecked backup piece: found to be ‘EXPIRED’
backup piece handle=/home/oracle/rmanbackup_04k03osi recid=4 stamp=671212435
crosschecked backup piece: found to be ‘EXPIRED’
backup piece handle=/home/oracle/rmanbackup_05k03q2v recid=5 stamp=671213663
crosschecked backup piece: found to be ‘EXPIRED’
backup piece handle=/home/oracle/rmanbackup_06k03q6i recid=6 stamp=671213779
crosschecked backup piece: found to be ‘AVAILABLE’
backup piece handle=/home/oracle/rmanbackup_07k03r5g recid=7 stamp=671214768
crosschecked backup piece: found to be ‘AVAILABLE’
backup piece handle=/home/oracle/rmanbackup_08k03r8q recid=8 stamp=671214875
crosschecked backup piece: found to be ‘AVAILABLE’
backup piece handle=/home/oracle/rmanbackup_09k03r9f recid=9 stamp=671214895
Crosschecked 9 objects
In target database if all the datafiles or any one datafile are lost or corrupted:
RMAN> shutdown immediate;
database dismounted
Oracle instance shut down
RMAN> startup mount;
connected to target database (not started)
Oracle instance started

138

ORACLE BACKUP STRATEGIES

database mounted
Total System Global Area 343932928 bytes
Fixed Size 1219328 bytes
Variable Size 289408256 bytes
Database Buffers 50331648 bytes
Redo Buffers 2973696 bytes
RMAN> restore database;
Starting restore at 19-NOV-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=37 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /home/oracle/tarun/datafiles/system01.dbf
restoring datafile 00002 to /home/oracle/tarun/datafiles/undotbs1.dbf
restoring datafile 00003 to /home/oracle/tarun/datafiles/sysaux01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/rmanbackup_07k03r5g
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/rmanbackup_07k03r5g tag=TAG20081119T163248
channel ORA_DISK_1: restore complete, elapsed time: 00:01:16
Finished restore at 19-NOV-08

139

ORACLE BACKUP STRATEGIES

RMAN> recover database;
Starting recover at 19-NOV-08
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 19-NOV-08
RMAN> alter database open;
database opened
If we want to delete the old backup:
RMAN> delete backup;
using channel ORA_DISK_1
List of Backup Pieces
BP Key BS Key Pc# Cp# Status Device Type Piece Name
——- ——- — — ———– ———– ———96 92 1 1 EXPIRED DISK /home/oracle/rmanbackup_01k03op3
97 93 1 1 EXPIRED DISK /home/oracle/rmanbackup_02k03op5
98 94 1 1 EXPIRED DISK /home/oracle/rmanbackup_03k03ose
99 95 1 1 EXPIRED DISK /home/oracle/rmanbackup_04k03osi
124 121 1 1 EXPIRED DISK /home/oracle/rmanbackup_05k03q2v
125 122 1 1 EXPIRED DISK /home/oracle/rmanbackup_06k03q6i

140

ORACLE BACKUP STRATEGIES

171 167 1 1 AVAILABLE DISK /home/oracle/rmanbackup_07k03r5g
172 168 1 1 AVAILABLE DISK /home/oracle/rmanbackup_08k03r8q
192 189 1 1 AVAILABLE DISK /home/oracle/rmanbackup_09k03r9f
Do you really want to delete the above objects (enter YES or NO)? yes
deleted backup piece
backup piece handle=/home/oracle/rmanbackup_01k03op3 recid=1 stamp=671212324
deleted backup piece
backup piece handle=/home/oracle/rmanbackup_02k03op5 recid=2 stamp=671212325
deleted backup piece
backup piece handle=/home/oracle/rmanbackup_03k03ose recid=3 stamp=671212432
deleted backup piece
backup piece handle=/home/oracle/rmanbackup_04k03osi recid=4 stamp=671212435
deleted backup piece
backup piece handle=/home/oracle/rmanbackup_05k03q2v recid=5 stamp=671213663
deleted backup piece
backup piece handle=/home/oracle/rmanbackup_06k03q6i recid=6 stamp=671213779
deleted backup piece
backup piece handle=/home/oracle/rmanbackup_07k03r5g recid=7 stamp=671214768
deleted backup piece
backup piece handle=/home/oracle/rmanbackup_08k03r8q recid=8 stamp=671214875

141

ORACLE BACKUP STRATEGIES

deleted backup piece
backup piece handle=/home/oracle/rmanbackup_09k03r9f recid=9 stamp=671214895
Deleted 9 objects
RECOVERING THE DROPED TABLE IN A SCHEMA:
[oracle@REDDY ~]$ rman
Recovery Manager: Release 10.2.0.1.0 – Production on Wed Nov 26 13:56:50 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> connect target sys@REDDY;
target database Password:
connected to target database: TARUN (DBID=2429858623)
RMAN> connect catalog rman/rman@REDDY1;
connected to recovery catalog database
RMAN> create catalog;
recovery catalog created
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN> report schema;
Report of database schema

142

ORACLE BACKUP STRATEGIES

List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
—- ——– ——————– ——- ————————
1 500 SYSTEM YES /home/oracle/tarun/datafiles/system01.dbf
2 500 UNDOTBS1 YES /home/oracle/tarun/datafiles/undotbs1.dbf
3 500 SYSAUX NO /home/oracle/tarun/datafiles/sysaux01.dbf
4 20 USERS NO /home/oracle/tarun/datafiles/users01.dbf
List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name
—- ——– ——————– ———– ——————–
1 200 TEMP 200 /home/oracle/tarun/datafiles/temp01.dbf
Where target database is present:
SQL> show user
USER is “SYS”
SQL> connect tarun/tarun
Connected.
SQL> select * from tab;
no rows selected

143

ORACLE BACKUP STRATEGIES

SQL> create table test (c1 number) tablespace users;
Table created.
SQL> begin
2 for i in 1..1000 loop
3 insert into test values(i);
4 end loop;
5 end;
6/
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.
RMAN> backup database;
Starting backup at 26-NOV-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/home/oracle/tarun/datafiles/system01.dbf
input datafile fno=00002 name=/home/oracle/tarun/datafiles/undotbs1.dbf
input datafile fno=00003 name=/home/oracle/tarun/datafiles/sysaux01.dbf
input datafile fno=00004 name=/home/oracle/tarun/datafiles/users01.dbf

144

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: starting piece 1 at 26-NOV-08
channel ORA_DISK_1: finished piece 1 at 26-NOV-08
piece handle=/home/oracle/rmanbackup_0rk0m1tf tag=TAG20081126T141823 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:55
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 26-NOV-08
channel ORA_DISK_1: finished piece 1 at 26-NOV-08
piece handle=/home/oracle/rmanbackup_0sk0m212 tag=TAG20081126T141823 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 26-NOV-08
SQL> set time on
14:21:54 SQL> drop table test;
Table dropped.
RMAN> shutdown immediate;
database closed
database dismounted
Oracle instance shut down

145

ORACLE BACKUP STRATEGIES

RMAN> startup mount;
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area 343932928 bytes
Fixed Size 1219328 bytes
Variable Size 289408256 bytes
Database Buffers 50331648 bytes
Redo Buffers 2973696 bytes
RMAN> run
2> {
3> set until time “to_date(’11/26/08 14:21:54′,’MM/DD/YY HH24:MI:SS’)”;
4> restore database;
5> recover database;}
executing command: SET until clause
Starting restore at 26-NOV-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=37 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set

146

ORACLE BACKUP STRATEGIES

restoring datafile 00001 to /home/oracle/tarun/datafiles/system01.dbf
restoring datafile 00002 to /home/oracle/tarun/datafiles/undotbs1.dbf
restoring datafile 00003 to /home/oracle/tarun/datafiles/sysaux01.dbf
restoring datafile 00004 to /home/oracle/tarun/datafiles/users01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/rmanbackup_0rk0m1tf
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/rmanbackup_0rk0m1tf tag=TAG20081126T141823
channel ORA_DISK_1: restore complete, elapsed time: 00:01:26
Finished restore at 26-NOV-08
Starting recover at 26-NOV-08
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:02
Finished recover at 26-NOV-08
RMAN> alter database open resetlogs;
database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
14:32:10 SQL> !

147

ORACLE BACKUP STRATEGIES

[oracle@REDDY ~]$ sqlplus tarun/tarun
SQL*Plus: Release 10.2.0.1.0 – Production on Wed Nov 26 14:32:33 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production
With the Partitioning, OLAP and Data Mining options
SQL> show user;
USER is “TARUN”
SQL> select count(*) from test;
COUNT(*)
———1000
RECOVERING THE DROPED USER:
[oracle@REDDY ~]$ rman
Recovery Manager: Release 10.2.0.1.0 – Production on Wed Nov 26 13:56:50 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> connect target sys@REDDY;
target database Password:
connected to target database: TARUN (DBID=2429858623)
RMAN> connect catalog rman/rman@REDDY1;

148

ORACLE BACKUP STRATEGIES

connected to recovery catalog database
RMAN> create catalog;
recovery catalog created
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN> report schema;
Report of database schema
List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
—- ——– ——————– ——- ————————
1 500 SYSTEM YES /home/oracle/tarun/datafiles/system01.dbf
2 500 UNDOTBS1 YES /home/oracle/tarun/datafiles/undotbs1.dbf
3 500 SYSAUX NO /home/oracle/tarun/datafiles/sysaux01.dbf
4 20 USERS NO /home/oracle/tarun/datafiles/users01.dbf
List of Temporary Files
=======================
File Size(MB) Tablespace Maxsize(MB) Tempfile Name

149

ORACLE BACKUP STRATEGIES

—- ——– ——————– ———– ——————–
1 200 TEMP 200 /home/oracle/tarun/datafiles/temp01.dbf
RMAN> backup database;
Starting backup at 26-NOV-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/home/oracle/tarun/datafiles/system01.dbf
input datafile fno=00002 name=/home/oracle/tarun/datafiles/undotbs1.dbf
input datafile fno=00003 name=/home/oracle/tarun/datafiles/sysaux01.dbf
input datafile fno=00004 name=/home/oracle/tarun/datafiles/users01.dbf
channel ORA_DISK_1: starting piece 1 at 26-NOV-08
channel ORA_DISK_1: finished piece 1 at 26-NOV-08
piece handle=/home/oracle/rmanbackup_0tk0m4s0 tag=TAG20081126T150847 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:05
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 26-NOV-08

150

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: finished piece 1 at 26-NOV-08
piece handle=/home/oracle/rmanbackup_0uk0m4vt tag=TAG20081126T150847 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 26-NOV-08
RMAN> list backup;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
——- —- — ———- ———– ———— —————
889 Full 236.30M DISK 00:01:56 26-NOV-08
BP Key: 891 Status: AVAILABLE Compressed: NO Tag: TAG20081126T150847
Piece Name: /home/oracle/rmanbackup_0tk0m4s0
List of Datafiles in backup set 889
File LV Type Ckp SCN Ckp Time Name
—- — —- ———- ——— —1 Full 343455 26-NOV-08 /home/oracle/tarun/datafiles/system01.dbf
2 Full 343455 26-NOV-08 /home/oracle/tarun/datafiles/undotbs1.dbf
3 Full 343455 26-NOV-08 /home/oracle/tarun/datafiles/sysaux01.dbf
4 Full 343455 26-NOV-08 /home/oracle/tarun/datafiles/users01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time

151

ORACLE BACKUP STRATEGIES

——- —- — ———- ———– ———— —————
890 Full 6.67M DISK 00:00:02 26-NOV-08
BP Key: 892 Status: AVAILABLE Compressed: NO Tag: TAG20081126T150847
Piece Name: /home/oracle/rmanbackup_0uk0m4vt
Control File Included: Ckp SCN: 343497 Ckp time: 26-NOV-08
SPFILE Included: Modification time: 08-NOV-08
Where target database is present:
SQL> show user
USER is “SYS”
SQL> select username from dba_users;
USERNAME
——————————
OUTLN
SYS
SYSTEM
TARUN
TSMSYS
DIP
DBSNMP
7 rows selected.

152

ORACLE BACKUP STRATEGIES

SQL> set time on
15:14:02 SQL> drop user tarun cascade;
User dropped.
RMAN> shutdown immediate;
database closed
database dismounted
Oracle instance shut down
RMAN> startup mount;
connected to target database (not started)
Oracle instance started
database mounted
Total System Global Area 343932928 bytes
Fixed Size 1219328 bytes
Variable Size 289408256 bytes
Database Buffers 50331648 bytes
Redo Buffers 2973696 bytes
RMAN> run
2> {
3> set until time “to_date(’11/26/08 15:14:02′,’MM/DD/YY HH24:MI:SS’)”;
4> restore database;

153

ORACLE BACKUP STRATEGIES

5> recover database;}
executing command: SET until clause
Starting restore at 26-NOV-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=37 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /home/oracle/tarun/datafiles/system01.dbf
restoring datafile 00002 to /home/oracle/tarun/datafiles/undotbs1.dbf
restoring datafile 00003 to /home/oracle/tarun/datafiles/sysaux01.dbf
restoring datafile 00004 to /home/oracle/tarun/datafiles/users01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/rmanbackup_0tk0m4s0
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/rmanbackup_0tk0m4s0 tag=TAG20081126T150847
channel ORA_DISK_1: restore complete, elapsed time: 00:01:25
Finished restore at 26-NOV-08
Starting recover at 26-NOV-08
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:03

154

ORACLE BACKUP STRATEGIES

Finished recover at 26-NOV-08
RMAN> alter database open resetlogs;
database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
15:14:28 SQL> !
[oracle@REDDY ~]$ sqlplus sys as sysdba
SQL*Plus: Release 10.2.0.1.0 – Production on Wed Nov 26 15:24:20 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Enter password:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production
With the Partitioning, OLAP and Data Mining options
SQL> select username from dba_users;
USERNAME
——————————
OUTLN
SYS
SYSTEM

155

ORACLE BACKUP STRATEGIES

TARUN
TSMSYS
DIP
DBSNMP
7 rows selected.
RECOVERING TABLESPACE IF ONE OF THE DATAFILE IS LOST OR CORRUPTD:
[oracle@REDDY ~]$ rman
Recovery Manager: Release 10.2.0.1.0 – Production on Sat Nov 29 15:18:50 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> connect target sys@REDDY;
target database Password:
connected to target database: TARUN (DBID=2431589971)
RMAN> connect catalog rman/rman@REDDY1;
connected to recovery catalog database
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN> resync catalog;
starting full resync of recovery catalog

156

ORACLE BACKUP STRATEGIES

full resync complete
Where target database is present:
SQL> create tablespace test datafile ‘/home/oracle/tarun/datafiles/test01.dbf’ size
50m,’/home/oracle/tarun/datafiles/test02.dbf’ size 50m;
Tablespace created.
SQL> select tablespace_name,file_name from dba_data_files;
TABLESPACE_NAME
——————————
FILE_NAME
——————————————————————————–
SYSTEM
/home/oracle/tarun/datafiles/system01.dbf
UNDOTBS1
/home/oracle/tarun/datafiles/undotbs1.dbf
SYSAUX
/home/oracle/tarun/datafiles/sysaux01.dbf
TABLESPACE_NAME
——————————
FILE_NAME
——————————————————————————–
TEST

157

ORACLE BACKUP STRATEGIES

/home/oracle/tarun/datafiles/test01.dbf
TEST
/home/oracle/tarun/datafiles/test02.dbf
RMAN> backup database plus archivelog;
Starting backup at 29-NOV-08
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=44 recid=3 stamp=672076709
channel ORA_DISK_1: starting piece 1 at 29-NOV-08
channel ORA_DISK_1: finished piece 1 at 29-NOV-08
piece handle=/home/oracle/oracle/product/10.2.0/db_1/dbs/07k0u4t6_1_1
tag=TAG20081129T155830 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 29-NOV-08
Starting backup at 29-NOV-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/home/oracle/tarun/datafiles/system01.dbf

158

ORACLE BACKUP STRATEGIES

input datafile fno=00002 name=/home/oracle/tarun/datafiles/undotbs1.dbf
input datafile fno=00003 name=/home/oracle/tarun/datafiles/sysaux01.dbf
input datafile fno=00004 name=/home/oracle/tarun/datafiles/test01.dbf
input datafile fno=00005 name=/home/oracle/tarun/datafiles/test02.dbf
channel ORA_DISK_1: starting piece 1 at 29-NOV-08
channel ORA_DISK_1: finished piece 1 at 29-NOV-08
piece handle=/home/oracle/oracle/product/10.2.0/db_1/dbs/08k0u4t8_1_1
tag=TAG20081129T155832 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:05
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 29-NOV-08
channel ORA_DISK_1: finished piece 1 at 29-NOV-08
piece handle=/home/oracle/oracle/product/10.2.0/db_1/dbs/09k0u516_1_1
tag=TAG20081129T155832 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 29-NOV-08
Starting backup at 29-NOV-08
current log archived

159

ORACLE BACKUP STRATEGIES

using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=45 recid=4 stamp=672076840
channel ORA_DISK_1: starting piece 1 at 29-NOV-08
channel ORA_DISK_1: finished piece 1 at 29-NOV-08
piece handle=/home/oracle/oracle/product/10.2.0/db_1/dbs/0ak0u51a_1_1
tag=TAG20081129T160041 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 29-NOV-08
SQL> !
[oracle@REDDY ~]$ cd tarun/
[oracle@REDDY tarun]$ cd datafiles/
[oracle@REDDY datafiles]$ ls
redo01.log sysaux01.dbf temp01.dbf test02.dbf
redo02.log system01.dbf test01.dbf undotbs1.dbf
[oracle@REDDY datafiles]$ rm -rf test02.dbf
[oracle@REDDY datafiles]$ ls
redo01.log redo02.log sysaux01.dbf system01.dbf temp01.dbf test01.dbf undotbs1.dbf
RMAN> sql “alter tablespace test offline”;
sql statement: alter tablespace test offline

160

ORACLE BACKUP STRATEGIES

starting full resync of recovery catalog
full resync complete
RMAN> restore tablespace ‘TEST’;
Starting restore at 29-NOV-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00004 to /home/oracle/tarun/datafiles/test01.dbf
restoring datafile 00005 to /home/oracle/tarun/datafiles/test02.dbf
channel ORA_DISK_1: reading from backup piece
/home/oracle/oracle/product/10.2.0/db_1/dbs/08k0u4t8_1_1
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/oracle/product/10.2.0/db_1/dbs/08k0u4t8_1_1
tag=TAG20081129T155832
channel ORA_DISK_1: restore complete, elapsed time: 00:00:16
Finished restore at 29-NOV-08
RMAN> recover tablespace ‘TEST’;
Starting recover at 29-NOV-08
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:00

161

ORACLE BACKUP STRATEGIES

Finished recover at 29-NOV-08
RMAN> sql “alter tablespace test online”;
sql statement: alter tablespace test online
starting full resync of recovery catalog
full resync complete
SQL> select file_name,tablespace_name from dba_data_files;
FILE_NAME
——————————————————————————–
TABLESPACE_NAME
——————————
/home/oracle/tarun/datafiles/system01.dbf
SYSTEM
/home/oracle/tarun/datafiles/undotbs1.dbf
UNDOTBS1
/home/oracle/tarun/datafiles/sysaux01.dbf
SYSAUX
FILE_NAME
——————————————————————————–
TABLESPACE_NAME
——————————

162

ORACLE BACKUP STRATEGIES

/home/oracle/tarun/datafiles/test01.dbf
TEST
/home/oracle/tarun/datafiles/test02.dbf
TEST
SQL> !
[oracle@REDDY ~]$ cd tarun/
[oracle@REDDY tarun]$ ls
archive bdump control datafiles dbc.sql udump
[oracle@REDDY tarun]$ cd datafiles/
[oracle@REDDY datafiles]$ ls
redo01.log sysaux01.dbf temp01.dbf test02.dbf
redo02.log system01.dbf test01.dbf undotbs1.dbf
RECOVERING THE LOST OR CORRUPTD DATAFILE AND RESTORE THE BACKUP DATAFILE TO
THE NEW LOCATION:
[oracle@REDDY ~]$ rman
Recovery Manager: Release 10.2.0.1.0 – Production on Tue Dec 2 13:58:19 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> connect target sys@REDDY;
target database Password:
connected to target database: TARUN (DBID=2431589971)
RMAN> connect catalog rman/rman@REDDY1;
connected to recovery catalog database
RMAN> create catalog;
recovery catalog created
RMAN> register database;
database registered in recovery catalog

163

ORACLE BACKUP STRATEGIES

starting full resync of recovery catalog
full resync complete
RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/rmanbackup_%u’;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ‘AES128′; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
‘/home/oracle/oracle/product/10.2.0/db_1/dbs/snapcf_tarun.f’; # default
Where target database is present:
SQL> create tablespace test datafile ‘/home/oracle/test01.dbf’ size 20m;
Tablespace created.
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
——————————
SYSTEM
UNDOTBS1
SYSAUX
TEMP
TEST
SQL> select name from v$datafile;
NAME
——————————————————————————–
/home/oracle/tarun/datafiles/system01.dbf
/home/oracle/tarun/datafiles/undotbs1.dbf

164

ORACLE BACKUP STRATEGIES

/home/oracle/tarun/datafiles/sysaux01.dbf
/home/oracle/test01.dbf
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /home/oracle/tarun/archive
Oldest online log sequence 14
Next log sequence to archive 15
Current log sequence 15
RMAN> list backup;
RMAN> backup database plus archivelog;
starting full resync of recovery catalog
full resync complete
Starting backup at 02-DEC-08
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=1 recid=25 stamp=672158787
input archive log thread=1 sequence=2 recid=26 stamp=672408184
……………………………………………………………………………………………………………………..
piece handle=/home/oracle/rmanbackup_0nk18ggt tag=TAG20081202T141758 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 02-DEC-08
Starting backup at 02-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/home/oracle/tarun/datafiles/system01.dbf
input datafile fno=00002 name=/home/oracle/tarun/datafiles/undotbs1.dbf
input datafile fno=00003 name=/home/oracle/tarun/datafiles/sysaux01.dbf
input datafile fno=00004 name=/home/oracle/test01.dbf
channel ORA_DISK_1: starting piece 1 at 02-DEC-08
channel ORA_DISK_1: finished piece 1 at 02-DEC-08
piece handle=/home/oracle/rmanbackup_0ok18ggv tag=TAG20081202T141807 comment=NONE

165

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: backup set complete, elapsed time: 00:01:45
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 02-DEC-08
channel ORA_DISK_1: finished piece 1 at 02-DEC-08
piece handle=/home/oracle/rmanbackup_0pk18gk8 tag=TAG20081202T141807 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 02-DEC-08
Starting backup at 02-DEC-08
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=16 recid=40 stamp=672416395
channel ORA_DISK_1: starting piece 1 at 02-DEC-08
channel ORA_DISK_1: finished piece 1 at 02-DEC-08
piece handle=/home/oracle/rmanbackup_0qk18gkd tag=TAG20081202T141956 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 02-DEC-08
SQL> !
[oracle@REDDY ~]$ ls
Desktop oracle rmanbackup_0mk18ggr rmanbackup_0pk18gk8 tarun
rmanbackup_0nk18ggt rmanbackup_0qk18gkd rmanbackup_0lk18ggm rmanbackup_0ok18ggv
test01.dbf
[oracle@REDDY ~]$ rm -rf test01.dbf
RMAN> shutdown immediate;
database closed
database dismounted
Oracle instance shut down
RMAN> startup mount;
connected to target database (not started)
Oracle instance started
database mounted

166

ORACLE BACKUP STRATEGIES

Total System Global Area 343932928 bytes
Fixed Size 1219328 bytes
Variable Size 289408256 bytes
Database Buffers 50331648 bytes
Redo Buffers 2973696 bytes
RMAN> run{
2> set newname for datafile’/home/oracle/test01.dbf’ to
‘/home/oracle/tarun/datafiles/test01.dbf’;
3> restore tablespace ‘TEST’;
4> switch datafile all;
5> recover tablespace ‘TEST’;
6> }
executing command: SET NEWNAME
Starting restore at 02-DEC-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=37 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00004 to /home/oracle/tarun/datafiles/test01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/rmanbackup_0ok18ggv
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/rmanbackup_0ok18ggv tag=TAG20081202T141807
channel ORA_DISK_1: restore complete, elapsed time: 00:00:04
Finished restore at 02-DEC-08
datafile 4 switched to datafile copy
input datafile copy recid=12 stamp=672417414 filename=/home/oracle/tarun/datafiles/test01.dbf
starting full resync of recovery catalog
full resync complete
Starting recover at 02-DEC-08
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 02-DEC-08
RMAN> alter database open;
database opened

167

ORACLE BACKUP STRATEGIES

[oracle@REDDY ~]$ cd tarun/datafiles/
[oracle@REDDY datafiles]$ ls
redo01.log redo02.log sysaux01.dbf system01.dbf temp01.dbf test01.dbf undotbs1.dbf
[oracle@REDDY datafiles]$ cd
[oracle@REDDY ~]$ sqlplus sys as sysdba
SQL*Plus: Release 10.2.0.1.0 – Production on Tue Dec 2 14:39:49 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Enter password:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production
With the Partitioning, OLAP and Data Mining options
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
——————————
SYSTEM
UNDOTBS1
SYSAUX
TEMP
TEST
SQL> select name from v$datafile;
NAME
——————————————————————————–
/home/oracle/tarun/datafiles/system01.dbf
/home/oracle/tarun/datafiles/undotbs1.dbf
/home/oracle/tarun/datafiles/sysaux01.dbf
/home/oracle/tarun/datafiles/test01.dbf
WHEN THE DATABASE OPEN TO RESTORE THE BACKUP DATAFILE TO THE NEW LOCATION:
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
——————————
SYSTEM
UNDOTBS1
SYSAUX
TEMP
TEST

168

ORACLE BACKUP STRATEGIES

SQL> select name from v$datafile;
NAME
——————————————————————————–
/home/oracle/tarun/datafiles/system01.dbf
/home/oracle/tarun/datafiles/undotbs1.dbf
/home/oracle/tarun/datafiles/sysaux01.dbf
/home/oracle/tarun/datafiles/test01.dbf
RMAN> run{
2> sql’ALTER TABLESPACE TEST OFFLINE IMMEDIATE’;
3> set newname for datafile’/home/oracle/tarun/datafiles/test01.dbf’ to
‘/home/oracle/tarun/test01.dbf’;
4> restore tablespace ‘TEST’;
5> recover tablespace ‘TEST’;
6> switch datafile all;
7> recover tablespace ‘TEST’;
8> sql ‘ALTER TABLESPACE TEST ONLINE’;
9> }
sql statement: ALTER TABLESPACE TEST OFFLINE IMMEDIATE
executing command: SET NEWNAME
Starting restore at 02-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00004 to /home/oracle/tarun/test01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/rmanbackup_0ok18ggv
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/rmanbackup_0ok18ggv tag=TAG20081202T141807
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
Finished restore at 02-DEC-08
Starting recover at 02-DEC-08
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:00
Finished recover at 02-DEC-08
datafile 4 switched to datafile copy

169

ORACLE BACKUP STRATEGIES

input datafile copy recid=14 stamp=672420263 filename=/home/oracle/tarun/test01.dbf
starting full resync of recovery catalog
full resync complete
Starting recover at 02-DEC-08
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 02-DEC-08
sql statement: ALTER TABLESPACE TEST ONLINE
SQL> select tablespace_name,status from dba_tablespaces;
TABLESPACE_NAME STATUS
—————————— ———
SYSTEM ONLINE
UNDOTBS1 ONLINE
SYSAUX ONLINE
TEMP ONLINE
TEST ONLINE
SQL> select name from v$datafile;
NAME
——————————————————————————–
/home/oracle/tarun/datafiles/system01.dbf
/home/oracle/tarun/datafiles/undotbs1.dbf
/home/oracle/tarun/datafiles/sysaux01.dbf
/home/oracle/tarun/test01.dbf
RECOVERING THE DROPED TABLESPACE:
[oracle@REDDY ~]$ rman
Recovery Manager: Release 10.2.0.1.0 – Production on Fri Dec 5 11:08:28 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> connect target sys@REDDY;
target database Password:
connected to target database: TARUN (DBID=2432194154)
RMAN> connect catalog rman/rman@REDDY1;
connected to recovery catalog database
RMAN> register database;
database registered in recovery catalog

170

ORACLE BACKUP STRATEGIES

starting full resync of recovery catalog
full resync complete
RMAN> resync catalog;
starting full resync of recovery catalog
full resync complete
RMAN> configure channel device type disk format’/home/oracle/rman_%u’;
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/rman_%u’;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/rman_%u’;
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM ‘AES128′; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
‘/home/oracle/oracle/product/10.2.0/db_1/dbs/snapcf_tarun.f’; # default
Where target database is present:
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
——————————
SYSTEM
UNDOTBS1
SYSAUX

171

ORACLE BACKUP STRATEGIES

TEMP
SQL> create tablespace users datafile’/home/oracle/tarun/datafiles/users01.dbf’ size 20m;
Tablespace created.
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
——————————
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /home/oracle/tarun/archive
Oldest online log sequence 45
Next log sequence to archive 46
Current log sequence 46
RMAN> run
2> {
3> backup database plus archivelog;
4> backup current controlfile;
5> }

172

ORACLE BACKUP STRATEGIES

Starting backup at 05-DEC-08
current log archived
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=22 devtype=DISK
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=41 recid=1 stamp=672664479
input archive log thread=1 sequence=42 recid=2 stamp=672664484
input archive log thread=1 sequence=43 recid=3 stamp=672664485
input archive log thread=1 sequence=44 recid=4 stamp=672664488
input archive log thread=1 sequence=45 recid=5 stamp=672664495
input archive log thread=1 sequence=46 recid=6 stamp=672665081
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_01k1g3fr tag=TAG20081205T112443 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 05-DEC-08
Starting backup at 05-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/home/oracle/tarun/datafiles/system01.dbf
input datafile fno=00002 name=/home/oracle/tarun/datafiles/undotbs1.dbf
input datafile fno=00003 name=/home/oracle/tarun/datafiles/sysaux01.dbf
input datafile fno=00004 name=/home/oracle/tarun/datafiles/users01.dbf
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_02k1g3fu tag=TAG20081205T112446 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:45
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08

173

ORACLE BACKUP STRATEGIES

piece handle=/home/oracle/rman_03k1g3j7 tag=TAG20081205T112446 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 05-DEC-08
Starting backup at 05-DEC-08
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=47 recid=7 stamp=672665194
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_04k1g3jb tag=TAG20081205T112635 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 05-DEC-08
Starting backup at 05-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_05k1g3je tag=TAG20081205T112638 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 05-DEC-08
RMAN> list backup;
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
——- ———- ———– ———— —————
1971 7.28M DISK 00:00:02 05-DEC-08
BP Key: 1974 Status: AVAILABLE Compressed: NO Tag: TAG20081205T112443
Piece Name: /home/oracle/rman_01k1g3fr
List of Archived Logs in backup set 1971
Thrd Seq Low SCN Low Time Next SCN Next Time
—- ——- ———- ——— ———- ———

174

ORACLE BACKUP STRATEGIES

1 41 149755 04-DEC-08 152107 05-DEC-08
1 42 152107 05-DEC-08 152110 05-DEC-08
1 43 152110 05-DEC-08 152112 05-DEC-08
1 44 152112 05-DEC-08 152114 05-DEC-08
1 45 152114 05-DEC-08 152117 05-DEC-08
1 46 152117 05-DEC-08 152446 05-DEC-08
BS Key Type LV Size Device Type Elapsed Time Completion Time
——- —- — ———- ———– ———— —————
1972 Full 231.53M DISK 00:01:44 05-DEC-08
BP Key: 1975 Status: AVAILABLE Compressed: NO Tag: TAG20081205T112446
Piece Name: /home/oracle/rman_02k1g3fu
List of Datafiles in backup set 1972
File LV Type Ckp SCN Ckp Time Name
—- — —- ———- ——— —1 Full 152459 05-DEC-08 /home/oracle/tarun/datafiles/system01.dbf
2 Full 152459 05-DEC-08 /home/oracle/tarun/datafiles/undotbs1.dbf
3 Full 152459 05-DEC-08 /home/oracle/tarun/datafiles/sysaux01.dbf
4 Full 152459 05-DEC-08 /home/oracle/tarun/datafiles/users01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
——- —- — ———- ———– ———— —————
1973 Full 6.58M DISK 00:00:02 05-DEC-08
BP Key: 1976 Status: AVAILABLE Compressed: NO Tag: TAG20081205T112446
Piece Name: /home/oracle/rman_03k1g3j7
Control File Included: Ckp SCN: 152494 Ckp time: 05-DEC-08
SPFILE Included: Modification time: 04-DEC-08
BS Key Size Device Type Elapsed Time Completion Time
——- ———- ———– ———— —————
1994 25.00K DISK 00:00:01 05-DEC-08
BP Key: 1997 Status: AVAILABLE Compressed: NO Tag: TAG20081205T112635
Piece Name: /home/oracle/rman_04k1g3jb
List of Archived Logs in backup set 1994
Thrd Seq Low SCN Low Time Next SCN Next Time
—- ——- ———- ——— ———- ———
1 47 152446 05-DEC-08 152498 05-DEC-08
BS Key Type LV Size Device Type Elapsed Time Completion Time

175

ORACLE BACKUP STRATEGIES

——- —- — ———- ———– ———— —————
2005 Full 6.55M DISK 00:00:01 05-DEC-08
BP Key: 2007 Status: AVAILABLE Compressed: NO Tag: TAG20081205T112638
Piece Name: /home/oracle/rman_05k1g3je
Control File Included: Ckp SCN: 152519 Ckp time: 05-DEC-08
SQL> set time on;
11:27:38 SQL> drop tablespace users including contents and datafiles;
Tablespace dropped.
RMAN> shutdown immediate;
starting full resync of recovery catalog
full resync complete
database closed
database dismounted
Oracle instance shut down
RMAN> startup nomount;
connected to target database (not started)
Oracle instance started
Total System Global Area 343932928 bytes
Fixed Size 1219328 bytes
Variable Size 289408256 bytes
Database Buffers 50331648 bytes
Redo Buffers 2973696 bytes
RMAN> restore controlfile;
Starting restore at 05-DEC-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: reading from backup piece /home/oracle/rman_05k1g3je
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/rman_05k1g3je tag=TAG20081205T112638
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output filename=/home/oracle/tarun/control/c1.ctl
Finished restore at 05-DEC-08
RMAN> alter database mount;

176

ORACLE BACKUP STRATEGIES

database mounted
released channel: ORA_DISK_1
RMAN> run{
2> set until time “to_date(’12/05/08 11:27:38′,’MM/DD/YY HH24:MI:SS’)”;
3> restore database;
4> recover database;
5> }
executing command: SET until clause
Starting restore at 05-DEC-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /home/oracle/tarun/datafiles/system01.dbf
restoring datafile 00002 to /home/oracle/tarun/datafiles/undotbs1.dbf
restoring datafile 00003 to /home/oracle/tarun/datafiles/sysaux01.dbf
restoring datafile 00004 to /home/oracle/tarun/datafiles/users01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/rman_02k1g3fu
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/rman_02k1g3fu tag=TAG20081205T112446
channel ORA_DISK_1: restore complete, elapsed time: 00:01:16
Finished restore at 05-DEC-08
Starting recover at 05-DEC-08
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 47 is already on disk as file /home/oracle/tarun/datafiles/redo01.log
archive log thread 1 sequence 48 is already on disk as file /home/oracle/tarun/datafiles/redo02.log
archive log filename=/home/oracle/tarun/datafiles/redo01.log thread=1 sequence=47
archive log filename=/home/oracle/tarun/datafiles/redo02.log thread=1 sequence=48
media recovery complete, elapsed time: 00:00:01
Finished recover at 05-DEC-08
RMAN> alter database open resetlogs;
database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog

177

ORACLE BACKUP STRATEGIES

full resync complete
[oracle@REDDY ~]$ sqlplus sys as sysdba
SQL*Plus: Release 10.2.0.1.0 – Production on Fri Dec 5 11:35:31 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Enter password:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production
With the Partitioning, OLAP and Data Mining options
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
——————————
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
NOTE:
1. I am using Controlfile Instead of Recovery catalog for RMAN repository
2. Don’t use AUTOBACKUP controlfile option becuase we need backup controlfile for incomplete
recovery not current controlfile.
RECOVERING THE DROPED REDOLOG GROUP AND REDO LOGFILES:
[oracle@REDDY ~]$ rman
Recovery Manager: Release 10.2.0.1.0 – Production on Fri Dec 5 11:08:28 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> connect target sys@REDDY;
target database Password:
connected to target database: TARUN (DBID=2432194154)
RMAN> connect catalog rman/rman@REDDY1;
connected to recovery catalog database
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN> resync catalog;
starting full resync of recovery catalog

178

ORACLE BACKUP STRATEGIES

full resync complete
RMAN> configure channel device type disk format’/home/oracle/rman_%u’;
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/rman_%u’;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
Where target database is present:
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /home/oracle/tarun/archive
Oldest online log sequence 1
Next log sequence to archive 1
Current log sequence 1
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
———- ———- ———- ———- ———- — —————FIRST_CHANGE# FIRST_TIM
————- ———
1 1 1 10485760 1 NO CURRENT
153671 05-DEC-08
2 1 0 10485760 1 YES UNUSED
0
SQL> alter database add logfile group 3′/home/oracle/tarun/datafiles/redo03.log’ size 20m;
Database altered.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> /

179

ORACLE BACKUP STRATEGIES

System altered.
SQL> /
System altered.
RMAN> run
2> {
3> backup database plus archivelog;
4> backup current controlfile;
5> }
Starting backup at 05-DEC-08
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=41 recid=1 stamp=672664479
input archive log thread=1 sequence=42 recid=2 stamp=672664484
input archive log thread=1 sequence=43 recid=3 stamp=672664485
input archive log thread=1 sequence=44 recid=4 stamp=672664488
input archive log thread=1 sequence=45 recid=5 stamp=672664495
input archive log thread=1 sequence=46 recid=6 stamp=672665081
input archive log thread=1 sequence=47 recid=10 stamp=672665697
input archive log thread=1 sequence=48 recid=11 stamp=672665697
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_0ek1g6r3 tag=TAG20081205T122154 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=1 recid=12 stamp=672667321
input archive log thread=1 sequence=2 recid=13 stamp=672667326
input archive log thread=1 sequence=3 recid=14 stamp=672667332
input archive log thread=1 sequence=4 recid=15 stamp=672667334
input archive log thread=1 sequence=5 recid=16 stamp=672667340
input archive log thread=1 sequence=6 recid=17 stamp=672667439
input archive log thread=1 sequence=7 recid=22 stamp=672668106
input archive log thread=1 sequence=8 recid=21 stamp=672668106

180

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_0fk1g6r5 tag=TAG20081205T122154 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=1 recid=23 stamp=672668348
input archive log thread=1 sequence=2 recid=24 stamp=672668349
input archive log thread=1 sequence=3 recid=25 stamp=672668355
input archive log thread=1 sequence=4 recid=26 stamp=672668356
input archive log thread=1 sequence=5 recid=27 stamp=672668357
input archive log thread=1 sequence=6 recid=28 stamp=672668513
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_0gk1g6r7 tag=TAG20081205T122154 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 05-DEC-08
Starting backup at 05-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/home/oracle/tarun/datafiles/system01.dbf
input datafile fno=00002 name=/home/oracle/tarun/datafiles/undotbs1.dbf
input datafile fno=00003 name=/home/oracle/tarun/datafiles/sysaux01.dbf
input datafile fno=00004 name=/home/oracle/tarun/datafiles/users01.dbf
input datafile fno=00005 name=/home/oracle/tarun/datafiles/test01.dbf
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_0hk1g6r9 tag=TAG20081205T122201 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:05
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 05-DEC-08

181

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_0ik1g6v6 tag=TAG20081205T122201 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 05-DEC-08
Starting backup at 05-DEC-08
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=7 recid=29 stamp=672668649
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_0jk1g6vb tag=TAG20081205T122411 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 05-DEC-08
Starting backup at 05-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_0kk1g6ve tag=TAG20081205T122414 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 05-DEC-08
SQL> set time on;
12:24:37 SQL> alter database drop logfile group 1;
Database altered.
12:25:26 SQL> !
[oracle@REDDY ~]$ cd tarun/datafiles/
[oracle@REDDY datafiles]$ ls
redo01.log redo03.log system01.dbf test01.dbf users01.dbf
redo02.log sysaux01.dbf temp01.dbf undotbs1.dbf
[oracle@REDDY datafiles]$ rm -rf redo01.log
[oracle@REDDY datafiles]$ cd

182

ORACLE BACKUP STRATEGIES

RMAN> shutdown immediate;
starting full resync of recovery catalog
full resync complete
database closed
database dismounted
Oracle instance shut down
RMAN> startup nomount;
connected to target database (not started)
Oracle instance started
Total System Global Area 343932928 bytes
Fixed Size 1219328 bytes
Variable Size 289408256 bytes
Database Buffers 50331648 bytes
Redo Buffers 2973696 bytes
RMAN> restore controlfile;
Starting restore at 05-DEC-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: reading from backup piece /home/oracle/rman_0kk1g6ve
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/rman_0kk1g6ve tag=TAG20081205T122414
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output filename=/home/oracle/tarun/control/c1.ctl
Finished restore at 05-DEC-08
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN> run {
2> set until time “to_date(’12/05/08 12:24:37′,’MM/DD/YY HH24:MI:SS’)”;
3> restore database;
4> recover database;
5> }
executing command: SET until clause

183

ORACLE BACKUP STRATEGIES

Starting restore at 05-DEC-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /home/oracle/tarun/datafiles/system01.dbf
restoring datafile 00002 to /home/oracle/tarun/datafiles/undotbs1.dbf
restoring datafile 00003 to /home/oracle/tarun/datafiles/sysaux01.dbf
restoring datafile 00004 to /home/oracle/tarun/datafiles/users01.dbf
restoring datafile 00005 to /home/oracle/tarun/datafiles/test01.dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/rman_0hk1g6r9
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/rman_0hk1g6r9 tag=TAG20081205T122201
channel ORA_DISK_1: restore complete, elapsed time: 00:01:25
Finished restore at 05-DEC-08
Starting recover at 05-DEC-08
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 7 is already on disk as file
/home/oracle/tarun/archive/arch_1_672668106_7.arc
archive log thread 1 sequence 8 is already on disk as file /home/oracle/tarun/datafiles/redo02.log
archive log filename=/home/oracle/tarun/archive/arch_1_672668106_7.arc thread=1 sequence=7
archive log filename=/home/oracle/tarun/datafiles/redo02.log thread=1 sequence=8
media recovery complete, elapsed time: 00:00:02
Finished recover at 05-DEC-08
RMAN> alter database open resetlogs;
database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
[oracle@REDDY ~]$ sqlplus sys as sysdba
SQL*Plus: Release 10.2.0.1.0 – Production on Fri Dec 5 12:32:52 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Enter password:
Connected to:

184

ORACLE BACKUP STRATEGIES

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production
With the Partitioning, OLAP and Data Mining options
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
———- ———- ———- ———- ———- — —————FIRST_CHANGE# FIRST_TIM
————- ———
1 1 0 10485760 1 YES UNUSED
0
2 1 1 10485760 1 NO CURRENT
154073 05-DEC-08
3 1 0 20971520 1 YES UNUSED
0
SQL> !
[oracle@REDDY ~]$ cd tarun/datafiles/
[oracle@REDDY datafiles]$ ls
redo01.log redo03.log system01.dbf test01.dbf users01.dbf
redo02.log sysaux01.dbf temp01.dbf undotbs1.dbf

RECOVERING THE DROPED CONTROLFILE:
[oracle@REDDY ~]$ rman
Recovery Manager: Release 10.2.0.1.0 – Production on Fri Dec 5 14:22:44 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> connect target sys@REDDY;
target database Password:
connected to target database: TARUN (DBID=2432194154)
RMAN> connect catalog rman@REDDY1;
recovery catalog database Password:

185

ORACLE BACKUP STRATEGIES

connected to recovery catalog database
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
RMAN> run
2> {
3> backup database plus archivelog;
4> backup current controlfile;
5> }
Starting backup at 05-DEC-08
current log archived
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=22 devtype=DISK
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=1 recid=15 stamp=672676311
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_09k1geep tag=TAG20081205T143152 comment=NONE

186

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=48 recid=14 stamp=672672893
input archive log thread=1 sequence=49 recid=13 stamp=672672893
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_0ak1geer tag=TAG20081205T143152 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 05-DEC-08
Starting backup at 05-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/home/oracle/tarun/datafiles/system01.dbf
input datafile fno=00002 name=/home/oracle/tarun/datafiles/undotbs1.dbf
input datafile fno=00003 name=/home/oracle/tarun/datafiles/sysaux01.dbf
input datafile fno=00004 name=/home/oracle/tarun/datafiles/users01.dbf
input datafile fno=00005 name=/home/oracle/tarun/datafiles/test1.dbf
channel ORA_DISK_1: starting piece 1 at 05-DEC-08

187

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_0bk1geet tag=TAG20081205T143157 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:05
Finished backup at 05-DEC-08
Starting backup at 05-DEC-08
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=2 recid=16 stamp=672676443
channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_0ck1geis tag=TAG20081205T143404 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 05-DEC-08
Starting backup at 05-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset

188

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: starting piece 1 at 05-DEC-08
channel ORA_DISK_1: finished piece 1 at 05-DEC-08
piece handle=/home/oracle/rman_0dk1geiv tag=TAG20081205T143407 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 05-DEC-08
Starting Control File and SPFILE Autobackup at 05-DEC-08
piece handle=/home/oracle/oracle/product/10.2.0/db_1/dbs/c-2432194154-20081205-03
comment=NONE
Finished Control File and SPFILE Autobackup at 05-DEC-08
Where target database is present:
[oracle@REDDY control]$ rm c1.ctl
RMAN> shutdown immediate;
database closed
database dismounted
Oracle instance shut down
RMAN> startup;
connected to target database (not started)
Oracle instance started
RMAN-00571:
===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

189

ORACLE BACKUP STRATEGIES

RMAN-00571:
===========================================================
RMAN-03002: failure of startup command at 12/05/2008 14:32:43
ORA-00205: error in identifying control file, check alert log for more info
RMAN> shutdown immediate;
Oracle instance shut down
RMAN> startup nomount;
connected to target database (not started)
Oracle instance started
Total System Global Area 343932928 bytes
Fixed Size 1219328 bytes
Variable Size 289408256 bytes
Database Buffers 50331648 bytes
Redo Buffers 2973696 bytes
RMAN> restore controlfile;
Starting restore at 05-DEC-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: restoring control file

190

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: reading from backup piece /home/oracle/oracle/product/10.2.0/db_1/dbs/c2432194154-20081205-03
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/oracle/product/10.2.0/db_1/dbs/c-2432194154-20081205-03
tag=TAG20081205T143409
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output filename=/home/oracle/tarun/control/c1.ctl
Finished restore at 05-DEC-08
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN> recover database;
Starting recover at 05-DEC-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
starting media recovery
archive log thread 1 sequence 3 is already on disk as file /home/oracle/tarun/datafiles/redo01.log
archive log filename=/home/oracle/tarun/datafiles/redo01.log thread=1 sequence=3
media recovery complete, elapsed time: 00:00:01
Finished recover at 05-DEC-08
RMAN> alter database open resetlogs;

191

ORACLE BACKUP STRATEGIES

database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
—————————————————————————————————
Note:Use of Resetlogs
SQL> select SEQUENCE#, RESETLOGS_TIME , RESETLOGS_CHANGE# from v$log_history;
SEQUENCE# RESETLOGS RESETLOGS_CHANGE#
———- ——— —————–
45 04-DEC-08 1
46 04-DEC-08 1
47 04-DEC-08 1
48 04-DEC-08 1
49 04-DEC-08 1
1 05-DEC-08 172874
2 05-DEC-08 172874
3 05-DEC-08 172874
1 05-DEC-08 175625
2 05-DEC-08 175625
3 05-DEC-08 175625

192

ORACLE BACKUP STRATEGIES

—————————————————————————————————
[oracle@REDDY ~]$ sqlplus sys as sysdba
SQL*Plus: Release 10.2.0.1.0 – Production on Fri Dec 5 14:44:27 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Enter password:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production
With the Partitioning, OLAP and Data Mining options
SQL> select status from v$instance;
STATUS
————
OPEN
SQL> select name from v$controlfile;
NAME
——————————————————————————–
/home/oracle/tarun/control/c1.ctl
SQL> !
[oracle@REDDY ~]$ cd tarun/control/
[oracle@REDDY control]$ ls
c1.ctl

193

ORACLE BACKUP STRATEGIES

RECOVERING THE DROPED TABLESPACE USING SCN:
[oracle@REDDY ~]$ rman
Recovery Manager: Release 10.2.0.1.0 – Production on Fri Dec 5 14:22:44 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> connect target sys@REDDY;
target database Password:
connected to target database: TARUN (DBID=2432194154)
RMAN> connect catalog rman@REDDY1;
recovery catalog database Password:
connected to recovery catalog database
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
Where target database is present:
SQL> create tablespace test datafile’/home/oracle/tarun/datafiles/test01.dbf’ size 20m;
Tablespace created.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;

194

ORACLE BACKUP STRATEGIES

System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> /
System altered.
RMAN> run
2> {
3> backup database plus archivelog;
4> backup current controlfile;
5> }
starting full resync of recovery catalog
full resync complete
Starting backup at 06-DEC-08
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset

195

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=1 recid=43 stamp=672763872
input archive log thread=1 sequence=2 recid=44 stamp=672764359
input archive log thread=1 sequence=3 recid=45 stamp=672764480
input archive log thread=1 sequence=4 recid=46 stamp=672765004
input archive log thread=1 sequence=5 recid=47 stamp=672765009
input archive log thread=1 sequence=6 recid=48 stamp=672765015
input archive log thread=1 sequence=7 recid=49 stamp=672765022
input archive log thread=1 sequence=8 recid=50 stamp=672765028
input archive log thread=1 sequence=9 recid=51 stamp=672765082
input archive log thread=1 sequence=10 recid=52 stamp=672765191
input archive log thread=1 sequence=11 recid=53 stamp=672765576
channel ORA_DISK_1: starting piece 1 at 06-DEC-08
channel ORA_DISK_1: finished piece 1 at 06-DEC-08
piece handle=/home/oracle/rman_1qk1j603 tag=TAG20081206T152554 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=2 recid=42 stamp=672760439
input archive log thread=1 sequence=3 recid=41 stamp=672760439

196

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: starting piece 1 at 06-DEC-08
channel ORA_DISK_1: finished piece 1 at 06-DEC-08
piece handle=/home/oracle/rman_1rk1j605 tag=TAG20081206T152554 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=1 recid=54 stamp=672765868
input archive log thread=1 sequence=2 recid=55 stamp=672765872
input archive log thread=1 sequence=3 recid=56 stamp=672765873
input archive log thread=1 sequence=4 recid=57 stamp=672765885
input archive log thread=1 sequence=5 recid=58 stamp=672765890
input archive log thread=1 sequence=6 recid=59 stamp=672765954
channel ORA_DISK_1: starting piece 1 at 06-DEC-08
channel ORA_DISK_1: finished piece 1 at 06-DEC-08
piece handle=/home/oracle/rman_1sk1j607 tag=TAG20081206T152554 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 06-DEC-08
Starting backup at 06-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset

197

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/home/oracle/tarun/datafiles/system01.dbf
input datafile fno=00002 name=/home/oracle/tarun/datafiles/undotbs1.dbf
input datafile fno=00003 name=/home/oracle/tarun/datafiles/sysaux01.dbf
input datafile fno=00004 name=/home/oracle/tarun/datafiles/users01.dbf
input datafile fno=00005 name=/home/oracle/tarun/datafiles/test01.dbf
channel ORA_DISK_1: starting piece 1 at 06-DEC-08
channel ORA_DISK_1: finished piece 1 at 06-DEC-08
piece handle=/home/oracle/rman_1tk1j60a tag=TAG20081206T152601 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:55
Finished backup at 06-DEC-08
Starting backup at 06-DEC-08
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=7 recid=60 stamp=672766077
channel ORA_DISK_1: starting piece 1 at 06-DEC-08
channel ORA_DISK_1: finished piece 1 at 06-DEC-08
piece handle=/home/oracle/rman_1uk1j63u tag=TAG20081206T152758 comment=NONE

198

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 06-DEC-08
Starting backup at 06-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
channel ORA_DISK_1: starting piece 1 at 06-DEC-08
channel ORA_DISK_1: finished piece 1 at 06-DEC-08
piece handle=/home/oracle/rman_1vk1j641 tag=TAG20081206T152801 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 06-DEC-08
Starting Control File and SPFILE Autobackup at 06-DEC-08
piece handle=/home/oracle/oracle/product/10.2.0/db_1/dbs/c-2432194154-20081206-0b
comment=NONE
Finished Control File and SPFILE Autobackup at 06-DEC-08
SQL> set time on
15:28:23 SQL> select current_scn from v$database;
CURRENT_SCN
———–
248959

199

ORACLE BACKUP STRATEGIES

15:28:44 SQL> drop tablespace test including contents and datafiles;
Tablespace dropped.
RMAN> shutdown immediate;
starting full resync of recovery catalog
full resync complete
database closed
database dismounted
Oracle instance shut down
RMAN> startup nomount;
connected to target database (not started)
Oracle instance started
Total System Global Area 343932928 bytes
Fixed Size 1219328 bytes
Variable Size 289408256 bytes
Database Buffers 50331648 bytes
Redo Buffers 2973696 bytes
RMAN> restore controlfile until scn 248959;
Starting restore at 06-DEC-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK

200

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: reading from backup piece /home/oracle/oracle/product/10.2.0/db_1/dbs/c2432194154-20081206-0b
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/oracle/product/10.2.0/db_1/dbs/c-2432194154-20081206-0b
tag=TAG20081206T152805
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output filename=/home/oracle/tarun/control/c1.ctl
Finished restore at 06-DEC-08
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN> run {
2> set until scn 248959;
3> restore database;
4> recover database;
5> }
executing command: SET until clause
Starting restore at 06-DEC-08
allocated channel: ORA_DISK_1

201

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: sid=36 devtype=DISK
skipping datafile 1; already restored to file /home/oracle/tarun/datafiles/system01.dbf
skipping datafile 2; already restored to file /home/oracle/tarun/datafiles/undotbs1.dbf
skipping datafile 3; already restored to file /home/oracle/tarun/datafiles/sysaux01.dbf
skipping datafile 4; already restored to file /home/oracle/tarun/datafiles/users01.dbf
datafile 5 is already restored to file /home/oracle/tarun/datafiles/test01.dbf
restore not done; all files readonly, offline, or already restored
Finished restore at 06-DEC-08
Starting recover at 06-DEC-08
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 7 is already on disk as file /home/oracle/tarun/datafiles/redo01.log
archive log thread 1 sequence 8 is already on disk as file /home/oracle/tarun/datafiles/redo02.log
archive log filename=/home/oracle/tarun/datafiles/redo01.log thread=1 sequence=7
archive log filename=/home/oracle/tarun/datafiles/redo02.log thread=1 sequence=8
media recovery complete, elapsed time: 00:00:01
Finished recover at 06-DEC-08
RMAN> alter database open resetlogs;
database opened
new incarnation of database registered in recovery catalog

202

ORACLE BACKUP STRATEGIES

starting full resync of recovery catalog
full resync complete
15:29:23 SQL> !
[oracle@REDDY ~]$ sqlplus sys as sysdba
SQL*Plus: Release 10.2.0.1.0 – Production on Sat Dec 6 15:38:21 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Enter password:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – Production
With the Partitioning, OLAP and Data Mining options
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
——————————
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
TEST
6 rows selected.

203

ORACLE BACKUP STRATEGIES

RECOVERING THE DROPED TABLESPACE USING LOGSEQ:
[oracle@REDDY ~]$ rman
Recovery Manager: Release 10.2.0.1.0 – Production on Fri Dec 5 14:22:44 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> connect target sys@REDDY;
target database Password:
connected to target database: TARUN (DBID=2432194154)
RMAN> connect catalog rman@REDDY1;
recovery catalog database Password:
connected to recovery catalog database
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
Where target database is present:
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
——————————
SYSTEM
UNDOTBS1

204

ORACLE BACKUP STRATEGIES

SYSAUX
TEMP
USERS
TEST
TBS
TC
8 rows selected.
SQL> alter system switch logfile;
System altered.
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /home/oracle/tarun/archive
Oldest online log sequence 9
Next log sequence to archive 10
Current log sequence 10
RMAN> resync catalog;
starting full resync of recovery catalog
full resync complete
RMAN> run

205

ORACLE BACKUP STRATEGIES

2> {
3> backup database plus archivelog;
4> backup current controlfile;
5> }
Starting backup at 11-DEC-08
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=1 recid=94 stamp=673107981
input archive log thread=1 sequence=2 recid=95 stamp=673187822
input archive log thread=1 sequence=3 recid=96 stamp=673188203
input archive log thread=1 sequence=4 recid=97 stamp=673188358
input archive log thread=1 sequence=5 recid=98 stamp=673188428
input archive log thread=1 sequence=6 recid=99 stamp=673188429
input archive log thread=1 sequence=7 recid=100 stamp=673188436
input archive log thread=1 sequence=8 recid=101 stamp=673188442
input archive log thread=1 sequence=9 recid=102 stamp=673188448
input archive log thread=1 sequence=10 recid=103 stamp=673188526
channel ORA_DISK_1: starting piece 1 at 11-DEC-08

206

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: finished piece 1 at 11-DEC-08
piece handle=/home/oracle/rman_1rk202lf tag=TAG20081211T124847 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 11-DEC-08
Starting backup at 11-DEC-08
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/home/oracle/tarun/datafiles/system01.dbf
input datafile fno=00002 name=/home/oracle/tarun/datafiles/undotbs1.dbf
input datafile fno=00003 name=/home/oracle/tarun/datafiles/sysaux01.dbf
input datafile fno=00006 name=/home/oracle/tarun/datafiles/tbs.dbf
input datafile fno=00005 name=/home/oracle/tarun/datafiles/test01.dbf
input datafile fno=00004 name=/home/oracle/tarun/datafiles/users01.dbf
input datafile fno=00007 name=/home/oracle/tarun/datafiles/tb..dbf
channel ORA_DISK_1: starting piece 1 at 11-DEC-08
channel ORA_DISK_1: finished piece 1 at 11-DEC-08
piece handle=/home/oracle/rman_1sk202li tag=TAG20081211T124850 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:25
channel ORA_DISK_1: starting full datafile backupset

207

ORACLE BACKUP STRATEGIES

channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 11-DEC-08
channel ORA_DISK_1: finished piece 1 at 11-DEC-08
piece handle=/home/oracle/rman_1tk202q3 tag=TAG20081211T124850 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 11-DEC-08
Starting backup at 11-DEC-08
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=11 recid=104 stamp=673188678
channel ORA_DISK_1: starting piece 1 at 11-DEC-08
channel ORA_DISK_1: finished piece 1 at 11-DEC-08
piece handle=/home/oracle/rman_1uk202q7 tag=TAG20081211T125119 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 11-DEC-08
Starting backup at 11-DEC-08

208

ORACLE BACKUP STRATEGIES

using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current control file in backupset
channel ORA_DISK_1: starting piece 1 at 11-DEC-08
channel ORA_DISK_1: finished piece 1 at 11-DEC-08
piece handle=/home/oracle/rman_1vk202q9 tag=TAG20081211T125121 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
Finished backup at 11-DEC-08
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /home/oracle/tarun/archive
Oldest online log sequence 12
Next log sequence to archive 13
Current log sequence 13
SQL> drop tablespace test including contents and datafiles;
Tablespace dropped.
RMAN> shutdown immediate;
starting full resync of recovery catalog

209

ORACLE BACKUP STRATEGIES

full resync complete
database closed
database dismounted
Oracle instance shut down
RMAN> startup nomount;
connected to target database (not started)
Oracle instance started
Total System Global Area 343932928 bytes
Fixed Size 1219328 bytes
Variable Size 289408256 bytes
Database Buffers 50331648 bytes
Redo Buffers 2973696 bytes
RMAN> restore controlfile until logseq 13;
Starting restore at 11-DEC-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: reading from backup piece /home/oracle/rman_1vk202q9
channel ORA_DISK_1: restored backup piece 1

210

ORACLE BACKUP STRATEGIES

piece handle=/home/oracle/rman_1vk202q9 tag=TAG20081211T125121
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
output filename=/home/oracle/tarun/control/c1.ctl
Finished restore at 11-DEC-08
RMAN> startup mount;
database is already started
database mounted
released channel: ORA_DISK_1
RMAN> run {
2> set until logseq 13;
3> restore database;
4> recover database;
5> }
executing command: SET until clause
Starting restore at 11-DEC-08
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=36 devtype=DISK
channel ORA_DISK_1: starting datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
restoring datafile 00001 to /home/oracle/tarun/datafiles/system01.dbf

211

ORACLE BACKUP STRATEGIES

restoring datafile 00002 to /home/oracle/tarun/datafiles/undotbs1.dbf
restoring datafile 00003 to /home/oracle/tarun/datafiles/sysaux01.dbf
restoring datafile 00004 to /home/oracle/tarun/datafiles/users01.dbf
restoring datafile 00005 to /home/oracle/tarun/datafiles/test01.dbf
restoring datafile 00006 to /home/oracle/tarun/datafiles/tbs.dbf
restoring datafile 00007 to /home/oracle/tarun/datafiles/tb..dbf
channel ORA_DISK_1: reading from backup piece /home/oracle/rman_1sk202li
channel ORA_DISK_1: restored backup piece 1
piece handle=/home/oracle/rman_1sk202li tag=TAG20081211T124850
channel ORA_DISK_1: restore complete, elapsed time: 00:01:26
Finished restore at 11-DEC-08
Starting recover at 11-DEC-08
using channel ORA_DISK_1
starting media recovery
archive log thread 1 sequence 11 is already on disk as file
/home/oracle/tarun/archive/arch_1_673019616_11.arc
archive log thread 1 sequence 12 is already on disk as file /home/oracle/tarun/datafiles/redo01.log
archive log filename=/home/oracle/tarun/archive/arch_1_673019616_11.arc thread=1 sequence=11
archive log filename=/home/oracle/tarun/datafiles/redo01.log thread=1 sequence=12
media recovery complete, elapsed time: 00:00:00
Finished recover at 11-DEC-08

212

ORACLE BACKUP STRATEGIES

RMAN> alter database open resetlogs;
database opened
new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
——————————
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
TEST
TBS
TC
8 rows selected.
Allocating Multiple Channels Using RMAN:
Connect to the target database
[oracle@REDDY ~]$ rman

213

ORACLE BACKUP STRATEGIES

Recovery Manager: Release 10.2.0.1.0 – Production on Wed Nov 19 14:11:32 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
RMAN> connect target sys@REDDY (netservice name,tns name of the client)
target database Password:
connected to target database: TARUN (DBID=2429858623)
Connect to the catalog database
RMAN> connect catalog rman/rman@REDDY1;
connected to recovery catalog database
(Both the target database and catalog database must be connected at the same time)
Create the catalog
RMAN> create catalog;
recovery catalog created
Register the database
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
Configure the channel
RMAN>configure channel device type disk format ‘/home/oracle/rmanbackup_%u’;
new RMAN configuration parameters:

214

ORACLE BACKUP STRATEGIES

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/rmanbackup_%u’;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
RMAN> run
2> {
3> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/oracle/rmanbackup_%u’;
4> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/oracle/product/rmanbackup_
%u’;
5> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
‘/home/oracle/oracle/product/10.2.0/rmanbackup_%u’;}
old RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/rmanbackup_%u’;
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/oracle/rmanbackup_%u’;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
old RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/oracle/rmanbackup_%u’;
new RMAN configuration parameters:

215

ORACLE BACKUP STRATEGIES

CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/oracle/product/rmanbackup_%u’;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete
old RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/oracle/product/rmanbackup_%u’;
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT ‘/home/oracle/oracle/product/10.2.0/rmanbackup_
%u’;
new RMAN configuration parameters are successfully stored
starting full resync of recovery catalog
full resync complete

Difference between: Full, Differential, and Incremental Backup
Type

Definition

Benefits

Drawbacks

Full
Backup:

A complete backup of everything you
want to backup.

Restoration is fast,
since you only need
one set of backup
data.

The backing up
process is slow.
High storage
requirements.

Differential
Backup:

The backup software looks at which
files have changed since you last did
a full backup. Then creates copies of
all the files that are different from the
ones in the full backup.

Faster to create than
a full backup.

Restoration is slower
than using a full
backup.

If you do a differential backup more
than once, it will copy all the files, or
parts of files that have changed since
the last full backup, even if you
already have identical copies of those

Restoration is faster
than using
incremental backup.
Not as much storage
needed as in a full
backup.

Creating a differential
backup is slower than
creating an
incremental backup.

216

ORACLE BACKUP STRATEGIES

files in a previous differential backup.
For restoring all the data, you will
only need the the last full backup,
and the last differential backup.
The backup software creates copies
of all the files, or parts of files that
have changed since previous backups
of any type (full, differential or
incremental).
Incrementa
For example if you did a full backup
l Backup:
on Sunday. An incremental backup
made on Monday, would only contain
files changed since Sunday, and an
incremental backup on Tuesday,
would only contain files changed
since Monday, and so on.

This method is the
fastest when creating
a backup.
The least storage
space is needed.

Restoring from
incremental backups
is the slowest because
it may require several
sets of data to fully
restore all the data.
For example if you
had a full backup and
six incremental
backups. To restore
the data would
require you to process
the full backup and all
six incremental
backups.

Flashback Architecture In Oracle
Oracle Flashback Technology is a group of Oracle Database features that let us view past states of
database objects or to return database objects to a previous state without using point-in-time media
recovery. Flashback Database is a part of the backup & recovery enhancements in Oracle 10g
Database that are called Flashback Features .
Flashback Database enables us to wind our entire database backward in time, reversing the effects of
unwanted database changes within a given time window. The effects are similar to database point-intime recovery. It is similar to conventional point in time recovery in its effects, allowing us to return a
database to its state at a time in the recent past.
Flashback Database can be used to reverse most unwanted changes to a database, as long as the
datafiles are intact. Oracle Flashback Database lets us quickly recover an Oracle database to a
previous time to correct problems caused by logical data corruptions or user errors.
What are the Benefits?
According to many studies and reports, Human Error accounts for 30-35% of data loss episodes. This
makes Human Errors one of the biggest single causes of downtime. With Flashback Database feature
Oracle is trying to fight against user and operator errors in an extremely fast and effective way.
In most cases, a disastrous logical failure caused by human error can be solved by performing a
Database Point-in-Time Recovery (DBPITR). Before 10g the only way to do a DBPITR was incomplete
media recovery. Media Recovery is a slow and time-consuming process that can take a lot of hours. On
the other side, by using of Flashback Database a DBPITR can be done in an extremely fast way: 25 to

217

ORACLE BACKUP STRATEGIES
105 times faster than usual incomplete media recovery and in result it can minimize the downtime
significantly.
Flashback Database provides :


Very effective way to recover from complex human errors.



Faster database point-in-time recovery.



Simplified management and administration .



Little performance overhead .



It provides a lot of benefits and almost no disadvantages.

The Flashback Database is not just our database “rewind” button. It is a “Time Machine” for our
Database data that is one single command away from us.
The Flashback Database Architecture :
Flashback Database uses its own type of log files, called Flashback Database Log Files. To support this
mechanism, Oracle uses new background process called RVWR (Recovery Writer) and a new buffer in
the SGA, called Flashback Buffer. The Oracle database periodically logs before images of data blocks
in the flashback buffer. The flashback buffer records images of all changed data blocks in the
database. This means that every time a data block in the database is altered, the database writes a
before image of this block to the flashback buffer. This before image can be used to reconstruct a
datafile
to
the
current
point
of
time.
The maximum allowed memory for the flashback buffer is 16 MB. We don’t have direct control on its
size. The flashback buffer size depends on the size of the current redo log buffer that is controlled by
Oracle. Starting at 10g R2, the log buffer size cannot be controlled manually by setting the
initialization parameter LOG_BUFFER.

In 10G R2, Oracle combines fixed SGA area and redo buffer together. If there is a free space after

218

ORACLE BACKUP STRATEGIES
Oracle puts the combined buffers into a granule, that space is added to the redo buffer. The sizing of
the redo log buffer is fully controlled by Oracle. According to SGA and its atomic sizing by granules,
Oracle will calculate automatically the size of the log buffer depending of the current granule size. For
smaller SGA size and 4 MB granules, it is possible redo log buffer size + fixed SGA size to be multiple
of the granule size. For SGAs bigger than 128 MB, the granule size is 16 MB. We can see current size
of the redo log buffer, fixed SGA and granule by querying the V$SGAINFO view , and can query the
V$SGASTAT view to display detailed information on the SGA and its structures.
To find current size of the flashback buffer, we can use the following query:
SQL> SELECT * FROM v$sgastat WHERE NAME = 'flashback generation buff';
There is no official information from Oracle that confirms the relation between 'flashback generation
buff' structure in SGA and the real flashback buffer structure. This is only a suggestion. A similar
message message is written to the alertSID.log file during opening of the database .
Allocated 3981204 bytes in shared pool for flashback generation buffer Starting background process
RVWR RVWR started with pid=16, OS id=5392 .
RVWR writes periodically flashback buffer contents to flashback database logs. It is an asynchronous
process and we don’t have control over it. All available sources are saying that RVWR writes
periodically to flashback logs. The explanation for this behavior is that Oracle is trying to reduce the
I/O and CPU overhead that can be an issue in many production environments.

Flashback log files can be created only under the Flash Recovery Area (that must be configured before
enabling the Flashback Database functionality). RVWR creates flashback log files into a directory
named “FLASHBACK” under FRA. The size of every generated flashback log file is again under Oracle’s
control. According to current Oracle environment – during normal database activity flashback log files
have size of 8200192 bytes. It is very close value to the current redo log buffer size. The size of a
generated flashback log file can differs during shutdown and startup database activities. Flashback log
file sizes can differ during high intensive write activity as well.
Flashback log files can be written only under FRA (Flash Recovery Area). FRA is closely related and is
built on top of Oracle Managed Files (OMF). OMF is a service that automates naming, location, creation
and deletion of database files. By using OMF and FRA, Oracle manages easily flashback log files. They
are created with automatically generated names with extension .FLB. For instance, this is the name of
one flashback log file: O1_MF_26ZYS69S_.FLB
By its nature flashback logs are similar to redo log files. LGWR writes contents of the redo log buffer to
online redo log files, RVWR writes contents of the flashback buffer to flashback database log files.
Redo log files contain all changes that are performed in the database, that data is needed in case of
media or instance recovery. Flashback log files contain only changes that are needed in case of
flashback operation. The main differences between redo log files and flashback log files are :


Flashback log files are never archived - they are reused in a circular manner.



Redo log files are used to forward changes in case of recovery while flashback log files are
used to backward changes in case of flashback operation.



Flashback log files can be compared with UNDO data (contained in UNDO tablespaces) as well.
While UNDO data contains changes at the transaction level, flashback log files contain UNDO data
at the data block level. While UNDO tablespace doesn’t record all operations performed on the
database (for instance, DDL operations), flashback log files record that data as well. In few
words, flashback log files contain the UNDO data for our database.

To Summarize

:

219

ORACLE BACKUP STRATEGIES


UNDO data doesn’t contain all changes that are performed in the database while flashback
logs contain all altered blocks in the database .



UNDO data is used to backward changes at the transaction level while flashback logs are used
to backward changes at the database level .

We can query the V$FLASHBACK_DATABASE_LOGFILE to find detailed info about our flashback log
files. Although this view is not documented it can be very useful to check and monitor generated
flashback logs.
There is a new record section within the control file header that is named FLASHBACK LOGFILE
RECORDS. It is similar to LOG FILE RECORDS section and contains info about the lowest and highest
SCN contained in every particular flashback database log file .
***************************************************************************
FLASHBACK LOGFILE RECORDS
***************************************************************************
(size = 84, compat size = 84, section max = 2048, section in-use = 136,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 139, numrecs = 2048)
FLASHBACK LOG FILE #1:
(name #4) E:\ORACLE\FLASH_RECOVERY_AREA\ORCL102\FLASHBACK\O1_MF_26YR1CQ4_.FLB
Thread 1 flashback log links: forward: 2 backward: 26
size: 1000 seq: 1 bsz: 8192 nab: 0x3e9 flg: 0x0 magic: 3 dup: 1
Low scn: 0x0000.f5c5a505 05/20/2006 21:30:04
High scn: 0x0000.f5c5b325 05/20/2006 22:00:38
What does a Flashback Database operation ?

When we perform a flashback operation, Oracle needs all flashback logs from now on to the desired
time. They will be applied consecutively starting from the newest to the oldest. For instance, if we
want to flashback the database to SCN 4123376440, Oracle will read flashback logfile section in
control file and will check for the availability of all needed flashback log files. The last needed
flashback log should be this with Low scn and High scn values between the desired SCN 4123376440 .
In current environment this is the file with name: O1_MF_26YSTQ6S_.FLB and with values of:
Low SCN : 4123374373
High SCN : 4123376446

Note: If we want to perform successfully a flashback operation we will always need to have available
at least one archived (or online redo) log file. This is a particular file that contains redo log information
about changes around the desired flashback point in time (SCN 4123376440). In this case, this is the
archived redo log with name: ARC00097_0587681349.001 that has values of:
First change#: 4123361850
Next change#: 4123380675

The flashback operation will not succeed without this particular archived redo log. The reason for this :
Flashback log files contain information about before-images of data blocks, related to some SCN
(System Change Number). When we perform flashback operation to SCN 4123376440, Oracle cannot
apply all needed flashback logs and to complete successfully the operation because it applying beforeimages of data. Oracle needs to restore each data block copy (by applying flashback log files) to its
state at a closest possible point in time before SCN 4123376440. This will guarantee that the
subsequent “redo apply” operation will forward the database to SCN 4123376440 and the database
will be in consistent state. After applying flashback logs, Oracle will perform a forward operation by

220

ORACLE BACKUP STRATEGIES
applying all needed archive log files (in this case redo information from the file:
ARC00097_0587681349.001) that will forward the database state to the desired SCN.
Oracle cannot start applying redo log files before to be sure that all data blocks are returned to their
state before the desired point in time. So, if desired restore point of time is 10:00 AM and the oldest
restored data block is from 09:47 AM then we will need all archived log files that contain redo data for
the time interval between 09:47 AM and 10:00 AM. Without that redo data, the flashback operation
cannot succeed. When a database is restored to its state at some past target time using Flashback
Database, each block changed since that time is restored from the copy of the block in the flashback
logs most immediately prior to the desired target time. The redo log is then used to re-apply changes
since the time that block was copied to the flashback logs.
Note : Redo logs must be available for the entire time period spanned by the flashback logs, whether
on tape or on disk. (In practice, however, redo logs are generally needed much longer than the
flashback retention target to support point-in-time recovery.)
Flashback logs are not independent. They can be used only with the redo data that contains database
changes around the desired SCN. This means that if we want to have working flashback window (and
to be able to restore the database to any point in time within this window) we need to ensure the
availability of redo logs as well. If we are familiar with this information then we will be able to work in
a better way with this feature and to ensure that it will help us to perform faster recovery without
unexpected
problems.
Rules
for
Retention
and
Deletion
of
Flashback
Logs
:
The following rules govern the flash recovery area's creation, retention, overwriting and deletion of
flashback logs:



A flashback log is created whenever necessary to satisfy the flashback retention target, as
long as there is enough space in the flash recovery area.



A flashback log can be reused, once it is old enough that it is no longer needed to satisfy the
flashback retention target.



If the database needs to create a new flashback log and the flash recovery area is full or there
is no disk space, then the oldest flashback log is reused instead.



If the flash recovery area is full, then an archived redo log may be automatically deleted by
the flash recovery area to make space for other files. In such a case, any flashback logs that would
require the use of that redo log file for the use of FLASHBACK DATABASE are also deleted.
Note : Re-using the oldest flashback log shortens the flashback database window. If enough flashback
logs are reused due to a lack of disk space, the flashback retention target may not be satisfied.
Limitations of Flashback Database :






Since Flashback Database works by undoing changes to the datafiles that exist at the moment
that we run the command, it has the following limitations:Flashback Database can only undo changes
to a datafile made by an Oracle database. It cannot be used to repair media failures, or to recover
from accidental deletion of datafiles.
we cannot use Flashback Database to undo a shrink datafile operation.
If the database control file is restored from backup or re-created, all accumulated flashback
log information is discarded. We cannot use FLASHBACK DATABASE to return to a point in time
before the restore or re-creation of a control file.

221

ORACLE BACKUP STRATEGIES
When using Flashback Database with a target time at which a NOLOGGING operation was in progress,
block corruption is likely in the database objects and datafiles affected by the NOLOGGING operation.
For example, if we perform a direct-path INSERT operation in NOLOGGING mode, and that operation
runs from 9:00 to 9:15 , and we later need to use Flashback Database to return to the target time
09:07 on that date, the objects and datafiles updated by the direct-path INSERT may be left with
block
corruption
after
the
Flashback
Database
operation
completes.
If possible, avoid using Flashback Database with a target time or SCN that coincides with a
NOLOGGING operation. Also, perform a full or incremental backup of the affected datafiles
immediately after any NOLOGGING operation to ensure recoverability to points in time after the
operation. If we expect to use Flashback Database to return to a point in time during an operation
such as a direct-path INSERT, consider performing the operation in LOGGING mode.
Finally few important point to be noted :



The Flashback Database should be part of our Backup & Recovery Strategy but it not
supersedes the normal physical backup & recovery strategy. It is only an additional protection of our
database data.



The Flashback Database can be used to flashes back a database to its state to any point in
time into the flashback window, only if all flashback logs and their related archived redo logs for the
spanned time period are physically available and accessible.



Always ensure that archived redo logs covering the flashback window are available on either
the tape or disk.



We cannot perform flashback database operation if we have media failure. In this case we
must use the traditional database point-in-time media recovery method.



Always write down the current SCN or/and create a restore point (10g R2) before any
significant change over our database: applying of patches, running of batch jobs that can can corrupt
the data, etc. As we know: The most common cause for downtime is change.



Always write down the current SCN or/and create a restore point (10g R2) before to start a
flashback operation .



Flashback database is the only one flashback operation that can be performed to undone
result of a TRUNCATE command (FLASHBACK DROP, FLASHBACK TABLE, or FLASHBACK QUERY
cannot be used for this).



Dropping of tablespace cannot be reversed with Flashback Database. After such an operation,
the flashback database window begins at the time immediately following that operation.



Shrink a datafile cannot be reversed with Flashback Database. After such an operation, the
flashback database window begins at the time immediately following that operation.



Resizing of datafile cannot be reversed with Flashback Database. After such an operation, the
flashback database window begins at the time immediately following that operation. If we need to
perform flashback operation in this time period, we must offline this datafile before performing of
flashback operation.



Recreating or restoring of control file prevents using of Flashback Database before this point of
time.

222

ORACLE BACKUP STRATEGIES



We can flashback database to a point in time before a RESETLOGS operation. This feature is
available from 10g R2 because the flashback log files are not deleted after RESETLOGS operation. We
cannot do this in 10g R1 because old flashback logs are deleted immediately after an RESETLOGS
operation.



Don’t exclude the SYSTEM tablespace from flashback logging. Otherwise we will not be able to
flashback the database.



The DB_FLASHBACK_RETENTION_TARGET parameter is a TARGET parameter. It doesn’t
guarantee the flashback database window. Our proper configuration of the Flashback Database
should guarantee it.



Monitor regularly the size of the FRA and generated flashback logs to ensure that there is no
space pressure and the flashback log data is within the desired flashback window

Flashback Features in Oracle 10g
As I have cover the "Architecture Of Flashback" in Oracle 10g in my previous post. Here i am going
further to explain and perform the some demo of the flashback features of Oracle 10g.

How to check Flashback Status :
Flashback status of a database can be checked from the below query and system parameters.
SQL> select NAME,FLASHBACK_ON from v$database ;
SQL> show parameter undo_retention
NAME
TYPE
VALUE
---------------------------------undo_retention
integer
900
SQL> show parameter db_flashback_retention
NAME
TYPE
------------------------------------------db_flashback_retention_target
integer

VALUE
--------1440

SQL> show parameter db_recovery_file_dest
NAME
TYPE
VALUE
---------------------------------------------------------------------------------------db_recovery_file_dest
string
D:\oracle\product\10.2.0\flash_recovery_area
db_recovery_file_dest_size
big integer
5G
If the database Flashback feature is off then follow the below steps :
1.) The Database must be started through SPFILE.
SQL> show parameter spfile
NAME
TYPE
----------------spfile
string

VALUE
---------------------------------------------D:\ORACLE\PRODUCT\10.2.0\DB_1\
DATABASE\SPFILENOIDA.ORA

223

ORACLE BACKUP STRATEGIES
2.) The Database must be in Archive log mode.
SQL>
SQL>
SQL>
SQL>

shut immediate
startup mount
alter database archivelog ;
alter database open ;

3.) Undo management should be AUTO
SQL> show parameter undo_management
NAME
TYPE
VALUE
------------------------------------undo_management
string
AUTO
4.) Set the Recovery file destination or flashback area which will contain all flashback logs
depending on the undo retention period

SQL> alter
scope=both;

system

set

db_recovery_file_dest='D:\oracle\product\10.2.0\flash_recovery_area'

System altered.

5.) Set the recovery file destination size. This is the hard limit on the total space to be used
by target database recovery files created in the flash recovery area .

SQL> alter system set db_recovery_file_dest_size=5G scope=both;
System altered.
6.) Set the flash back retention target . This is the upper limit (in minutes) on how far back
in time the database may be flashed back. How far back one can flashback a database
depends on how much flashback data Oracle has kept in the flash recovery area.

SQL> alter system set db_flashback_retention_target=1440 scope=both;
System altered.
7.) Convert the Database to FLASHBACK ON state.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 830472192 bytes

224

ORACLE BACKUP STRATEGIES
Fixed Size
2074760 bytes
Variable Size
213911416 bytes
Database Buffers
608174080 bytes
Redo Buffers
6311936 bytes
Database mounted.
SQL> ALTER DATABASE FLASHBACK ON ;
Database altered.
SQL> alter database open;
Database altered.
SQL> select NAME, FLASHBACK_ON
NAME
FLASHBACK_ON
-----------------------------NOIDA
YES

from

v$database ;

Flashback technology provides a set of features to view and rewind data back and forth in time. The
flashback features offer the capability to query past versions of schema objects, query historical data,
perform change analysis, and perform self-service repair to recover from logical corruption while the
database is online.Here we will discuss some more features of FlashBack .

The Flashback features are :
1.) Flashback Query
2.) Flashback Version Query
3.) Flashback Transaction Query
4.)Flashback Table
5.) Flashback Drop (Recycle Bin)
6.) Flashback Database
7.) Flashback Query Functions
1.) Flashback Query : Flashback Query allows the contents of a table to be queried with reference
to a specific point in time, using the AS OF clause. Essentially it is the same as the DBMS_FLASHBACK
functionality , but in a more convenient form. For example, Here is a Demo of Flashback Query :
SQL> CREATE TABLE flashback_query_test (id NUMBER(10));
Table created.
SQL> SELECT current_scn, TO_CHAR(SYSTIMESTAMP, 'YYYY-MM-DD HH24:MI:SS') FROM v$database;
CURRENT_SCN
TO_CHAR(SYSTIMESTAM
-----------------------------------------------1365842
2011-08-12 13:44:15
SQL> INSERT INTO flashback_query_test (id) VALUES (1);
1 row created.
SQL> commit;
Commit complete.
SQL> SELECT COUNT(*) FROM flashback_query_test;
COUNT(*)
----------

225

ORACLE BACKUP STRATEGIES
1
SQL> SELECT COUNT(*) FROM flashback_query_test AS OF TIMESTAMP TO_TIMESTAMP('2011-08-12
13:44:15', 'YYYY-MM-DD HH24:MI:SS');
COUNT(*)
---------0
SQL> SELECT COUNT(*) FROM flashback_query_test AS OF SCN 1365842;
COUNT(*)
---------0
2.) Flashback Version Query : Oracle Flashback Versions Query is an extension to SQL that can be
used to retrieve the versions of rows in a given table that existed in a specific time interval. Oracle
Flashback Versions Query returns a row for each version of the row that existed in the specified time
interval. For any given table, a new row version is created each time the COMMIT statement is
executed. Flashback version query allows the versions of a specific row to be tracked during a
specified time period using the VERSIONS
BETWEEN clause . Here is Demo of Flashback Version Query :

SQL> CREATE TABLE flashback_version_query_test (id NUMBER(10),description VARCHAR2(50));
Table created.
SQL> INSERT INTO flashback_version_query_test (id, description) VALUES (1, 'ONE');
1 row created.
SQL> COMMIT;
Commit complete.
SQL> SELECT current_scn, TO_CHAR(SYSTIMESTAMP, 'YYYY-MM-DD HH24:MI:SS') FROM v$database;
CURRENT_SCN
TO_CHAR(SYSTIMESTAMP)
-------------------------------------------------1366200
2011-08-12 13:53:16
SQL> UPDATE flashback_version_query_test SET description = 'TWO' WHERE id = 1;
1 row updated.
SQL> COMMIT;
Commit complete.
SQL> UPDATE flashback_version_query_test SET description = 'THREE' WHERE id = 1;
1 row updated.
SQL> COMMIT;
Commit complete.
SQL> SELECT current_scn, TO_CHAR(SYSTIMESTAMP, 'YYYY-MM-DD HH24:MI:SS') FROM v$database;

226

ORACLE BACKUP STRATEGIES
CURRENT_SCN
------------------1366214

TO_CHAR(SYSTIMESTAM
--------------------------------2011-08-12 13:54:38

SQL>SELECT versions_startscn, versions_starttime, versions_endscn, versions_endtime,
versions_operation, description
FROM flashback_version_query_test
VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP('2011-08-12 13:53:11', 'YYYY-MM-DD
HH24:MI:SS')
AND TO_TIMESTAMP('2011-08-12 13:54:38', 'YYYY-MM-DD HH24:MI:SS')
WHERE id = 1;
VERSIONS_STARTSCN
VERSIONS_ENDTIME
1366212
U
1366209
13:53:35.000
U

VERSIONS_STARTTIME
VERSIONS_ENDSCN
VERSIONS_OPERATION
DESCRIPTION
12.08.11 13:53:35.000
THREE
12.08.11 13:53:35.000
1366212
12.08.11
TWO
1366209

13:53:35.000
3 rows selected

12.08.11

ONE

The available pseudocolumn meanings are:


VERSIONS_STARTSCN or VERSIONS_STARTTIME - Starting SCN and TIMESTAMP when
row took on this value. The value of NULL is returned if the row was created before the lower
bound SCN or TIMESTAMP.



VERSIONS_ENDSCN or VERSIONS_ENDTIME - Ending SCN and TIMESTAMP when row last
contained this value. The value of NULL is returned if the value of the row is still current at the
upper bound SCN ot TIMESTAMP.



VERSIONS_XID - ID of the transaction that created the row in it's current state.



VERSIONS_OPERATION - Operation performed by the transaction ( (I)nsert, (U)pdate or
(D)elete) .

3.) Flashback Transaction Query : Flashback transaction query can be used to get extra information
about the transactions listed by flashback version queries. The VERSIONS_XID column values from a
flashback version query can be used to query the FLASHBACK_TRANSACTION_QUERY view.

SQL> SELECT xid, operation, start_scn,commit_scn, logon_user, undo_sql FROM
flashback_transaction_query WHERE xid = HEXTORAW('0600030021000000');
XID
--------------UNDO_SQL
-------------0600030021000000

OPERATION
--------------

UPDATE

START_SCN
--------------

725208

COMMIT_SCN
----------------

725209

LOGON_USER
--------------

SCOTT

update "SCOTT"."FLASHBACK_VERSION_QUERY_TEST" set "DESCRIPTION" = 'ONE'

where ROWID

227

ORACLE BACKUP STRATEGIES
= 'AAAMP9AAEAAAAAYAAA' ;
1 rows selected.
4.) Flashback Table :
There are two distinct table related flashback table features in oracle,
flashback table which relies on undo segments and flashback drop which lies on the recyclebin not the
undo segments.

Flashback table lets we recover a table to a previous point in time, we don't have to take the
tablespace offline during a recovery, however oracle acquires exclusive DML locks on the table or
tables that we are recovering, but the table continues to be online. When using flashback table oracle
does not preserve the ROWIDS when it restores the rows in the changed data blocks of the tables,
since it uses DML operations to perform its work, we must have enabled row movement in the tables
that we are going to flashback, only flashback table requires we to enable row movement. If the data
is not in the undo segments then we cannot recover the table by using flashback table, however we
can use other means to recover the table.

Restriction on flashback table recovery : we cannot use flashback table on SYS objects we cannot
flashback a table that has had preceding DDL operations on the table like table structure changes,
dropping columns, etc The flashback must entirely exceed or it will fail, if flashing back multiple tables
all tables must be flashed back or none. Any constraint violations will abort the flashback operation we
cannot flashback a table that has had any shrink or storage changes to the table (pct-free, initrans
and maxtrans. The following example creates a table, inserts some data and flashbacks to a point
prior to the data insertion. Finally it flashbacks to the time after the data insertion.Here is demo of
the Flashback Table :

SQL> CREATE TABLE flashback_table_test (id NUMBER(10));
Table created.
SQL> ALTER TABLE flashback_table_test ENABLE ROW MOVEMENT;
Table altered.
SQL> SELECT current_scn FROM v$database;
CURRENT_SCN
--------------1368791
SQL> INSERT INTO flashback_table_test (id) VALUES (1);
1 row created.
SQL> COMMIT;
Commit complete.
SQL> SELECT current_scn FROM v$database;
CURRENT_SCN
---------------1368802
SQL> FLASHBACK TABLE flashback_table_test TO SCN 1368791;

228

ORACLE BACKUP STRATEGIES
Flashback complete.
SQL> SELECT COUNT(*) FROM flashback_table_test;
COUNT(*)
---------0
SQL> FLASHBACK TABLE flashback_table_test TO SCN 1368802;
Flashback complete.
SQL> SELECT COUNT(*) FROM flashback_table_test;
COUNT(*)
------------1
Flashback of tables can also be performed using timestamps.
SQL> FLASHBACK TABLE flashback_table_test TO TIMESTAMP TO_TIMESTAMP('2004-03-03
10:00:00', 'YYYY-MM-DD HH:MI:SS');
5.) Flashback Drop (Recycle Bin) : Prior to Oracle 10g, a DROP command permanently removed
objects from the database. In Oracle 10g, a DROP command places the object in the recycle bin. The
extents allocated to the segment are not reallocated until we purge the object. we can restore the
object from the recycle bin at any time. This feature eliminates the need to perform a point-in-time
recovery operation. Therefore, it has minimum impact to other database users.

In Oracle 10g the default action of a DROP TABLE command is to move the table to the recycle bin (or
rename it), rather than actually dropping it. The PURGE option can be used to permanently drop a
table.
The recycle bin is a logical collection of previously dropped objects, with access tied to the DROP
privilege. The contents of the recycle bin can be shown using the SHOW RECYCLEBIN command and
purged using the PURGE TABLE command. As a result, a previously dropped table can be recovered
from the recycle bin.
Recycle Bin :



A recycle bin contains all the dropped database objects until :

we permanently drop them with the PURGE command.we
recover the dropped objects with the UNDROP command.



There is no room in the tablespace for new rows or updates to existing rows.



The tablespace must be extended.



We can view the dropped objects in the recycle bin from two dictionary views:

user_recyclebin —
dba_recyclebin —

list all dropped user objects.
list all dropped system-wide objects.

Here is Demo of Flashback Drop :

229

ORACLE BACKUP STRATEGIES

SQL> CREATE TABLE flashback_drop_test ( 2
Table created.

id NUMBER(10) ) ;

SQL> INSERT INTO flashback_drop_test (id) VALUES (1) ;
1 row created.
SQL> COMMIT ;
Commit complete.
SQL> DROP TABLE flashback_drop_test ;
Table dropped.
SQL> SHOW RECYCLEBIN ;
ORIGINAL NAME
RECYCLEBIN NAME
--------------------------------------------------------flashback_drop_test
BIN$KEZB6YXdRfW1925mCoGOlg==$0

OBJECT TYPE
DROPTIME
--------------------------table
201108:15:58:31EST

SQL> FLASHBACK TABLE flashback_drop_test TO BEFORE DROP;
Flashback complete.
SQL> SELECT * FROM flashback_drop_test;
ID
---------1
If an object is dropped and recreated multiple times all dropped versions will be kept in the recycle
bin, subject to space. Where multiple versions are present it's best to reference the tables via the
recyclebin_name. For any references to the ORIGINAL_NAME it is assumed the most recent object is
drop version in the referenced question. During the flashback operation the table can be renamed.
FLASHBACK TABLE flashback_drop_test TO BEFORE DROP RENAME TO flashback_drop_test_old;
Several purge options exist :

PURGE TABLE tablename;
PURGE INDEX indexname;
PURGE TABLESPACE ts_name;
PURGE TABLESPACE ts_name USER username;
specific user.
PURGE RECYCLEBIN;
PURGE DBA_RECYCLEBIN;

-- Specific table.
-- Specific index.
-- All tables in a specific tablespace.
-- All tables in a specific tablespace for a
-- The current users entire recycle bin.
-- The whole recycle bin.

Several restrictions apply relating to the recycle bin :


Only available for non-system, locally managed tablespaces.



There is no fixed size for the recycle bin. The time an object remains in the recycle bin can
vary.



The objects in the recycle bin are restricted to query operations only (no DDL or DML).

230

ORACLE BACKUP STRATEGIES


Flashback query operations must reference the recycle bin name.



Tables and all dependent objects are placed into, recovered and purged from the recycle bin at
the same time.



Tables with Fine Grained Access policies are not protected by the recycle bin.



Partitioned index-organized tables are not protected by the recycle bin.



The recycle bin does not preserve referential integrity .



Flashback Database

6.) The FLASHBACK DATABASE :
Flashback Database command is a fast alternative to
performing an incomplete recovery. In order to flashback the database we must have SYSDBA
privilege and the flash recovery area must have been prepared in advance.The database can be taken
back in time by reversing all work done sequentially. The database must be opened with resetlogs as if
an incomplete recovery has happened. This is ideal if we have a database corruption (wrong
transaction, etc) and require the database to be rewound before the corruption occurred. If we have
media or a physical problem a normal recovery is required.

Flashback database is not enabled by default, when enabled flashback database a process (RVWR –
recovery Writer) copies modified blocks to the flashback buffer. This buffer is then flushed to disk
(flashback logs). Remember the flashback logging is not a log of changes but a log of the complete
block images. Not every changed block is logged as this would be too much for the database to cope
with, so only as many blocks are copied such that performance is not impacted. Flashback database
will construct a version of the data files that is just before the time we want. The data files probably
will be in a inconsistent state as different blocks will be at different SCN’s, to complete the flashback
process, Oracle then uses the redo logs to recover all the blocks to the exact time requested thus
synchronizing all the data files to the same SCN. Archiving mode must be enabled to use flashback
database. An important note to remember is that Flashback can never reserve a change only to redo
them.

The advantage in using flashback database is speed and convenience with which we can take the
database back in time.we can use rman, sql and Enterprise manager to flashback a database. If the
flash recovery area does not have enough room the database will continue to function but flashback
operations may fail. It is not possible to flashback one tablespace, we must flashback the whole
database. If performance is being affected by flashback data collection turn some tablespace
flashbacking off .

we cannot undo a resized data file to a smaller size. When using ‘backup recovery area’ and ‘backup
recovery files’ controlfiles , redo logs, permanent files and flashback logs will not be backed up.
SQL> CREATE TABLE flashback_database_test (id NUMBER(10));
Table created.
SQL> conn / as sysdba
SQL> shut immediate

231

ORACLE BACKUP STRATEGIES
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount exclusive;
Database mounted.
SQL> FLASHBACK DATABASE TO TIMESTAMP SYSDATE-(1/24/12) ;
Flashback complete.

-----( 5 min back)

SQL> alter database open resetlogs ;
Database altered.
SQL> conn neer/neer@noida
Connected.
SQL> desc flashback_database_test
ERROR : ORA-04043 : object flashback_database_test does not exist .
Some other variations of the flashback database command includes :


FLASHBACK DATABASE TO TIMESTAMP my_date ;



FLASHBACK DATABASE TO BEFORE TIMESTAMP my_date;



FLASHBACK DATABASE TO SCN my_scn;



FLASHBACK DATABASE TO BEFORE SCN my_scn;

The
window
of
time
that
is
available
for
flashback
is
determined
by
the
db_flashback_retention_target parameter . The maximum flashback can be determined by
querying the v$flashback_database_log view . It is only possible to flashback to a point in time
after flashback was enabled on the database and since the last RESETLOGS command.

7.)Flashback Query Functions : The TIMESTAMP_TO_SCN and SCN_TO_TIMESTAMP functions
have been added to SQL and PL/SQL to simplify flashback operations.

SQL> selet * from emp as of scn timestamp_to_scn(systimestamp - 1/24) ;
SQL>select * from emp as of timestamp scn_to_timestamp(9945365);
SQL> declare
l_scn
number ;
l_timestamp timestamp;
begin
l_scn
:= timestamp_to_scn(systimestamp - 1/24);
l_timestamp := scn_to_timestamp(l_scn);
end ;
/

232

ORACLE BACKUP STRATEGIES
Flashback Data Archive (FBDA) In Oracle 11g
Flashback Data Archive (Oracle Total Recall) provides the ability to track and store all transactional
changes to a table over its lifetime. It is no longer necessary to build this intelligence into our
application. A Flashback Data Archive is useful for compliance with record stage policies and audit
reports.
Prior to oracle 11g, Flashback technology to a large part was based on the availability of undo data or
flashback logs and both the undo data as well as flashback logs are subject to recycling when out of
space pressure exists. The UNDO tablespace in Oracle was primarily meant for transaction consistency
and not data archival. A Flashback Data Archive is configured with retention time. Data archived in the
Flashback Data Archive is retained for the retention time.Let’s look at an example :
Creating a Flashback Data Archive :
SQL> create flashback archive near_term
tablespace users
retention 1 month ;
Flashback archive created.
The archive is created in the tablespace Users. Assume we have to record changes to a table called
employees which is in "HR" schema . All we need to do is enable the Flashback Data Archive status of
the table to start recording the changes in that archive .
SQL> alter table hr.employees flashback archive near_term;
Table altered.
This puts the table into the Flashback Data Archive mode. All the changes to the rows of the table will
be now tracked permanently.
SQL> select salary,job_id from hr.employees where employee_id=121;
SALARY
JOB_ID
-----------------8200
ST_MAN
SQL> update hr.employees set salary=50000 where employee_id=121;
1 row updated.
SQL> commit;
Commit complete.
Now, if we select the row, it will always display 50000 in this column. To find out the older value as of
a certain time, we can use the Flashback query as shown below :
SQL> select
salary
from
hr.employees
as
of
timestamp
10:55:00','mm/dd/yyyy hh24:mi:ss') where employee_id =121;
SALARY
--------8200

to_timestamp

('09/5/2011

Now, after some time, when the undo data has been purged out of the undo segments, query the
flashback data again:
SQL> select
salary
from
hr.employees
as
of
timestamp
10:55:00','mm/dd/yyyy hh24:mi:ss') where employee_id =121 ;
SALARY
---------

to_timestamp

('09/5/2010

233

ORACLE BACKUP STRATEGIES
8200
It comes back with the result :500000 The undo is gone, so where did the data come from .We can do
that using autotrace and see the execution plan:
SQL> set autotrace traceonly explain
SQL> select
salary
from
hr.employees
as
of
timestamp
10:55:00','mm/dd/yyyy hh24:mi:ss') where employee_id =121;

to_timestamp

('09/5/2010

Check the explain Plan detail by clicking below link :
http://www.4shared.com/document/WXMMFOS8/fda_explain_tab.html
This output answers the riddle “Where did the data come from?”; it came from the table
SYS_FBA_HIST_68909, which is a location in the Flashback Archive we defined earlier for that table.
We can check the table but it’s not supported by Oracle to directly peek at that data there. Anyway, I
don’t see a reason we would want to do that.
The data inside the archive is retained but until how long? This is where the retention period comes
into play. It’s retained up to that period. After that, when new data comes in, the older data will be
purged. We can also purge it ourself,
e.g.
SQL> alter flashback archive near_term purge before scn xxxxxxxx;
Disable flashback : Disable flashback archiving for the table employee :
SQL> ALTER TABLE hr.employee NO FLASHBACK ARCHIVE;
Remove Flashback Data Archive and all its historical data, but not its tablespaces:
SQL> DROP FLASHBACK ARCHIVE near_term ;
Use Cases :
Flashback Data Archive is handy for many purposes. Here are some ideas:
• To audit for recording how data changed
• To enable an application to undo changes (correct mistakes)
• To debug how data has been changed
• To comply with some regulations that require data must not be changed after some time. Flashback
Data
Archives are not regular tables so they can’t be changed by typical users.
• Recording audit trails on cheaper storage thereby allowing more retention at less cost
For more detail visit :
http://www.oracle.com/pls/db111/search?remark=quick_search&word=flashback+data+archive

RMAN Frequently Asked Questions
1. What is RMAN ?
Recovery Manager (RMAN) is a utility that can manage your entire Oracle backup and recovery
activities.
Which Files must be backed up?
Database Files (with RMAN)
Control Files (with RMAN)
Offline Redolog Files (with RMAN)
INIT.ORA (manually)
Password Files (manually)
2. When you take a hot backup putting Tablespace in begin backup mode, Oracle records
SCN # from header of a database file. What happens when you issue hot backup database
in RMAN at block level backup? How does RMAN mark the record that the block has been

234

ORACLE BACKUP STRATEGIES
backed up ? How does RMAN know what blocks were backed up so that it doesn't have to
scan them again?
In 11g, there is Oracle Block Change Tracking feature. Once enabled; this new 10g feature records
the modified since last backup and stores the log of it in a block change tracking file. During backups
RMAN uses the log file to identify the specific blocks that must be backed up. This improves RMAN's
performance as it does not have to scan whole datafiles to detect changed blocks.
Logging of changed blocks is performed by the CTRW process which is also responsible for writing data
to the block change tracking file. RMAN uses SCNs on the block level and the archived redo logs to
resolve any inconsistencies in the datafiles from a hot backup. What RMAN does not require is to put
the tablespace in BACKUP mode, thus freezing the SCN in the header. Rather, RMAN keeps this
information in either your control files or in the RMAN repository (i.e., Recovery Catalog).
3. What are the Architectural components of RMAN?
1.RMAN executable
2.Server processes
3.Channels
4.Target database
5.Recovery catalog database (optional)
6.Media management layer (optional)
7.Backups, backup sets, and backup pieces
4. What are Channels?
A channel is an RMAN server process started when there is a need to communicate with an I/O device,
such as a disk or a tape. A channel is what reads and writes RMAN backup files. It is through the
allocation of channels that you govern I/O characteristics such as:
Type of I/O device being read or written to, either a disk or an sbt_tape
Number of processes simultaneously accessing an I/O device
Maximum size of files created on I/O devices
Maximum rate at which database files are read
Maximum number of files open at a time
5. Why is the catalog optional?
Because RMAN manages backup and recovery operations, it requires a place to store necessary
information about the database. RMAN always stores this information in the target database control
file. You can also store RMAN metadata in a recovery catalog schema contained in a separate
database. The recovery catalog
schema must be stored in a database other than the target database.
6. What does complete RMAN backup consist of ?
A backup of all or part of your database. This results from issuing an RMAN backup command. A
backup consists of one or more backup sets.
7. What is a Backup set?
A logical grouping of backup files -- the backup pieces -- that are created when you issue an RMAN
backup command. A backup set is RMAN's name for a collection of files associated with a backup. A
backup set is composed of one or more backup pieces.
8. What is a Backup piece?
A physical binary file created by RMAN during a backup. Backup pieces are written to your backup
medium, whether to disk or tape. They contain blocks from the target database's datafiles, archived
redo log files, and control files. When RMAN constructs a backup piece from datafiles, there are a
several rules that it follows:
 A datafile cannot span backup sets
 A datafile can span backup pieces as long as it stays within one backup set
 Datafiles and control files can coexist in the same backup sets
 Archived redo log files are never in the same backup set as datafiles or control files RMAN is the
only tool that can operate on backup pieces. If you need to restore a file from an RMAN backup, you
must use RMAN to do it. There's no way for you to manually reconstruct database files from the
backup pieces. You must use RMAN to restore files from a backup piece.
9. What are the benefits of using RMAN?

235

ORACLE BACKUP STRATEGIES
1. Incremental backups that only copy data blocks that have changed since the last backup.
2. Tablespaces are not put in backup mode, thus there is noextra redo log generation during online
backups.
3. Detection of corrupt blocks during backups.
4. Parallelization of I/O operations.
5. Automatic logging of all backup and recovery operations.
6. Built-in reporting and listing commands.
10. RMAN Restore Preview
The PREVIEW option of the RESTORE command allows you to identify the backups required to
complete a specific restore operation. The output generated by the command is in the same format as
the LIST command. In addition the PREVIEW SUMMARY command can be used to produce a summary
report with the same format as the LIST SUMMARY command. The following examples show how these
commands are used:
# Spool output to a log file
SPOOL LOG TO c:\oracle\rmancmd\restorepreview.lst;
# Show what files will be used to restore the SYSTEM tablespace’s datafile
RESTORE DATAFILE 2 PREVIEW;
# Show what files will be used to restore a specific tablespace
RESTORE TABLESPACE users PREVIEW;
# Show a summary for a full database restore
RESTORE DATABASE PREVIEW SUMMARY;
# Close the log file
SPOOL LOG OFF;
11. Where should the catalog be created?
The recovery catalog to be used by rman should be created in a separate database other than the
target database. The reason been that the target database will be shutdown while datafiles are
restored.
12. How many times does oracle ask before dropping a catalog?
The default is two times one for the actual command, the other for confirmation.
13. How to view the current defaults for the database.
RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘%F’; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
‘/u02/app/oracle/product/10.1.0/db_1/dbs/snapcf_test.f’; # default
14. Backup the database.
run
{
backup incremental level $level ${level_keyword}
tag INC${target_db}_$level database include current controlfile;
backup archivelog all not backed up 1 times delete input;
}
15. How to resolve the ora-19804 error
Basically this error is because of flash recovery area been full. One way to solve is to increase the
space available for flashback database.
sql>ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=5G; –It can be set to K,M or G.
rman>backup database;
……………….
channel ORA_DISK_1: specifying datafile(s) in backupset
including current controlfile in backupset

236

ORACLE BACKUP STRATEGIES
including current SPFILE in backupset
channel ORA_DISK_1: starting piece 1 at 04-JUL-05
channel ORA_DISK_1: finished piece 1 at 04-JUL-05
piece
handle=/u02/app/oracle/flash_recovery_area/TEST/backupset/2005_07_04/o1_mf_ncsnf_TAG200507
04T205840_1dmy15cr_.bkp comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 04-JUL-05
Oracle Flashback
After taking a back up resync the database.
Restoring the whole database.
run {
shutdown immediate;
startup mount;
restore database;
recover database;
alter database open;
}
16. What are the various reports available with RMAN
rman>list backup;
rman> list archive;
17. What does backup incremental level=0 database do?
Backup database level=0 is a full backup of the database. rman>>backup incremental level=0
database;
You can also use backup full database; which means the same thing as level=0;
18. What is the difference between DELETE INPUT and DELETE ALL command in backup?
Generally speaking LOG_ARCHIVE_DEST_n points to two disk drive locations where we archive the
files, when a command is issued through rman to backup archivelogs it uses one of the location to
backup the data. When we specify delete input the location which was backedup will get deleted, if we
specify delete all all log_archive_dest_n will get deleted.
DELETE all applies only to archived logs. delete expired archivelog all;
19. How do I backup archive log?
In order to backup archivelog we have to do the following:run
{
allocate channel t1 type 'SBT_TAPE';
delete noprompt archivelog until time = 'sysdate-3/24';
delete noprompt obsolete;
release channel t1;
}
20. How do I do a incremental backup after a base backup?
run
{
backup incremental level $level ${level_keyword}
tag INC${target_db}_$level database include current controlfile;
backup archivelog all not backed up 1 times delete input;
}
21. In catalog database, if some of the blocks are corrupted due to system crash, How will
you recover?
using RMAN BLOCK RECOVER command
22. You have taken a manual backup of a datafile using o/s. How RMAN will know about it?
You have to catalog that manual backup in RMAN's repository by command
RMAN> catalog datafilecopy '/DB01/BACKUP/users01.dbf';
restrictions:
> Accessible on disk
> A complete image copy of a single file

237

ORACLE BACKUP STRATEGIES

23. Where RMAN keeps information of backups if you are using RMAN without Catalog?
RMAN keeps information of backups in the control file.
CATALOG vs NOCATALOG
the difference is only who maintains the backup records like when is the last successful backup
incremental differential etc.
In CATALOG mode another database (TARGET database) stores all the information.
In NOCATALOG mode controlfile of Target database is responsible.
24. How do you see information about backups in RMAN?
RMAN> List Backup;
Use this SQL to check
SQL> SELECT sid totalwork sofar FROM v$session_longops WHERE sid 153;
Here give SID when back start it will show SID
25. How RMAN improves backup time?
RMAN backup time consumption is very less than compared to regular online backup as RMAN copies
only modified blocks
26. What is the advantage of RMAN utility?
Central Repository
Incremental Backup
Corruption Detection
Advantage over tradition backup system:
1). copies only the filled blocks i.e. even if 1000 blocks is allocated to datafile but 500 are filled with
data then RMAN will only create a backup for that 500 filled blocks.
2). incremental and accumulative backup.
3). catalog and no catalog option.
4). detection of corrupted blocks during backup;
5). can create and store the backup and recover scripts.
6). increase performance through automatic parallelization( allocating channels) less redo generation.
27. List the encryption options available with RMAN?
RMAN offers three encryption modes: transparent mode, password mode and dual mode.
28. What are the steps required to perform in $ORACLE_HOME for enabling the RMAN
backups with netbackup or TSM tape library software?
I can explain what are all the steps to take a rman backup with TSM tape library as follows
1.Install TDPO (default path /usr/tivoli/tsm/client/oracle/)
2.Once u installed the TDPO automatically one link is created from TDPO directory to /usr/lib.Now we
need to Create soft link between OS to ORACLE_HOME
ln -s /usr/lib/libiobk64.a $ORACLE_HOME/lib/libobk.a(very imporatant)
3.Uncomment and Modify tdpo.opt file which in
/usr/tivoli/tsm/client/oracle/bin/tdpo.opt as follows
DSMI_ORC_CONFIG /usr/Tivoli/tsm/client/oracle/bin64/dsm.opt
DSMI_LOG /home/tmp/oracle
TDPO_NODE backup
TDPO_PSWDPATH /usr/tivoli/tsm/client/oracle/bin64
4.create dsm.sys file in same path and add the entries
SErvername <Server name >
TCPPort 1500
passwordacess prompt
nodename backup
enablelanfree yes
TCPSERVERADDRESS <Server Address>
5.Create dsm.opt file add an entry
SErvername <Server name >
6.Then take backup
RMAN>run

238

ORACLE BACKUP STRATEGIES
{
allocate channel t1 type 'sbt_tape' parms
'ENV (TDPO_OPTFILE /usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';
backup database include current controlfile;
release channel t1;
}
29. What is the significance of incarnation and DBID in the RMAN backups?
When you have multiple databases you have to set your DBID (Database Id) which is unique to each
database. You have to set this before you do any restore operation from RMAN.
There is possibility that incarnation may be different of your database. So it is advised to reset to
match with the current incarnation. If you run the RMAN command ALTER DATABASE OPEN
RESETLOGS then RMAN resets the
target database automatically so that you do not have to run RESET DATABASE. By resetting the
database RMAN considers the new incarnation as the current incarnation of the database.
30. List at least 6 advantages of RMAN backups compare to traditional hot backups?
RMAN has the following advantages over Traditional backups:
1. Ability to perform INCREMENTAL backups
2. Ability to Recover one block of datafile
3. Ability to automatically backup CONTROLFILE and SPFILE
4. Ability to delete the older ARCHIVE REDOLOG files, with the new one's automatically.
5. Ability to perform backup and restore with parallelism.
6. Ability to report the files needed for the backup.
7. Ability to RESTART the failed backup, without starting from beginning.
8. Much faster when compared to other TRADITIONAL backup strategies.
31. How do you enable the autobackup for the controlfile using RMAN?
issue command at rman prompt.....
RMAN> configure controlfile autobackup on;
also we can configure controlfile backup format......
RMAN> configure controlfile autobackup format for device type disk to
2> '$HOME/BACKUP/RMAN/ F.bkp';
$HOME/BACKUP/RMAN/ this can be any desired location.
32. How do you identify what are the all the target databases that are being backed-up with
RMAN database?
You don’t have any view to identify whether it is backed up or not . The only option is connect to the
target database and give list backup this will give you the backup information with date and timing.
33. What is the difference between cumulative incremental and differential incremental
backups?
Differential backup: This is the default type of incremental backup which backs up all blocks
changed after the most recent backup at level n or lower.
Cumulative backup: Backup all blocks changed after the most recent backup at level n-1 or lower.
34. How do you identify the block corruption in RMAN database? How do you fix it?
using v$block_corruption view u can find which blocks corrupted.
Rman>> block recover datafile <fileid> block <blockid>;
Using the above statement u recover the corrupted blocks.
First check whether the block is corrupted or not by using this command
sql>select file# block# from v$database_block_corruption;
file# block
2 507
the above block is corrupted...
conn to Rman
To recover the block use this command...
Rman>blockrecover dataile 2 block 507;
the above command recover the block 507

239

ORACLE BACKUP STRATEGIES
Now just verify it.....
Rman>blockrecover corruption list;
35. How do you clone the database using RMAN software? Give brief steps? When do you
use crosscheck command?
Check whether backup pieces proxy copies or disk copies still exist.
Two commands available in RMAN to clone database:
1) Duplicate
2) Restore.
36. What is the difference between obsolete RMAN backups and expired RMAN backups?
The term obsolete does not mean the same as expired. In short obsolete means "not needed "
whereas expired means "not found."
37. List some of the RMAN catalog view names which contain the catalog information?
RC_DATABASE_INCARNATION RC_BACKUP_COPY_DETAILS
RC_BACKUP_CORRUPTION
RC_BACKUP-DATAFILE_SUMMARY to name a few
38. What is db_recovery_file_dest ? When do you need to set this value?
If Database Flashback option is on then use this option.
39. How do you setup the RMAN tape backups?
RMAN Target /
run
{
Allocate channel ch1 device type sbt_tape maxpiecesize 4g
Format' D_ U_ T_ t';
sql 'alter system switch logfile';
Backup database;
backup archivelog from time 'sysdate-7';
Backup Format ' D_CTLFILE_P_ U_ T_ t' Current controlfile;
release channel ch1;
}
This is backup script for Tivoli Backup Server
40. How do you install the RMAN recovery catalog?
Steps to be followed:
1) Create connection string at catalog database.
2) At catalog database create one new user or use existing user and give that user a
recovery_catalog_owner privilege.
3)Login into RMAN with connection string
a) export ORACLE_SID
b) rman target catalog @connection string
4) rman> create catalog;
5) register database;
41. When do you recommend hot backup? What are the pre-reqs?
Database must be Archivelog Mode
Archive Destination must be set and LOG_ARCHIVE_START TRUE (EARLIER VERSION BEFORE 10G)
If you go through RMAN then
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'/u01/oracle/autobackup/ F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 2BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

240

ORACLE BACKUP STRATEGIES
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/u01/app/oracle/product/10.2.0/db_2/dbs/snapcf_dba.f'; # default
42. What is the difference between physical and logical backups?
In Oracle Logical Backup is "which is taken using either Traditional Export/Import or Latest Data
Pump". Where as Physical backup is known "when you take Physical O/s Database related Files as
Backup".
43. What is RAID? What is RAID0? What is RAID1? What is RAID 10?
RAID: It is a redundant array of independent disk
RAID0: Concatenation and stripping
RAID1: Mirroring
44. What are things which play major role in designing the backup strategy?
I Believe in designing a good backup strategy it will not only be simply backup but also a contingency
plan. In this case you should consider the following:
1. How long is the allowable down time during recovery? - If short you could consider using
dataguard.
2. How long is the backup period? - If short I would advise to use RMAN instead of user managed
backup.
3. If limited disk space for backup never use user managed backup.
4. If the database is large you could consider doing full rman backups on a weekend and do a
incremental backup on a weekday.
5. Schedule your backup on the time where there is least database activity this is to avoid resource
huggling.
6. Backup script should always be automized via scheduled jobs. This way operators would never miss
a backup period.
7. Retention period should also be considered. Try keeping atleast 2 full backups. (current and
previous backup).
Cold backup: shutdown the database and copy the datafiles with the help of
O.S. command. this is simply copying of datafiles just like any other text file copy.
Hot backup: backup process starts even though database in running. The process to take a hot backup
is
1) sql> alter database begin backup;
2) copy the datafiles.
3) after copying
sql> alter database end backup;
Begin backup clause will generate the timestamp. it'll be used in backup consistency i.e. when begin
backup pressed it'll generate the timestamp. During restore database will restore the data from
backup till that timestamp and remaining backup will be recovered from archive log.
45. What is hot backup and what is cold backup?
Hot backup when the database is online cold backup is taken during shut down period
46. How do you test that your recovery was successful?
SQL> SELECT count(*) FROM flashback_table;
47. How do you backup the Flash Recovery Area?
A:RMAN> BACKUP RECOVERY FILES;
The files on disk that have not previously been backed up will be backed up. They are full and
incremental backup sets, control file auto-backups, archive logs and datafile copies.
48. How to enable Fast Incremental Backup to backup only those data blocks that have
changed?

241

ORACLE BACKUP STRATEGIES
A:SQL> ALTER DATABASE enable BLOCK CHANGE TRACKING;
49. How do you set the flash recovery area?
A:SQL> ALTER SYSTEM SET db_recovery_file_dest_size = 100G;SQL> ALTER SYSTEM SET
db_recovery_file_dest =‘/u10/oradata/school’;
50. How can you use the CURRENT_SCN column in the V$DATABASE view to obtain the
currentSCN?
A:SQL> SELECT current_scn FROM v$database;
51. You have taken a manual backup of a datafile using o/s. How RMAN will know about it?
You have to catalog that manual backup in RMAN's repository by command
RMAN> catalogdatafilecopy '/DB01/BACKUP/users01.dbf';
restrictions:> Accessible on disk> A complete image copyof a single file
52. In catalog database, if some of the blocks are corrupted due to system crash, How will
you recover?
using RMAN BLOCK RECOVER command
53. List advantages of RMAN backups compare to traditional hot backups?
RMAN has the following advantages over Traditional backups:
1. Ability to perform INCREMENTALbackups
2. Ability to Recover one block of datafile
3. Ability to automatically backup CONTROLFILEand SPFILE
4. Ability to delete the older ARCHIVE REDOLOG files
54. How do you identify the expired, active, obsolete backups? Which RMAN command you
use?
Use command:
Rman > crosscheck backup;
Rman > crosscheck archivelog all;
Rman > listbackup;
Rman > list archive logall
55. How do you enable the autobackup for the controlfile using RMAN?
RMAN> configure controlfile autobackup on;
also we can configurecontrolfile backup format......
RMAN> configure control file auto backup format for device type disk
56. How do you identify what are the all the target databases that are being backed-up with
RMAN database?
You don’t have any view to identify whether it is backed up or not . The only option is connect to the
target database and give list backup, this will give you the backup information with date and timing
57. What is the difference between cumulative incremental and differential incremental
backups?
Differential backup: This is the default type of incremental backup which backs up all blocks changed
after the most recent backup at level n or lower.
Cumulative backup: Backup all blocks changed after the most recent backup at level n-1 or lower
58. Explain how to setup the physical stand by database with RMAN?
$ Export ORACLE_SID=TEST $ rman target /
RMAN> show all;
Using target database controlfile instead of recovery catalog RMAN configuration parameters are:
CONFIGURE RETENTIONPOLICY TO RECOVERY WINDOW OF 1 DAYS;
CONFIGURE BACKUP OPTIMIZATION
59. What is auxiliary channel in RMAN? When do you need this?

242

ORACLE BACKUP STRATEGIES
An auxiliary channel is a link to auxiliary instance. If you do not have automatic channels configured,
then before issuing the DUPLICATE command, manually allocate at least one auxiliary channel with in
the same RUN command.
60. What is backup set?
RMAN can also store its backups in an RMAN-exclusive format which is called backup set. A backupset
is a collection of backup pieces, each of which may contain one or more datafile backups
61. What is RMAN and how does one use it?
Recovery Manager (or RMAN) is an Oracle provided utility for backing-up, restoring and
recoveringOracle Databases. RMAN ships with the database server and doesn't require a separate
installation. TheRMAN executable is located in your ORACLE_HOME/bin directory.
62. What kind of backup are supported by RMAN?
Backup SetsDatafiles CopiesOS BackupWhat is the Flash Recovery Area?
A: It is a unified storage location for all recovery-related files and activities in an Oracle Database.
Itincludes Control File, Archived Log Files, Flashback Logs, Control File Autobackups, Data Files,
andRMAN files.
63. How do you define a Flash Recovery Area?
A: To define a Flash Recovery Area set the following Oracle Initialization Parameters.
SQL> ALTER SYSTEM SET db_recovery_file_dest_size = 100G;
SQL> ALTER SYSTEM SET db_recovery_file_dest = ‘/u10/oradata/school’;
64. How do you use the V$RECOVERY_FILE_DEST view to display information regarding the
flashrecovery area?
A:SQL> SELECT name, space_limit, space_used,space_reclaimable, number_of_filesFROM
v$recovery_file_dest;
65. How can you display warning messages?
A:SQL> SELECT object_type, message_type,message_level, reason, suggested_actionFROM
dba_outstanding_alerts;
66. How to use the best practice to use Oracle Managed File (OMF) to let Oracle database to
create andmanage the underlying operating system files of a database?
A:SQL> ALTER SYSTEM SETdb_create_file_dest = ‘/u03/oradata/school’;
SQL> ALTER SYSTEM SETdb_create_online_dest_1 = ‘/u04/oradata/school’;
67. How to enable Fast Incremental Backup to backup only those data blocks that have
changed?
A:SQL> ALTER DATABASE enable BLOCK CHANGE TRACKING;
68. How do you monitor block change tracking?
A:SQL> SELECT filename, status, bytes FROM v$block_change_tracking;
It shows where the block change-tracking file is located, the status of it and the size.
69. How do you use the V$BACKUP_DATAFILE view to display how effective the block
change trackingis in minimizing the incremental backup I/O?
A:SQL> SELECT file#, AVG(datafile_blocks), AVG(blocks_read),AVG (blocks_read/datafile_blocks),
AVG(blocks)FROM v$backup_datafileWHERE used_change_tracking = ‘YES’ AND incremental_level >
0GROUP BY file#;If the AVG (blocks_read/datafile_blocks) column is high then you may have to
decrease the timebetween the incremental backups.
70. How do you backup the entire database?
A:RMAN> BACKUP DATABASE;
71. How do you backup an individual tablespaces?
A:RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;
RMAN> BACKUP TABLESPACE system;

243

ORACLE BACKUP STRATEGIES

72. How do you backup datafiles and control files?
A:RMAN> BACKUP DATAFILE 3;
RMAN> BACKUP CURRENT CONTROLFILE;
Use a fast recovery without restoring all backups from their backup location to the location specified
inthe controlfile.
A:RMAN> SWITCH DATABASE TO COPY;
73. RMAN will adjust the control file so that the data files point to the backup file location
and then starts recovery.Why use Rman ?
A. 1. No Extra Costs.. It is available free.
2.RMAN introduced in Oracle 8 it has become simpler with new version and easier that user managed
backups.
3.Proper Security
4.You are 100% sure your database has been backed up .
5.It contains details of backup taken in the central repository
6.Facility of Testing validity of backups also command like cross check to checkthe status of backup.
7.Oracle 10g has got further optimized incremental backups with has resulted inimprovement of
performance during backup
8.and recovery time
9.Parrallel operation are supported
10.Better Querying facility for knowing different details of backup.
11.No Extra redo generated when backup is taken. compared to online backup
12.Without rman.which results in saving of space in hard disk.
13.RMAN is an intelligent tool
14.Maintains repository of backup metadata.
15.Remembers backup locations
16.Knows what needs backup set locations
17.Knows what needs to be backed up
18.Knows what is required for recovery
19.Know what backups are redundant
20.It handles database corruptions
74. Oracle Enhancement for Rman in 10g
A. 1.Flash Recovery Area
2.Incrementally Updated Backups
3.Faster Incremental Backups
4.SWITCH DATABASE COMMAND.
5.Binary Compression
6.Global Scripting
7.Duration Clause
8.Configure This
9.Oracle Enhancement for Rman in 10g
10.Automatic Channel Failover
11.Compress Backup Sets
12.Recovery Through Reset Logs
13.Cross Backup Sets
75. Global Scripting
A.RMAN> print script full_backup to file 'my_script_file.txt'
Oracle Database 10g provides a new concept of global scripts, which you can executeagainst any
database registered in the recovery catalog, as long as your RMAN client isconnected to the recovery
catalog and a target database simultaneously.CPISOLUTION.COM
RMAN> create global script global_full_backup
76. Outline the steps for recovery of missing data file?
Losing Datafiles Whenever you are in NoArchivelog Mode:
###################################################

244

ORACLE BACKUP STRATEGIES
If you are in noarchivelog mode and you loss any datafile then whether it is temporary or permanent
media failure, the database will automatically shut down. If failure is temporary then correct the
underline hardware and start the database. Usually crash recovery will perform recovery of the
committed transaction of the database from online redo log files. If you have permanent media failure
then restore a whole database from a good backup. How to restore a database is as follows:
If a media failure damages datafiles in a NOARCHIVELOG database, then the only option for recovery
is usually to restore a consistent whole database backup. As you are in noarchivelog mode so you
have to understand that changes after taken backup is lost.
If you logical backup that is export file you can import that also.
In order to recover database in noarchivelog mode you have to follow the following procedure.
1)If the database is open shutdown it.
SQL>SHUTDOWN IMMEDIATE;
2)If possible, correct the media problem so that the backup database files can be restored to their
original locations.
3)Copy all of the backup control files, datafiles to the default location if you corrected media failure.
However you can restore to another location. Remember that all of the files not only the damaged
files.
4)Because online redo logs are not backed up, you cannot restore them with the datafiles and control
files. In order to allow the database to reset the online redo logs, you must have to do incomplete
recovery:
RECOVER DATABASE UNTIL CANCEL
CANCEL
5)Open the database in RESETLOGS mode:
ALTER DATABASE OPEN RESETLOGS;
In order to rename your control files or in case of media damage you can copy it to another location
and then by setting (if spfile)
STARTUP NOMOUNT
alter system set
control_files='+ORQ/orq1/controlfile/control01.ctl','+ORQ/orq1/controlfile/control02.ctl'
scope=spfile;
STARTUP FORCE MOUNT;
In order to rename data files or online redo log files first copy it to new location and then point control
file to new location by,
ALTER DATABASE RENAME FILE '+ORQ/orq1/datafile/system01.dbf';'
TO '+ORQ/orq1/datafile/system02.dbf';
Losing Datafiles Whenever you are in Archivelog Mode:
###################################################
If the datafile that is lost is under SYSTEM tablespace or if it is a datafile contain active undo segments
then database shuts down. If the failure is temporary then correct the underline hardware and start
the database. Usually crash recovery will perform recovery of the committed transaction of the
database from online redo log files.
If the datafile that is lost in not under SYSTEM tablespace and not contain active undo segments then
the affected datafile is gone to offline. The database remains open. In order to fix the problem take
the affected tablespace offline and then recover the tablespace.
77. Outline the steps for recovery with missing online redo logs?

245

ORACLE BACKUP STRATEGIES
Redo log is CURRENT (DB was shut down cleanly)
If the CURRENT redo log is lost and if the DB is closed consistently, OPEN RESETLOGS can be issued
directly without any transaction loss. It is advisable to take a full backup of DB immediately after
the STARTUP.
Redo log is CURRENT (DB was not shut down cleanly)
When a current redo log is lost, the transactions in the log file are also lost before making to archived
logs. Since a DB startup can no more perform a crash recovery (since all the now-available online log
files are not sufficient to startup the DB in consistent state), an incomplete media recovery is the only
option. We will need to restore the DB from a previous backup and restore to the point just before the
lost redo log file. The DB will need to be opened inRESETLOGS mode. There is some transaction loss in
this scenario.
RMAN> RESTORE CONTROLFILE FROM '<backup tag location>';
RMAN> ALTER DATABASE MOUNT;
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE UNTIL TIME "to_date('MAR 05 2009 19:00:00','MON DD YYYY
HH24:MI:SS')";
RMAN> ALTER DATABASE OPEN RESETLOGS;
78. Outline steps for recovery with missing archived redo logs?
If a redo log file is already archived, its loss can safely be ignored. Since all the changes in the DB are
now archived and the online log file is only waiting for its turn to be re-written by LGWR (redo log files
are written circularly) the loss of the redo log file doesnt matter much. It may be re-created using the
command
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP <group#>;
This will re-create all groups and no transactions are lost. The database can be opened normally after
this.
79. What is FRA ? When do you use this ?
Flash recovery area where you can store not only the traditional components found in a backup
strategy such as control files, archived log files, and Recovery Manager (RMAN) datafile copies but also
a number of other file
components such as flashback logs. The flash recovery area simplifies backup operations, and it
increases the availability of the database because many backup and recovery operations using the
flash recovery area can be performed when the database is open and available to users.
Because the space in the flash recovery area is limited by the initialization parameter DB_
RECOVERY_FILE_DEST_SIZE , the Oracle database keeps track of which files are no longer needed on
disk so that they can be deleted when there is not enough free space for new files. Each time a file is
deleted from the flash recovery area, a message is written to the alert log.
A message is written to the alert log in other circumstances. If no files can be deleted, and the
recovery area used space is at 85 percent, a warning message is issued. When the space used is at 97
percent, a critical warning is
issued. These warnings are recorded in the alert log file, are viewable in the data dictionary view
DBA_OUTSTANDING_ALERTS , and are available to you on the main page of the EM Database Control
80. What is Channel? How do you enable the parallel backups with RMAN?
Channel is a link that RMAN requires to link to target database. This link is required when backup and
recovery operations are performed and recorded. This channel can be allocated manually or can be
preconfigured by using
automatic channel allocation.
The number of allocated channels determines the maximum degree of parallelism that is used during
backup, restore or recovery. For example, if you allocate 4 channels for a backup operation, 4
background processes for the operation can run concurrently.
Parallelization of backup sets allocates multiple channels and assigns files to specific channels. You can
configure parallel backups by setting a PARALLELISM option of the CONFIGURE command to a value

246

ORACLE BACKUP STRATEGIES
greater than 1 or by
manually allocating multiple channels.
RMAN> CONFIGURE DEVICE TYPE PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET;
81. What are RTO, MTBF, and MTTR?
RTO: Recovery Time objective-is the maximum amount of time that the database can be unavailable
and still stasfy SLA's
MTBF (Meant tiem Between Failure)MTTR (Mean tie to recover)- fast recovery solutions
82. How do you enable the encryption for RMAN backups?
If you wish to modify your existing backup environment so that all RMAN backups are encrypted,
perform the following steps:
· Set up the Oracle Encryption Wallet
· Issue the following RMAN command:
RMAN> CONFIGURE ENCRYPTION ALGORITHM 'AES256'; -- use 256 bit encryption
RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON; -- encrypt backups
83. What is the difference between restoring and recovering?
Restoring involves copying backup files from secondary storage (backup media) to disk. This can be
done to replace damaged files or to copy/move a database to a new location.
Recovery is the process of applying redo logs to the database to roll it forward. One can roll-forward
until a specific point-in-time (before the disaster occurred), or roll-forward until the last transaction
recorded in the log files.
SQL> connect SYS as SYSDBA
SQL> RECOVER DATABASE UNTIL TIME '2001-03-06:16:00:00' USING BACKUP CONTROLFILE;
RMAN> run {
set until time to_date('04-Aug-2004 00:00:00', 'DD-MON-YYYY HH24:MI:SS');
restore database;
recover database;
}
What are the various tape backup solutions available in the market?
How do you generate the begin backup script?
Outline the steps for recovering the full database from cold backup?
Explain the steps to perform the point in time recovery with a backup which is taken before
the resetlogs of the db?
Outline the steps involved in TIME based recovery from the full database from hot backup?
Is it possible to take Catalog Database Backup using RMAN? If Yes, How?
Can a schema be restored in oracle 9i RMAN when the schema having numerous table
spaces?
Outline the steps for changing the DBID in a cloned environment?
How do you identify the expired, active, obsolete backups? Which RMAN command you use?
Explain how to setup the physical stand by database with RMAN?
List the steps required to enable the RMAN backup for a target database?
How do you verify the integrity of the image copy in RMAN environment?
Outline the steps involved in SCN based recovery from the full database from hot backup?
Outline the steps involved in CANCEL based recovery from the full database from hot
backup?
Outline the steps involved in TIME based recovery from the full database from hot backup?
Is it possible to specific tables when using RMAN DUPLICATE feature? If yes, how?
Explain the steps to perform the point in time recovery with a backup which is taken before
the resetlogs of the db?
Outline the steps for recovering the full database from cold backup?
How do you generate the begin backup script?

247

ORACLE BACKUP STRATEGIES

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close