ABSTRACT
Oracle Recovery Manager (Oracle RMAN) has been a feature in the Oracle Database since version 8.0, ever
since then it has grown into a robust method to backup and recover your database. But with the life of DBA being ever
present in performance issues, user requests and even non related database situations like meetings, a backup is normally
setup but, more often than not, it is forgotten to test out what would happen if a disaster would happen and what would
you do. This paper will illustrate how to setup a proper RMAN backup configuration and real life RMAN disaster
recovery scenarios so that if you are ever faced with this adversity you come out on top.
TARGET AUDIENCE
This paper will be beneficial for anyone who is beginning to use Oracles Recovery Manager and for those who
are already using it, but want to understand the intricacies of how a configuration setup can hurt your recovery of your
database.
EXECUTIVE SUMMARY
Learner will be able to:
Gain insights into Oracle RMAN setup that can minimize the possibility of error during recovery
Provide examples how these skills can help you solve a real life disaster
About 40% say they experienced, in total, one day or more of unplanned outage last year
44% have active efforts underway to mitigate their levels of unexpected downtime
18% report that their organizations conduct no disaster recovery plan. While 37% conduct a DRP for some types/
areas of data.
34% estimate that they would need more than a business day (exceeding eight hours) to have everything up and
running in case of a disaster.
One point that stands out to me, is that 34% of the people surveyed said that they would need more that a business
day to have their data available, and with the ever increasing need for data to be available 24/7, this is a real impact on the
profits and necessities of your organization.
But now the question that comes into mind is, what if you can reduce that time, by just having the right understanding
on how Oracles Recovery Manager (RMAN) works, this can and will help you out in reducing your meant time to
recover.
1
Session # 196
The first thing that we have to do, is understand what RMAN is and how RMAN works. Recovery Manager or better
known as RMAN, is an Oracle client utility that is installed with the Enterprise or Standard edition, you can also find it
with the Admin option when installing the Oracle Client.
In it's most basic form, the RMAN client connects, an it needs to be with a "sysdba" privileged user, to the database
that is being backed up, called a TARGET database, this client, is an executable that is normally found in
$ORACLE_HOME/bin.
By being a client side utility, it allows you to use one RMAN executable version to backup current and previous
versions of the Oracle Database; there are some restrictions to this though, which can be verified in MOS document
RMAN Compatibility Matrix [ID 73431.1].
This RMAN executable uses a file called recover.bsq, this file is located in $ORACLE_HOME/rdbms/admin ,
basically what the executable does, is to interpret the commands you give it , direct server sessions to execute those
commands, and record its activity in the TARGET database control file that is being backed up.
There are two main SYS packages that do the work of backup and recovery, which are DBMS_RCVMAN, this has
the procedures which list your database incarnations, the set until time recovery window, list your backups, to name a
few, and DBMS_BACKUP_RESTORE , which as you might have guessed is the one who does the backup and recovery
operations, like create the control file snapshot , backup the datafiles , backup the spfile to name some.
As mentioned above, the way that the RMAN client directs the server sessions to execute the commands are through
channels, a channel represents one stream of data to a device, and corresponds to one database server session. The
channel reads data into PGA memory, processes it, and writes it to the output device.
The work of each channel, whether of type disk or System Backup Tape (SBT), is subdivided into the following
distinct phases:
Read Phase
A channel reads blocks from disk into input I/O buffers. The allocation of these buffers depends on the number of
datafiles being read simultaneously from disk and written to the same backup piece. One way to control the numbers
of files is the backup parameter FILESPERSET
Copy Phase
A channel copies blocks from input buffers to output buffers and performs additional processing on the blocks,
like the validation of the data blocks, as it verifies that it's not backing up corrupt data blocks, it's also the phase
where it does the binary compression and the backup encryption
Write Phase
A channel writes the blocks from output buffers to storage media. The write phase can be either to SBT or to
disk, and these are mutually exclusive, meaning you write to one or the other, not both.
As you can see by the phases above, and what distinguishes RMAN from any other method, is that the backup is at
the block level, as to the user managed backups, it brings great advantages, as it wont have to backup empty blocks.
When you decide to write to SBT, Oracle uses its Media Manager Layer (MML) to allow RMAN to
communicate with 3rd party vendors and write the resulting backup piece to the sequential media device. Oracle uses a
library, which is really a symbolic link to the actual 3rd party media manager, located in $ORACLE_HOME/lib, called
libobk.so (orasbt.dll in Windows), for example if you were to setup Oracle RMAN 11.2.0.3 in RHEL 5 64-bit version
with Veritas Netbackup, you would have to do the following:
cd $ORACLE_HOME/lib
mv libobk.so libobk.so.orig
Session # 196
ln -s /<install_path>/netbackup/bin/libobk.so64 libobk.so
Establishing this link only enables RMAN to be able to pass commands to the MML and this one will interact
with the media manager, but for you to be able to complete a backup to SBT, you have to establish the necessary
parameters in the channel allocation, with the PARMS parameter.
This is vendor specific, so you will see, as an example, for Veritas Netbackup you have parameters like
NB_ORA_SERV, NB_ORA_CLIENT, NB_ORA_POLICY, and for Tivoli Storage Manager you specify a file called
tdpo.opt through the parameter TDPO_OPTFILE, in which you set the appropriate settings for this vendor media
manager.
As you can see below, the specification of the PARMS parameter is done when you either ALLOCATE
CHANNEL or CONFIGURE CHANNEL.
RMAN> run
2> {
3> ALLOCATE CHANNEL CH1 DEVICE TYPE 'SBT_TAPE'
PARMS'SBT_LIBRARY=<NBU_install_path>/netbackup/bin/libobk.so64,ENV=(NB_ORA_SERV = MASTER_SERVER,
4> NB_ORA_POLICY=5week,NB_ORA_CLIENT=CLIENT_SERVER)' format '%d_TAPE_%I_%s_%T_%t';
5> backup backupset all;
6> }
using target database control file instead of recovery catalog
allocated channel: CH1
channel CH1: SID=58 instance=TESTDB1 device type=SBT_TAPE
channel CH1: Veritas NetBackup for Oracle - Release 6.5 (2010042404)
Data files
Control files
But lets say a full on disaster were to happen, in which not only you lose your database, you lose your site or
your server, you need some additional files are needed so that you can have your data available as soon as possible:
ORACLE_HOME/GRID_HOME1
These additional files are not critical in RMAN to be backed up, but are very important in case a full disaster
were to occur, as if you were not to have a backup of these, you would need to rebuild your ORACLE_HOME /
GRID_HOME from scratch, taking you more time to have the data available to your client.
These files are not backed up with Oracles RMAN utility, you need to use a distinct method to back up these types of files.
Session # 196
A DISK
16-FEB-2013 04:55:14 1
NO
TAG20130216T045452
A DISK
16-FEB-2013 05:02:07 1
YES
FULL_BACKUP
A DISK
16-FEB-2013 05:02:27 1
YES
ARCH_BACKUP
A DISK
16-FEB-2013 05:02:44 1
NO
CTL_BACKUP
A DISK
16-FEB-2013 05:02:56 1
NO
TAG20130216T050247
A separate version of a database. The incarnation of the database changes when you open it with the RESETLOGS option, but you can recover backups from
a prior incarnation as long as the necessary redo is available.
Session # 196
DB ID
STATUS
Reset SCN
Reset Time
TESTDB
2590844408
PARENT
735231
16-FEB-2013 04:53:05
TESTDB
2590844408
CURRENT 737037
16-FEB-2013 05:05:47
A DISK
16-FEB-2013 05:08:00 1
NO
TAG20130216T050739
Session # 196
User created.
TESTDB1> GRANT connect, resource, recovery_catalog_owner TO cat_user;
Grant succeeded.
oracle@servidor1.localdomain [TESTDB1] /home/oracle/Desktop
oracle $ rman catalog=cat_user/cat_user_password
RMAN> CREATE CATALOG;
recovery catalog created
ii. Cumulative incremental backup. - Backs up all blocks changed after the most recent
incremental backup at level 0.
Session # 196
4. Value of CONTROL_FILE_RECORD_TIME_KEEP
Consider the minimum time you require to have information in your Recovery Catalog, if you were to set
it to a lower value, you can lose the capacity to recover your database to the desired time.
5. Set NLS parameters accordingly
Make sure your environment variables are set accordingly to the values of V$NLS_PARAMETERS in
your database.
6. Image Copy or Backupset output
a. Image copy is an exact copy of a data file, control file or archived redo log, with this type of
backup, you will have to use an external method of compression if you want to reduce the size of
the backup.
b. Backupset
A backupset is the smallest unit of an RMAN backup and it is the only form in which RMAN can
write backups to SBT. When using a backupset as your output method you can also configure
them to be:
i. Compressed
Which all but the BASIC option requires the Advanced Compression Option enabled
1. BASIC. - This does not require the Advanced Compression Option
2. LOW. - Least effect on backup throughput.
3. MEDIUM. - Recommended for most environments. Good combination of
compression ratios and speed
4. HIGH. - Best suited for backups over slower networks where the limiting factor
is network speed.
ii. Encrypted
1. Transparent. - Default mode if using encryption and uses Oracle Encryption
Wallet
2. Password-protected. - This mode uses only password protection. You must
provide a password when creating and restoring encrypted backups
3. Dual-mode. - This mode requires either the wallet or a password
You can also control them to be of a certain size with the configuration option of MAXSETSIZE
and MAXPIECESIZE.
7
Session # 196
In addition you can control the number of channels available for a device type when you run a
command with the configuration setting of PARALLELISM or by setting a number of channels
within a run control block, this will determine whether RMAN reads or writes in parallel.
RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON;
new RMAN configuration parameters:
CONFIGURE ENCRYPTION FOR DATABASE ON;
new RMAN configuration parameters are successfully stored
RMAN> SET ENCRYPTION ON IDENTIFIED BY rene ONLY;
executing command: SET encryption
RMAN> CONFIGURE DEVICE TYPE disk PARALLELISM 3;
new RMAN configuration parameters:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;
new RMAN configuration parameters are successfully stored
RMAN> CONFIGURE MAXSETSIZE TO 100M;
new RMAN configuration parameters:
CONFIGURE MAXSETSIZE TO 100 M;
new RMAN configuration parameters are successfully stored
RMAN> CONFIGURE COMPRESSION ALGORITHM 'BASIC';
new RMAN configuration parameters:
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE;
new RMAN configuration parameters are successfully stored
7. SBT or Disk
When deciding if you are going to use SBT or Disk as your storage for your backup pieces or backup
sets, you will have to take into consideration the price of backing up to disk, as it is more expensive
backing to a disk device than to a tape device. You can also take into consideration the portability of a
tape , as this can help in moving your backups to a disaster recovery site without much complications.
8. Fast Recovery Area (FRA)
Optional disk location that you can use to store recovery-related files such as control file and online redo
log copies, archived redo log files, flashback logs, and RMAN backups. Setting the following parameters
will setup the FRA:
a. DB_RECOVERY_FILE_DEST
b. DB_RECOVERY_FILE_DEST_SIZE
If you decide to setup the FRA, you need to consider the following when setting up the size or quota of it
a. Size of your Database Backup
b. Size of incremental backups, as used by your chosen backup strategy
c. Size of flashback logs
d. Size of (n+1) days of Archived Redo logs
e. Size of your control files
f. Size of your online redo logs * number of groups
8
Session # 196
At the end, you will have to make a decision on your backup settings and strategy based on your business and
data availability necessities, as most of the configurations above, will impact the Mean Time To Recover (MTTR) in case
of a disaster.
CONTROL_FILE_RECORD_TIME_KEEP
Make sure that this database parameter is equal to or higher than your retention policy.
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/mount/copy01/TESTDB/%d_DB_BU_%I_%s_%T_%t';
new RMAN configuration parameters:
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
'/mount/copy01/TESTDB/%d_DB_BU_%I_%s_%T_%t';
Session # 196
'/mount/copy01/TESTDB/%d_DB_BU_%I_%s_%T_%t';
10
Session # 196
Or have it in a run block command, adding complexity and the manageability that we have been talking about, as
it will help you identify which backups are for what type of file and in a disaster this will help you recognize what is
needed to have your data available as soon as possible, and also override certain persistent configurations you have set
with RMAN.
In the example below, we are using a PARALELLISM of 2 instead of the 3 we have set in our configuration and
we are defining within the command backup, the destination and format the backup piece we will have and as well we
will delete any archived redo logs that we are backing up:
RMAN> RUN
2> {
3>
4>
5>
6>
BACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT '/MOUNT/COPY01/TESTDB/%d_DB_BU_%I_%s_%T_%t'
TAG 'FULL_BACKUP';
7>
BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL FORMAT '/MOUNT/COPY01/TESTDB/%d_ARCH_BU_%I_
%s_%T_%t' TAG 'ARCH_BACKUP' DELETE INPUT;
8>
BACKUP CURRENT CONTROLFILE FORMAT '/MOUNT/COPY01/TESTDB/%d_CTL_BU_%I_%s_%T_%t' TAG
'CTL_BACKUP';
9> }
executing command: SET COMMAND ID
using target database control file instead of recovery catalog
allocated channel: CH1
channel CH1: SID=56 device type=DISK
allocated channel: CH2
channel CH2: SID=50 device type=DISK
Starting backup at 17-FEB-2013 01:00:26
channel CH1: starting compressed full datafile backup set
channel CH1: specifying datafile(s) in backup set
input datafile file number=00002 name=+DB_DATA/testdb/datafile/sysaux.257.798230837
input datafile file number=00003 name=+DB_DATA/testdb/datafile/undotbs1.256.798230841
input datafile file number=00005 name=+DB_DATA/testdb/datafile/undotbs2.268.798234245
channel CH1: starting piece 1 at 17-FEB-2013 01:00:28
channel CH2: starting compressed full datafile backup set
channel CH2: specifying datafile(s) in backup set
input datafile file number=00001 name=+DB_DATA/testdb/datafile/system.260.798230829
input datafile file number=00004 name=+DB_DATA/testdb/datafile/users.264.798230845
channel CH2: starting piece 1 at 17-FEB-2013 01:00:29
channel CH1: finished piece 1 at 17-FEB-2013 01:01:04
piece handle=/mount/copy01/TESTDB/TESTDB_DB_BU_2590844408_48_20130217_807584427 tag=FULL_BACKUP
comment=NONE
11
Session # 196
As we mentioned at the considerations section of this document, with a backup set we can send a backup set to
SBT, this you can accomplish it with the BACKUP command.
In the example below, we are emulating an SBT and sending the backup sets we have in disk to this media:
RMAN> RUN {
2>
3>
PARMS="SBT_LIBRARY=oracle.disksbt,
4>
ENV=(BACKUP_DIR=/MOUNT/COPY01/SBT)";
5>
6> }
using target database control file instead of recovery catalog
allocated channel: ch1
channel ch1: SID=56 device type=SBT_TAPE
channel ch1: WARNING: Oracle Test Disk API
Starting backup at 17-FEB-2013 01:22:39
channel ch1: input backup set: count=32, stamp=807583495, piece=1
channel ch1: starting piece 1 at 17-FEB-2013 01:22:44
channel ch1: backup piece /mount/copy01/TESTDB/TESTDB_DB_BU_2590844408_32_20130217_807583495
piece handle=10o25fo7_1_2 comment=API Version 2.0,MMS Version 8.1.3.0
channel ch1: finished piece 1 at 17-FEB-2013 01:22:47
12
Session # 196
...
channel ch1: backup piece /mount/copy01/TESTDB/c-2590844408-20130217-02
piece handle=c-2590844408-20130217-02 comment=API Version 2.0,MMS Version 8.1.3.0
channel ch1: finished piece 1 at 17-FEB-2013 01:24:20
channel ch1: backup piece complete, elapsed time: 00:00:07
Finished backup at 17-FEB-2013 01:24:20
Starting Control File and SPFILE Autobackup at 17-FEB-2013 01:24:21
piece handle=c-2590844408-20130217-03 comment=API Version 2.0,MMS Version 8.1.3.0
Finished Control File and SPFILE Autobackup at 17-FEB-2013 01:24:36
released channel: ch1
MONITORING BACKUPS
Once you have launched a backup, you can monitor the progress of this backup with the V$SESSION,
V$PROCESS and V$SESSION_LONGOPS in the target database.
oracle@servidor1.localdomain [TESTDB1] /home/oracle/scripts
oracle $ cat monitor.sql
COLUMN CLIENT_INFO FORMAT a30
COLUMN SID FORMAT 999
COLUMN SPID FORMAT 9999
SELECT SID, SPID, CLIENT_INFO
FROM
V$PROCESS p, V$SESSION s
WHERE
p.ADDR = s.PADDR
AND
V$SESSION_LONGOPS
WHERE SID=&SID_NUMBER;
TESTDB1> @monitor.sql
SID SPID
CLIENT_INFO
id=Backup_Session
11:
new
11:
13
Session # 196
SID OPNAME
[Units/s] Remaining[s] complete[%]
TARGET
SOFAR
TOTALWORK UNITS
33
658909
7666654 Blocks
When doing a backup to SBT, you can monitor the SBT with the following SQL query:
TESTDB1 >COLUMN EVENT FORMAT a17
TESTDB1 >COLUMN SECONDS_IN_WAIT FORMAT 999
TESTDB1 >COLUMN STATE FORMAT a15
TESTDB1 >COLUMN CLIENT_INFO FORMAT a30
TESTDB1 >
TESTDB1 >SELECT p.SPID, s.EVENT, sw.SECONDS_IN_WAIT AS SEC_WAIT,
2
sw.STATE, CLIENT_INFO
FROM
WHERE
AND
s.SID=sw.SID
AND
s.PADDR=p.ADDR;
SPID
EVENT
SEC_WAIT STATE
CLIENT_INFO
147 WAITING
rman channel=CH5
backup piece
BACKUP REPORTS
Now that you have taken a backup, how do you know which backups you have and which datafiles need backup
based on your retention period? RMAN provides two commands to do just this LIST and REPORT.
The LIST command displays backups and information about other objects recorded in the RMAN repository.
LIST INCARNATION;
In the example below you can see that Backup with key 58 is a Full backup that is present in both SBT and
Disk, backup with key 60 is a backup set that contains archived redo logs, backup with key 62 is a Level 0
backup and backup with key 65 is a Level 1 backup belonging to an incremental backup strategy.
RMAN> LIST BACKUP SUMMARY;
List of Backups
===============
Key
TY LV S Device Type Completion Time
14
Session # 196
99 B F A DISK
13-FEB-2013 08:53:53 1
101 B F A DISK
13-FEB-2013 08:53:59 1
102 B A A DISK
13-FEB-2013 08:54:04 1
103 B F A DISK
13-FEB-2013 08:54:12 1
104 B F A DISK
13-FEB-2013 08:54:17 1
2
2
2
1
1
1
1
1
1
1
1
1
1
YES
YES
YES
NO
NO
NO
NO
NO
YES
YES
YES
NO
NO
TAG20130211T003457
TAG20130211T003457
TAG20130211T003527
TAG20130211T035522
TAG20130211T035524
TAG20130211T035524
TAG20130211T035554
TAG20130211T035609
FULL_BACKUP
FULL_BACKUP
ARCH_BACKUP
CTL_BACKUP
TAG20130213T085412
The REPORT command provides certain information on database backups, such as, which files need a
backup? Which backups are obsolete and can be deleted? Which files have not been backed up recently?
REPORT SCHEMA;
REPORT OBSOLETE;
In the example below you can see which data files in your database require a backup based on your retention
policy
RMAN> REPORT NEED BACKUP;
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
Report of files with less than 1 redundant backups
File #bkps Name
---- ----- ----------------------------------------------------6
0
+DB_DATA/testdb/datafile/rene.269.807120841
RMAN> REPORT NEED BACKUP REDUNDANCY 3;
Report of files with less than 3 redundant backups
File #bkps Name
---- ----- ----------------------------------------------------1
8
+DB_DATA/testdb/datafile/system.260.798230829
2
7
+DB_DATA/testdb/datafile/sysaux.257.798230837
3
7
+DB_DATA/testdb/datafile/undotbs1.256.798230841
4
7
+DB_DATA/testdb/datafile/users.264.798230845
5
7
+DB_DATA/testdb/datafile/undotbs2.268.798234245
6
0
+DB_DATA/testdb/datafile/rene.269.807120841
Session # 196
Complete recovery. - All changes in the redo logs are applied, this is only takes place when recovering from a
consistent backup (Cold Backup)
Incomplete recovery. - Only changes up to a specified point in time are applied, this is normally done when
recovering from an inconsistent backup (Hot Backup). There are three ways to set the time or SCN until you want
to do your media recovery:
o SCN
o
Time
Sequence
In case of a disaster, how would you even know which backup is needed for your restore and recovery operations,
RMAN has an option with the RESTORE command to preview the needed backups without actually doing the restore, it
will help you see if you have the appropriate backup to be able to do your actual restore.
RMAN> RUN
2> {
3>
SET UNTIL SEQUENCE 66;
4>
ALLOCATE CHANNEL CH1 DEVICE TYPE DISK ;
5>
RESTORE DATABASE PREVIEW SUMMARY;
6> }
executing command: SET until clause
using target database control file instead of recovery catalog
allocated channel: ch1
channel ch1: SID=78 instance=TESTDB1 device type=DISK
Starting restore at 11-FEB-2013 08:44:32
datafile 6 will be created automatically during restore operation
List of Datafile Copies
=======================
Key
File S Completion Time
Ckp SCN
Ckp Time
------- ---- - -------------------- ---------- -------------------16
17
18
1
A 11-FEB-2013 09:54:07 918627
11-FEB-2013 09:54:07
Name: /mount/copy01/TESTDB/TESTDB_2581526535_75_20130211_807098047
Tag: TAG20130211T000728
2
A 11-FEB-2013 09:54:07 918633
11-FEB-2013 09:54:07
Name: /mount/copy01/TESTDB/TESTDB_2581526535_76_20130211_807098047
Tag: TAG20130211T000728
3
A 11-FEB-2013 09:54:07 918642
11-FEB-2013 09:54:07
Name: /mount/copy01/TESTDB/TESTDB_2581526535_77_20130211_807098047
Tag: TAG20130211T000728
List of Backups
===============
Key
TY LV S Device Type Completion Time
#Pieces #Copies Compressed Tag
------- -- -- - ----------- -------------------- ------- ------- ---------- --69
B A A DISK
11-FEB-2013 06:39:57 1
1
YES
TAG20130211T063810
Media recovery start SCN is 918621
Recovery must be done beyond SCN 1063385 to clear datafile fuzziness
Finished restore at 11-FEB-2013 08:44:36
released channel: ch1
The RESTORE command in RMAN has a VALIDATE option to help you corroborate if your backups are not
corrupt. This should be part of your backup strategy, checking periodically whether you have an integral set of backups
that can meet your recoverability objectives. RMAN reads the selected backups in their entirety to confirm that they are
not corrupt, but does not produce output files. This will never replace the real restore/recovery scenario, but its as close
as you can get.
16
Session # 196
As we have talked, the great importance of knowing your DBID is when you are faced with the total loss of your
control files. In a case like that, you would need to set your DBID so that you can recover your control files, be able to
recover your database and open your database, as you did a recovery you would need to open your database with the
resetlogs option and would create a new incarnation of your database.
TESTDB1> startup
ORACLE instance started.
Total System Global Area
1068937216 bytes
Fixed Size
2235208 bytes
Variable Size
696255672 bytes
Database Buffers
Redo Buffers
364904448 bytes
5541888 bytes
ORA-00205: error in identifying control file, check alert log for more info
oracle@servidor1.localdomain [TESTDB1] /mount/oracle/dump01/TESTDB/diag/rdbms/testdb/TESTDB1/trace
oracle $ tail -15 alert_TESTDB1.log
SUCCESS: diskgroup DB_DATA was mounted
Sun Feb 17 17:09:32 2013
ORA-00210: cannot open the specified control file
ORA-00202: control file: '+DB_DATA/testdb/controlfile/control02.ctl'
ORA-17503: ksfdopn:2 Failed to open file +DB_DATA/testdb/controlfile/control02.ctl
ORA-15173: entry 'controlfile' does not exist in directory 'testdb'
ORA-00210: cannot open the specified control file
ORA-00202: control file: '+DB_DATA/testdb/controlfile/control01.ctl'
ORA-17503: ksfdopn:2 Failed to open file +DB_DATA/testdb/controlfile/control01.ctl
17
Session # 196
MOUNT...
1068937216 bytes
Fixed Size
Variable Size
Database Buffers
Redo Buffers
2235208 bytes
708838584 bytes
352321536 bytes
5541888 bytes
18
Session # 196
DB ID
STATUS
Reset SCN
Reset Time
TESTDB
2590844408
PARENT
01-NOV-2012 20:11:31
TESTDB
2590844408
PARENT
735231
16-FEB-2013 04:53:05
TESTDB
2590844408
CURRENT 796984
17-FEB-2013 07:17:43
If you were to lose every file from your database and you are not using a recovery catalog, you would need to
manually identify which are the last backups you took, if you have been following this document, you would have named
with a format of %d_DB_BU_%I_%s_%T_%t, which would allow you to quickly identify that this is a Database
backup and %d_ARCH_BU_%I_%s_%T_%t to let you identify your archive backups and if you have autocontrol
backup on, you see the last controlfile that was backed up as well.
RMAN> show CONTROLFILE AUTOBACKUP;
RMAN configuration parameters for database with db_unique_name TESTDB are:
CONFIGURE CONTROLFILE AUTOBACKUP ON;
RMAN> show CONTROLFILE AUTOBACKUP format;
RMAN configuration parameters for database with db_unique_name TESTDB are:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/mount/copy01/TESTDB/%F';
RMAN>
BACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT '/MOUNT/COPY01/TESTDB/%d_DB_BU_%I_%s_%T_%t' TAG
'FULL_BACKUP';
19
Session # 196
RMAN>
BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL FORMAT '/MOUNT/COPY01/TESTDB/%d_ARCH_BU_%I_%s_%T_
%t' TAG 'ARCH_BACKUP' DELETE INPUT;
With the above configuration settings and backup format, we can now restore and recover our database
oracle@servidor1.localdomain [TESTDB1] /mount/copy01/TESTDB
oracle $ ls -ltr | tail -15
-rw-r----- 1 oracle asmadmin
1043886080 bytes
2234960 bytes
Variable Size
276825520 bytes
Database Buffers
759169024 bytes
20
Session # 196
Redo Buffers
5656576 bytes
1068937216 bytes
Fixed Size
2235208 bytes
Variable Size
708838584 bytes
Database Buffers
352321536 bytes
Redo Buffers
5541888 bytes
21
Session # 196
DB ID
STATUS
Reset SCN
Reset Time
TESTDB
2590844408
PARENT
01-NOV-2012 20:11:31
TESTDB
2590844408
PARENT
735231
16-FEB-2013 04:53:05
TESTDB
2590844408
CURRENT 796984
17-FEB-2013 07:17:43
TESTDB
2590844408
CURRENT 797549
17-FEB-2013 08:38:19
LIST FAILURE. - Method to obtain information regarding failures if you suspect one has occurred.
22
Session # 196
VALIDATE DATABASE. - If you suspect that a failure has occurred but not detected, this will help you validate
corrupt blocks and missing data files.
ADVISE FAILURE. - Will advise you on repair options based on open database failures
REPAIR FAILURE. - Automatically will fix failures suggested in the most recent ADVISE FAILURE, you
should first try any manual repairs before trying to automatically repair failures.
Database mounted.
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '+DB_DATA/testdb/datafile/rene.269.807120841
RMAN> validate database;
RMAN-03002: failure of validate command at 02/11/2013 23:31:38
RMAN-06056: could not access datafile 6
RMAN> list failure;
List of Database Failures
=========================
Failure ID Priority Status
Time Detected
Summary
OPEN
Time Detected
Summary
23
Session # 196
FLASHBACK TECHNOLOGY
Even though flashback features are not part of the RMAN utility, this Oracle element will help you to reduce
your MTTR in case of human error, which normally is not a media failure and not detected as a database error, for
example dropping a table.
There are four main methods of the flashback feature
Flashback Query
Provides the ability to view the data as it existed in the past by using undo segments to obtain metadata and
historical data for transactions.
TESTDB1> select first_name,last_name from employees as of timestamp
2
where EMPLOYEE_ID=100;
FIRST_NAME
LAST_NAME
-------------------- ------------------------Steven
King
Flashback Table
Recovers a table to a previous point in time. Both Flashback Query and Table use undo segments.
TESTDB1> SELECT current_scn FROM v$database;
CURRENT_SCN
----------800885
24
Session # 196
Flashback Drop
Virtual container where all dropped objects reside. When you drop a table, it is automatically placed into the
Recycle Bin if it is turned on with the parameter RECYCLEBIN=ON
TESTDB1> show parameter recyclebin
NAME
TYPE
VALUE
string
on
FROM
RECYCLE_NAME
-------
ORIGINAL_NAME
TYPE
DROPTIME
25
Session # 196
BIN$1e4zkkN+MvfgQ0c4qMAGZQ==$0
RENE
TABLE
2013-02-17:10:24:15
BIN$1e5c/ckXM1rgQ0c4qMAdIA==$0
RENE
TABLE
2013-02-17:10:35:51
Flashback Database
Provides a more efficient alternative to database point-in-time recovery, this flashback feature is very useful
when you are doing upgrades or have the need to restore the database to a point in time without doing a media
recovery. It uses Flashback Logs so the FRA and DB_FLASHBACK_RETENTION_TARGET have to be set,
also you will also have to turn it on with the database in ARCHIVELOG mode.
There are some restrictions to using this feature:
o No current data files are lost or damaged. You can only use FLASHBACK DATABASE to rewind
changes to a data file made by an Oracle database, not to repair media failures.
o You are not trying to recover from accidental deletion of data files, undo a shrink data file operation, or
undo a change to the database name.
o You are not trying to use FLASHBACK DATABASE to return to a point in time before the restore or recreation of a control file.
o You are not trying to use FLASHBACK DATABASE to undo a compatibility change.
TESTDB1> select FLASHBACK_ON from v$database;
FLASHBACK_ON
-----------------NO
TESTDB1> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
TESTDB1> startup mount;
ORACLE instance started.
Total System Global Area
1068937216 bytes
Fixed Size
2235208 bytes
Variable Size
Database Buffers
Redo Buffers
708838584 bytes
352321536 bytes
5541888 bytes
Database mounted.
TESTDB1> alter database flashback on;
Database altered.
26
Session # 196
LOG_MODE
------------------ -----------YES
ARCHIVELOG
1068937216 bytes
Fixed Size
2235208 bytes
Variable Size
Database Buffers
Redo Buffers
708838584 bytes
352321536 bytes
5541888 bytes
Database mounted.
TESTDB1> flashback database to restore point before_damage;
Flashback complete.
TESTDB1> alter database open resetlogs;
Database altered.
TESTDB1> select count(1) from dba_users where username='RENE';
COUNT(1)
---------1
27
Session # 196
CONCLUSION
If the time ever comes when you need to recover from a disaster, it is very critical knowing the DBID of your
database; you can always get the DBID from
Backup logs
RMAN Catalog
Get to know your RMAN configurations and where your backups reside, SBT or DISK. Always have a backup of
your ORACLE_HOME/GRID_HOME to the last current patch applied, and last but not least have as many Level 0
backups as your retention period/storage capacities allow.
Knowing and having these settings/configurations will allow you to reduce your MTTR and reduce the costs of
having the data unavailable for your organization or client.
REFERENCES
a. Oracle Database Backup and Recovery User's Guide 11g Release 2 (11.2)
from http://docs.oracle.com/cd/E11882_01/backup.112/e10642/toc.htm
b. Oracle RMAN 11g Backup and Recovery
Robert G. Freeman & Matthew Hart (2010) McGraw-Hill
c. RMAN Recipes for Oracle Database 11g:A Problem-Solution Approach
Darl Kuhn, Sam Alapati, & Arup Nanda (2007) Apress
d. 10 Problems with your backup script
from http://www.slideshare.net/yvelikanov/10-problems-with-your-rman-backup-script
e. Dont Forget the Basics
from http://www.pythian.com/blog/wp-content/uploads/Michael_Abbey_OOW_2012_UGF6458.pdf
f. RMAN | Pythian - Data Experts Blog
from http://www.pythian.com/blog/tag/rman/
28
Session # 196