How to survive a disaster with RMAN

Backup and Recovery

HOW TO SURVIVE A DISASTER WITH RMAN
Gustavo René Antúnez, The Pythian Group

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 Oracle’s 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 the skills to verify the integrity of a backup strategy
• Provide examples how these skills can help you solve a real life disaster
HOW TO SURVIVE A DISASTER WITH RMAN

In July of 2012 IOUG released its “2012 IOUG DATABASE AVAILABILITY SURVEY”, in which it questions
358 data managers and professionals about their data availability and how they have planned for it to be up and running,
and a couple of points stand out:
• 45% cite human errors as the leading cause of unplanned outages
• 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 Oracle’s Recovery Manager (RMAN) works, this can and will help you out in reducing your meant time to
recover.

1 Session # 196

Backup and Recovery

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

2 Session # 196

Backup and Recovery

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)

WHAT DO YOU NEED TO BACKUP?

When you consider on using Oracle’s RMAN utility, there are files that are critical to backup so that you can be
able to restore and recover your database in case a disaster were to occur:
• Data files
• Control files
• Archived Redo logs (If Database running in Archive Log mode)

But let’s 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:
• Parameter File (pfile1 or spfile)
• Block Change Tracking File1
• ORACLE_HOME/GRID_HOME1
• tnsnames.ora / listener.ora/ sqlnet.ora1

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.

1
These files are not backed up with Oracle’s RMAN utility, you need to use a distinct method to back up these types of files.
3 Session # 196

Backup and Recovery

BENEFITS OF THE RMAN CATALOG

When using Oracle’s RMAN backup utility, all of the backup metadata regarding the database files and the
backups that have been taken is stored in the RMAN Repository; By default, this repository is its own control file, but
there is also another way to store this metadata, it is an RMAN Recovery Catalog, this catalog is a schema an typically in
a Database by itself, though there is the inconvenience that you have to maintain another database, the benefits normally
outweigh the disadvantages of this.

By having an RMAN recovery catalog, it creates a redundancy for the RMAN repository that is stored in the
control file, so if you were to lose all of your control files, the metadata of your backups will still exist in this catalog. A
recovery catalog also centralizes this metadata for all the Oracle databases that you backup in your organization, making
backup reporting and administration tasks easier to perform.

One of the greatest benefits of having an RMAN recovery catalog is that it keeps backup history longer than the
control file can keep it. If you ever have to change the DBID of your Database, all the backup information belonging to
the current and previous parent incarnation2 would be lost, the only way to have a history of your backups, would be if
you have an RMAN recovery catalog. In this same topic, setting CONTROL_FILE_RECORD_TIME_KEEP to a low
value, will mean that the control file records can be lost if Oracle needs the space in the control file, as the backup records
are reusable records

RMAN> list backup summary;
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- -------------------- ------- ------- ---------- ---
1 B F A DISK 16-FEB-2013 04:55:14 1 1 NO TAG20130216T045452
2 B F A DISK 16-FEB-2013 05:02:07 1 1 YES FULL_BACKUP
3 B A A DISK 16-FEB-2013 05:02:27 1 1 YES ARCH_BACKUP
4 B F A DISK 16-FEB-2013 05:02:44 1 1 NO CTL_BACKUP
RMAN> shutdown immediate

oracle@servidor1.localdomain [TESTDB1] /home/oracle/Desktop
oracle $ nid target=sys/oracle@TESTDB
Connected to database TESTDB (DBID=2590798818)
Connected to server version 11.2.0
Control Files in database:
+DB_DATA/testdb/controlfile/control01.ctl
+DB_DATA/testdb/controlfile/control02.ctl

Change database ID of database TESTDB? (Y/[N]) => y
…

2
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.
4 Session # 196

Backup and Recovery

…
Database ID for database TESTDB changed to 2590844408.
All previous backups and archived redo logs for this database are unusable.
Database is not aware of previous backups and archived logs in Recovery Area.
Database has been shutdown, open database with RESETLOGS option.
Succesfully changed database ID.
DBNEWID - Completed succesfully.

oracle $ sqlplus
TESTDB1> startup mount
ORACLE instance started.
Database mounted.
TESTDB1> alter database open resetlogs;

Database altered.

oracle $ rman target /
connected to target database: TESTDB (DBID=2590844408)

RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1 1 TESTDB 2590844408 PARENT 735231 16-FEB-2013 04:53:05
2 2 TESTDB 2590844408 CURRENT 737037 16-FEB-2013 05:05:47

RMAN> list backup summary;
List of Backups
===============
------- -- -- - ----------- -------------------- ------- ------- ---------- ---

CONSIDERATIONS BEFORE CONFIGURING YOUR RMAN BACKUPS

As we talked above there are several considerations before you even start taking your first RMAN backup
1. ARCHIVELOG vs. NOARCHIVELOG
When deciding if you are going to take a cold (Consistent) or hot (Inconsistent) backup, you have verify
the LOG_MODE of your database, as you can’t run a hot backup in a database running in
NOARCHIVELOG mode

5 Session # 196

Backup and Recovery

2. Use of an RMAN Recovery Catalog
Do you have enough databases to require a centralized reporting schema? Do you have a problem
maintaining another high availability database? Do you require a secondary backup metadata repository?

TESTDB1> CREATE TABLESPACE catalog;
Tablespace created.

TESTDB1> CREATE USER cat_user IDENTIFIED BY cat_user_password
2 DEFAULT TABLESPACE catalog;
User created.

TESTDB1> GRANT connect, resource, recovery_catalog_owner TO cat_user;
Grant succeeded.

oracle $ rman catalog=cat_user/cat_user_password

RMAN> CREATE CATALOG;
recovery catalog created

3. Full or Incremental backups
a. Full Backup
Includes every allocated block in the file being backed up
b. Incremental Backups
• Level 0 is the base for subsequent incremental backups
• Level 1 incremental backup can be either of the following types:
i. Differential incremental backup. - Backs up all blocks changed after the most recent
incremental backup at level 1 or 0.

ii. Cumulative incremental backup. - Backs up all blocks changed after the most recent
incremental backup at level 0.

6 Session # 196

Backup and Recovery

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

Backup and Recovery

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;
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO BACKUPSET;

RMAN> CONFIGURE MAXSETSIZE TO 100M;
CONFIGURE MAXSETSIZE TO 100 M;

RMAN> CONFIGURE COMPRESSION ALGORITHM 'BASIC';
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE;

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

Backup and Recovery

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.
CONFIGURING RMAN DEFAULT SETTINGS
To facilitate the daily use of RMAN for your backup and recovery, it lets you set a number of persistent
configuration settings for each target database. There are several configurations that if set incorrectly or not accordingly
you might not be able to meet your recovery necessities. You can view your RMAN settings with the SHOW ALL or your
policy settings with the SHOW RETENTION POLICY commands
• CONFIGURE DEFAULT DEVICE TYPE TO DISK;
When formatting your output, be sure to always include the DBID, below are a couple of wildcards that
will always include your DBID.
a. %d_%I_%s_%T_%t
b. %U
• CONFIGURE CONTROLFILE AUTOBACKUP ON;
This will make sure that you always have a secondary option
• CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 3 TIMES TO DISK;
• Retention policy settings
Your retention policy can either be based on the redundancy of backups you have taken (a), or the
number of days before your backup becomes obsolete (b), these options are mutually exclusive
a. CONFIGURE RETENTION POLICY TO 3;
b. CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 8 DAYS;
There must always exist one backup of each data file that satisfies SYSDATE - BACKUP
CHECKPOINT TIME >= 8
c. CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 3 TIMES TO DISK;
This is critical when it is set to be equal or above the redundant retention policy you have, as
losing even one archived redo log, will compromise your recoverability.
• 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';
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/mount/copy01/TESTDB/%d_DB_BU_%I_%s_%T_%t';

RMAN> SHOW ALL;

RMAN configuration parameters for database with db_unique_name TESTDB are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 8 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/mount/copy01/TESTDB/%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

9 Session # 196

Backup and Recovery

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/mount/copy01/TESTDB/%d_DB_BU_%I_%s_%T_%t';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ;
#default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/mount/copy01/control_snaps/snapcf_TESTDB1.f';

BACKING UP YOUR DATABASE

The main objectives of taking a physical backup of your database is data protection in case of media failure and
data preservation in case you need preserve a copy of a database as it existed before a major release. Oracle RMAN utility
uses the command BACKUP to accomplish this objective.
You can run this command in one line, and as you can see it has the ease and simplicity for any beginners to
backup a database:
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
Starting backup at 17-FEB-2013 00:46:18
current log archived
using channel ORA_DISK_1
skipping archived logs of thread 1 from sequence 1 to 3; already backed up
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=4 RECID=4 STAMP=807583580
…
channel ORA_DISK_1: finished piece 1 at 17-FEB-2013 00:47:00
piece handle=/mount/copy01/TESTDB/TESTDB_DB_BU_2590844408_38_20130217_807583616
tag=TAG20130217T004624 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 17-FEB-2013 00:47:00

channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
channel ORA_DISK_1: starting piece 1 at 17-FEB-2013 00:47:04
channel ORA_DISK_1: finished piece 1 at 17-FEB-2013 00:47:05
piece handle=/mount/copy01/TESTDB/TESTDB_DB_BU_2590844408_39_20130217_807583624
tag=TAG20130217T004703 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Starting Control File and SPFILE Autobackup at 17-FEB-2013 00:47:06

10 Session # 196

Backup and Recovery

piece handle=/mount/copy01/TESTDB/c-2590844408-20130217-00 comment=NONE
Finished Control File and SPFILE Autobackup at 17-FEB-2013 00:47:21

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> SET COMMAND ID TO 'BACKUP_SESSION';
4> ALLOCATE CHANNEL CH1 DEVICE TYPE DISK;
5> ALLOCATE CHANNEL CH2 DEVICE TYPE DISK;
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

channel CH1: SID=56 device type=DISK

channel CH2: SID=50 device type=DISK

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
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 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
…
channel CH1: starting compressed archived log backup set
channel CH1: specifying archived log(s) in backup set

11 Session # 196

Backup and Recovery

piece handle=/mount/copy01/TESTDB/TESTDB_ARCH_BU_2590844408_51_20130217_807584479
tag=ARCH_BACKUP comment=NONE
channel CH1: backup set complete, elapsed time: 00:00:01
channel CH1: deleting archived log(s)
archived log file
name=/mount/oracle/copy01/flash_recovery_area/TESTDB/TESTDB/archivelog/2013_02_17/o1_mf_1_7_8l0wkfst_.ar
c RECID=7 STAMP=807584478

channel CH1: starting full datafile backup set
including current control file in backup set
piece handle=/mount/copy01/TESTDB/TESTDB_CTL_BU_2590844408_52_20130217_807584489 tag=CTL_BACKUP
comment=NONE
channel CH1: backup set complete, elapsed time: 00:00:03

piece handle=/mount/copy01/TESTDB/c-2590844408-20130217-02 comment=NONE
released channel: CH1
released channel: CH2

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> ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE'
3> PARMS="SBT_LIBRARY=oracle.disksbt,
4> ENV=(BACKUP_DIR=/MOUNT/COPY01/SBT)";
5> BACKUP BACKUPSET ALL;
6> }
allocated channel: ch1
channel ch1: SID=56 device type=SBT_TAPE
channel ch1: WARNING: Oracle Test Disk API

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

Backup and Recovery

...
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

piece handle=c-2590844408-20130217-03 comment=API Version 2.0,MMS Version 8.1.3.0
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 CLIENT_INFO LIKE '%Backup_Session%';

SET PAGESIZE 9999 LINESIZE 200
COL OPNAME FORMAT A40
COL TARGET FORMAT A15
COL UNITS FORMAT A10
COL TIME_REMAINING FORMAT 99990.99 HEADING REMAINING[S]
COL BPS FORMAT 9990.99 HEADING [UNITS/S]
COL FERTIG FORMAT 90.99 HEADING "COMPLETE[%]"
SELECT SID, OPNAME, TARGET, SOFAR, TOTALWORK, UNITS,
(TOTALWORK-SOFAR)/TIME_REMAINING BPS, (TIME_REMAINING/3600) TIME_REMAINING,
SOFAR/TOTALWORK*100 FERTIG
FROM V$SESSION_LONGOPS
WHERE SID=&SID_NUMBER;

TESTDB1> @monitor.sql
SID SPID CLIENT_INFO
---- ------------------------ ------------------------------
69 20654 id=Backup_Session

Enter value for sid_number: 69
old 11: WHERE sid in (&sid_number)
new 11: WHERE sid in (69)

13 Session # 196

Backup and Recovery

SID OPNAME TARGET SOFAR TOTALWORK UNITS
[Units/s] Remaining[s] complete[%]
---- ---------------------------------------- --------------- ---------- ---------- ----------
----------- ------------ -----------
69 RMAN: aggregate input 33 658909 7666654 Blocks
34691.81 0.06 8.59

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
3 FROM V$SESSION_WAIT sw, V$SESSION s, V$PROCESS p
4 WHERE sw.EVENT LIKE '%MML%'
5 AND s.SID=sw.SID
6 AND s.PADDR=p.ADDR;

SPID EVENT SEC_WAIT STATE CLIENT_INFO
------------------------ ----------------- ---------- --------------- --------------
7037 Backup: MML query 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 EXPIRED COPY;
• LIST EXPIRED BACKUP;
• LIST BACKUP SUMMARY;
• LIST BACKUP TAG TAG20130211T035650;
• LIST RECOVERABLE BACKUP OF DATABASE;
• LIST BACKUP OF DATAFILE 1 COMPLETED BETWEEN '03-FEB-2013' and '11-FEB-2013’;
• 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
===============

14 Session # 196

Backup and Recovery

------- -- -- - ----------- -------------------- ------- ------- ---------- ---
...
58 B F A * 11-FEB-2013 10:10:08 1 2 YES TAG20130211T003457
59 B F A * 11-FEB-2013 10:10:08 1 2 YES TAG20130211T003457
60 B A A * 11-FEB-2013 10:10:08 1 2 YES TAG20130211T003527
61 B A A DISK 11-FEB-2013 12:04:55 1 1 NO TAG20130211T035522
62 B 0 A DISK 11-FEB-2013 12:04:55 1 1 NO TAG20130211T035524
64 B A A DISK 11-FEB-2013 12:04:55 1 1 NO TAG20130211T035554
…
102 B A A DISK 13-FEB-2013 08:54:04 1 1 YES ARCH_BACKUP
103 B F A DISK 13-FEB-2013 08:54:12 1 1 NO CTL_BACKUP

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 NEED BACKUP;
• REPORT SCHEMA;
• REPORT NEED BACKUP RECOVERY WINDOW OF 2 DAYS;
• REPORT OBSOLETE;
• REPORT SCHEMA AT TIME 'SYSDATE-7'; (Only with recovery catalog)

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

RESTORING AND RECOVERING FROM FAILURE

Restoring data files is retrieving them from a valid backup and putting them in a disk location, this can be the
same place where it resided before the failure or a different location. Media recovery is the application of changes from
redo logs and incremental backups to a restored data file to bring the data file forward to a desired SCN or point in time.
When doing media recovery, there are two types of recovery depending on the backup you took:

15 Session # 196

Backup and Recovery

• 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
o 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
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 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
…
17 2 A 11-FEB-2013 09:54:07 918633 11-FEB-2013 09:54:07
Tag: TAG20130211T000728
18 3 A 11-FEB-2013 09:54:07 918642 11-FEB-2013 09:54:07
Tag: TAG20130211T000728
…
List of Backups
===============
------- -- -- - ----------- -------------------- ------- ------- ---------- ---
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

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 it’s as close
as you can get.

16 Session # 196

Backup and Recovery

• RESTORE DATABASE VALIDATE;
• RESTORE CONTROLFILE VALIDATE;
• RESTORE ARCHIVELOG FROM TIME 'SYSDATE-nn' VALIDATE;

RMAN> RUN{
2> SET UNTIL SEQUENCE 87;
3> ALLOCATE CHANNEL CH1 DEVICE TYPE DISK ;
4> RESTORE DATABASE VALIDATE;
5> RESTORE CONTROLFILE VALIDATE;
6>}
executing command: SET until clause
…

channel ch1: starting validation of datafile backup set
channel ch1: reading from backup piece /mount/copy01/TESTDB/TESTDB_2581526535_115_20130211_807139642
channel ch1: piece handle=/mount/copy01/TESTDB/TESTDB_2581526535_115_20130211_807139642
tag=TAG20130211T212722
channel ch1: restored backup piece 1
…
channel ch1: piece handle=/mount/copy01/TESTDB/TESTDB_2581526535_116_20130211_807139687
tag=TAG20130211T212722
channel ch1: restored backup piece 1
channel ch1: validation complete, elapsed time: 00:00:01

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

Total System Global Area 1068937216 bytes
Fixed Size 2235208 bytes
Variable Size 696255672 bytes
Database Buffers 364904448 bytes
Redo Buffers 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

Backup and Recovery

ORA-15173: entry 'controlfile' does not exist in directory 'testdb'
ORA-205 signalled during: ALTER DATABASE MOUNT...
Sun Feb 17 07:09:33 2013
Checker run found 2 new persistent data failures
SUCCESS: diskgroup DB_DATA was dismounted

oracle@servidor1.localdomain [TESTDB1] /mount/oracle/dump01/TESTDB/diag/rdbms/testdb/TESTDB1/trace
connected to target database (not started)
RMAN> set DBID=2590844408;
executing command: SET DBID

RMAN> startup nomount;
Oracle instance started

RMAN> restore controlfile from autobackup;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=30 device type=DISK
recovery area destination: /mount/oracle/copy01/flash_recovery_area/TESTDB
database name (or database unique name) used for search: TESTDB
channel ORA_DISK_1: AUTOBACKUP
/mount/oracle/copy01/flash_recovery_area/TESTDB/TESTDB/autobackup/2013_02_16/o1_mf_s_807512860_8kypmryz_.bkp
found in the recovery area
channel ORA_DISK_1: looking for AUTOBACKUP on day: 20130217
channel ORA_DISK_1: restoring control file from AUTOBACKUP
channel ORA_DISK_1: control file restore from AUTOBACKUP complete
output file name=+DB_DATA/testdb/controlfile/control01.ctl

RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1

RMAN> recover database;
Starting recover at 17-FEB-2013 07:16:10
Starting implicit crosscheck backup at 17-FEB-2013 07:16:11
Finished implicit crosscheck backup at 17-FEB-2013 07:16:12

18 Session # 196

Backup and Recovery

Starting implicit crosscheck copy at 17-FEB-2013 07:16:12
Finished implicit crosscheck copy at 17-FEB-2013 07:16:13

searching for all files in the recovery area
cataloging files...
cataloging done

List of Cataloged Files
File Name:
File Name:
/mount/oracle/copy01/flash_recovery_area/TESTDB/TESTDB/archivelog/2013_02_16/o1_mf_1_1_8kymdzom_.arc
File Name:
/mount/oracle/copy01/flash_recovery_area/TESTDB/TESTDB/archivelog/2013_02_16/o1_mf_1_2_8kymf16b_.arc
starting media recovery
archived log for thread 1 with sequence 10 is already on disk as file
+DB_DATA/testdb/onlinelog/group_2.261.807548767
archived log file name=+DB_DATA/testdb/onlinelog/group_2.261.807548767 thread=1 sequence=10
media recovery complete, elapsed time: 00:00:01
Finished recover at 16-FEB-13 07:17:27

RMAN> alter database open resetlogs;
database opened

------- ------- -------- ---------------- --- ---------- ----------
1 1 TESTDB 2590844408 PARENT 1 01-NOV-2012 20:11:31

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;
CONFIGURE CONTROLFILE AUTOBACKUP ON;

RMAN> show CONTROLFILE AUTOBACKUP format;
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

Backup and Recovery

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 34799616 Feb 17 07:06 TESTDB_CTL_BU_2590844408_60_20130217_807642372
-rw-r----- 1 oracle asmadmin 34832384 Feb 17 07:06 c-2590844408-20130217-04
-rw-r----- 1 oracle asmadmin 19398656 Feb 17 07:53 TESTDB_DB_BU_2590844408_64_20130217_807609191
-rw-r----- 1 oracle asmadmin 200704 Feb 17 07:53 TESTDB_ARCH_BU_2590844408_67_20130217_807609236

oracle@servidor1.localdomain [TESTDB1] /home/oracle
oracle $ export ORA_RMAN_SGA_TARGET=1000

oracle@servidor1.localdomain [TESTDB1] /home/oracle
Recovery Manager: Release 11.2.0.3.0 - Production on Sun Feb 17 08:27:29 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

RMAN> set dbid=2590844408;
executing command: SET DBID

startup failed: ORA-01078: failure in processing system parameters
ORA-01565: error in identifying file '+DB_DATA/TESTDB/spfileTESTDB.ora'
ORA-17503: ksfdopn:2 Failed to open file +DB_DATA/TESTDB/spfileTESTDB.ora
ORA-15056: additional error message
ORA-17503: ksfdopn:2 Failed to open file +DB_DATA/testdb/spfiletestdb.ora
ORA-15173: entry 'spfiletestdb.ora' does not exist in directory 'testdb'
ORA-06512: at line 4

starting Oracle instance without parameter file for retrieval of spfile

20 Session # 196

Backup and Recovery


RMAN> restore spfile from autobackup;
…
channel ORA_DISK_1: no AUTOBACKUP in 7 days found
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 02/17/2013 08:29:40
RMAN-06172: no AUTOBACKUP found or specified handle is not a valid copy or piece
RMAN> restore spfile from '/mount/copy01/TESTDB/c-2590844408-20130217-08';
channel ORA_DISK_1: restoring spfile from AUTOBACKUP /mount/copy01/TESTDB/c-2590844408-20130217-08
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete

RMAN> shutdown immediate;
Oracle instance shut down


RMAN> restore controlfile from '/mount/copy01/TESTDB/c-2590844408-20130217-08';
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:55

RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1

RMAN> restore database;

21 Session # 196

Backup and Recovery

…
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00002 to +DB_DATA/testdb/datafile/sysaux.257.798230837
…
channel ORA_DISK_2: restore complete, elapsed time: 00:02:58
RMAN> recover database;

channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=1
channel ORA_DISK_1: reading from backup piece
/mount/copy01/TESTDB/TESTDB_ARCH_BU_2590844408_68_20130217_807609237
…
channel default: deleting archived log(s)
archived log file
name=/mount/oracle/copy01/flash_recovery_area/TESTDB/TESTDB/archivelog/2013_02_17/o1_mf_1_2_8l1q8rmj_.arc
RECID=19 STAMP=807611849
unable to find archived log
archived log thread=1 sequence=3
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/17/2013 08:37:57
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 3 and starting SCN
of 797548

RMAN> alter database open resetlogs;
database opened

------- ------- -------- ---------------- --- ---------- ----------
1 1 TESTDB 2590844408 PARENT 1 01-NOV-2012 20:11:31

WHAT TO DO IF I DON’T KNOW WHAT TO DO?

Oracle has a utility within RMAN that is part of Oracle’s Fault Diagnosability Infrastructure, which automatically
diagnoses data failures, determines and presents appropriate repair options, and executes repairs at the user's request. It
can help you and guide you in diagnosing and repairing a media failure thus helping you reduce your MTTR.
The workflow begins when you either suspect or discover a failure
• LIST FAILURE. - Method to obtain information regarding failures if you suspect one has occurred.

22 Session # 196

Backup and Recovery

• 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.
• Return to the first step if other failures exist

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
---------- -------- --------- -------------------- -------
4222 HIGH OPEN 11-FEB-2013 23:31:02 One or more non-system datafiles are missing

RMAN> list failure 4222 detail;
…
Impact: See impact for individual child failures
List of child failures for parent failure ID 4222
Failure ID Priority Status Time Detected Summary
---------- -------- --------- -------------------- -------
4225 HIGH OPEN 11-FEB-2013 23:31:02 Datafile 6:
'+DB_DATA/testdb/datafile/rene.269.807120841' is missing
Impact: Some objects in tablespace RENE might be unavailable

RMAN> advise failure 4222;
…
Optional Manual Actions
=======================
1. If file +DB_DATA/testdb/datafile/rene.269.807120841 was unintentionally renamed or moved, restore it
Automated Repair Options
========================
Option Repair Description
------ ------------------
1 Restore and recover datafile 6
Strategy: The repair includes complete media recovery with no data loss
Repair script: /mount/oracle/dump01/TESTDB/diag/rdbms/testdb/TESTDB1/hm/reco_3903715129.hm

RMAN> repair failure;
…
contents of repair script:

23 Session # 196

Backup and Recovery

# restore and recover datafile
restore datafile 6;
recover datafile 6;
sql 'alter database datafile 6 online';

…

…
Finished recover at 11-FEB-2013 23:37:16

sql statement: alter database datafile 6 online
repair failure complete

Do you want to open the database (enter YES or NO)? yes
database opened

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 to_timestamp('2013-02-11 18:15:00','YYYY-MM-DD HH24:MI:SS')
3 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

Backup and Recovery

TESTDB1> select count(1) from test.rene;
COUNT(1)
----------
16

TESTDB1> delete from test.rene;
16 rows deleted.

TESTDB1> commit;
Commit complete.

COUNT(1)
----------
0

TESTDB1> FLASHBACK TABLE test.rene TO SCN 800885;
Flashback complete.

COUNT(1)
----------
16

• 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
------------------------------------ ----------- ------------------------------
recyclebin string on

TESTDB1> drop table test.rene;
Table dropped.

select count(1) from test.rene
ERROR at line 1:
ORA-00942: table or view does not exist

TESTDB1> SELECT OBJECT_NAME AS RECYCLE_NAME, ORIGINAL_NAME, TYPE,DROPTIME
2 FROM RECYCLEBIN WHERE ORIGINAL_NAME='RENE';

RECYCLE_NAME ORIGINAL_NAME TYPE DROPTIME
------------------------------ -------------------------------- -------------------------
-------

25 Session # 196

Backup and Recovery

BIN$1e4zkkN+MvfgQ0c4qMAGZQ==$0 RENE TABLE 2013-02-17:10:24:15
BIN$1e5c/ckXM1rgQ0c4qMAdIA==$0 RENE TABLE 2013-02-17:10:35:51

TESTDB1> FLASHBACK TABLE "BIN$1e5c/ckXM1rgQ0c4qMAdIA==$0" TO BEFORE DROP;
Flashback complete.

COUNT(1)
----------
16

• 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 re-
creation 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;

Database mounted.

TESTDB1> alter database flashback on;
Database altered.

26 Session # 196

Backup and Recovery

TESTDB1> alter database open;
Database altered.

TESTDB1> select flashback_on,log_mode from v$database;
FLASHBACK_ON LOG_MODE
------------------ ------------
YES ARCHIVELOG

TESTDB1> CREATE RESTORE POINT before_damage;
Restore point created.

TESTDB1> drop user RENE cascade;
User dropped.

TESTDB1> select count(1) from dba_users where username='RENE';
COUNT(1)
----------
0

TESTDB1> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
TESTDB1> startup mount

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

Backup and Recovery

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
• Backup Pieces if formatted to have it in the backup piece
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. Don’t 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

How to survive a disaster with RMAN

Recommended

More Related Content

Similar to How to survive a disaster with RMAN

Similar to How to survive a disaster with RMAN (20)

More from Gustavo Rene Antunez

More from Gustavo Rene Antunez (16)

Recently uploaded

Recently uploaded (20)

How to survive a disaster with RMAN