RMAN - Eliminate the Mystery of Oracle Backups

High Availability Boot Camp: RMAN - Eliminate the Mystery

RMAN - ELIMINATE THE MYSTERY
Nelson Calero, UYOUG

RMAN is a must-have tool familiar to most Oracle DBAs. There are many capabilities hidden in
RMAN and going beyond the basics is important.
After a quick review of the core functionality, we will discuss both old and new features and
provide tips and tricks along with sample code using the Command Line Interface (CLI).

INTRODUCTION
One of the most important tasks of the DBA is to ensure that production data are safe, although
incidents can occur and compromise hardware, software or physical facilities. Within our Disaster
Recovery and High Availability plans, one of the most important components are the backups.

RMAN functionality is implemented in the Oracle kernel, with many features to use in backup and
recovery tasks, available through a PL/SQL API. The RMAN client is a command line utility
included in the installation of the Oracle database, in the $ORACLE_HOME/bin directory, written
in Pro*C that executes the PL/SQL API. Also there are some functionalities accessible through
Enterprise Manager, and the possibility to create your own scripts calling the PL/SQL API.

The most important tasks we can perform with RMAN are:
• backup
• recovery
• failure diagnostic (from 11.1, Data Recovery Advisor functionality)
• instance duplication
• backups history

RMAN provides several additional features in addition to the obvious tasks expected of backups
and recovery. From validating the logical and physical integrity of the backups to sophisticated
tasks in a single command as the duplication of an instance. It also presents a lot of maturity,
where there have been resolved many errors (bugs): over 170 in all versions (ref:
support.oracle.com), and with few known issues remaining in the current version (MOS Note
247611.1).
Additionally, each new version of the database incorporate new functionaliies or improves
existing ones. For example, 11 improvements are included in version 11.2 and 21 in version 11.1
(documented in the "new features" section of each manual).

Although RMAN has been available since version 8 of the database (CLI mode), its adoption by
users has been low compared to the alternative of developing scripts that perform backups
manually.
This article will show the advantages of using RMAN, with examples to motivate those who do
not use it yet, and help leverage their capabilities to those who already use it.

1 Session #492


BACKUP POLICIES?
RMAN is a tool that can be used for specific actions or to implement tasks from a backup policy.
These policies are the ones who ensure that sensitive information of our organization is safe, and
therefore include processes and procedures that exceed the use of a particular tool.

As an example, these include the transfer of backups to external sites, the rotation frequency of
the media used to store the backups, use of encryption techniques to ensure that data is not
readable by third parties in case of media devices get lost, use of additional features of the
database to have redundant data to be used in case of failure, etc..

The DataPump utility, functionality such as Flashback and Secure Backup of the Oracle Database
are other ingredients to include in a backup policy, that we will not see here.

ORACLE BACKUPS
The database has several files: data (datafiles), control (controlfiles), temporal (TempFiles), undo
and redologs. To maintain consistency, it uses internally a number which identify transactions,
called System Change Number (SCN).
(http://docs.oracle.com/cd/E11882_01/server.112/e25789/transact.htm#CHDIAFFH)
This number is stored in several of these files. During the opening of the database is analyzed
and action is taken to ensure consistent data exist only with the last commited transaction,
which corresponds to an SCN. (For more details on this operation, see note 1376995.1
Information on the System Change Number (SCN) and how it is Used in the Oracle Database).

To take a backup while the database is down, the procedure is simple: just copy all the files that
composes the database to the new destination. This backup can be used later with the same
result we have on the original installation when opening the database after the backup, If it is
consistent, it will be consistent. If it needs to be recovered, we need to make sure we have all
the necesary logs included on this copy at the destination site.
This procedure is known as cold backup. It is difficult to have the option of using it in production
because it implies lack of service (down time) while it runs and that may be diffcult to arrange.

When the database is running, any activity of internal processes (background) and user (server
processes) can change data files. Then, copying those files from the operating system (using cp /
copy) can generate copies that are not identical to the originals one, since the database blocks
can be written (by the DBWR process) when trying to be read by the cp command, generating
the problem known as Fractured Block
(http://docs.oracle.com/cd/E11882_01/backup.112/e10642/glossary.htm#CHDBFCBF). This
occurs because the OS write operations are not necessarily of the same size that the blocks used
by the database (typical disk blocks are 512 bytes vs database blocks of 8 Kbytes), therefore
there may be several non-atomic input/output operations for each Oracle data blocks.
Even if using ASM this copy is possible, and can run into the same problem, though with different
methods depending on the version, because from 11.1 the command cp exists within the
ASMCMD utility.

To avoid this problem while copying, we must tell the database that we are doing this operation
through the command ALTER TABLESPACE BEGIN BACKUP <name>, and it will take precautions:
to freezes the modification of the SCN in datafiles header, and to write full data block the first

2 Session #492


time a record is modified. Archivelog should be enabled on the database to use this functionality.
It is necessary (and very important) to run another command to indicate the end of the copy
(ALTER TABLESPACE <name> END BACKUP), and thus the database starts to operate normally.

With these actions, when using the restored backup files and open the database, the recovery
process identifies that the datafiles need recovery from the moment the backup started (as the
SCN in the headers is less than the last known to the controlfile), so the recovery applies the
redo generated that include the complete blocks, correcting any possible inconsistencies in
existing data files. For more details, see note 1050932.6 'Why Are Datafiles Being Written To
DURING Hot Backup?'

This form of backup is known as hot backup, or inconsistent. This requires an additional task of
recovery when used, therefore archived redologs generated until the end of the backup is
needed in addition.

The following is a summary of the commands used in the two manual backup strategies (also
known as user managed):

consistent (cold) inconsistent (hot)
cp /u02/oradata/* dest-bkp alter tablespace nnn begin backup;
cp /u02/oradata/datafile-nnn.dbf destbkp
alter tablespace nnn end backup;
cp /archivelogs-path/* dest-bkp

RMAN BACKUPS
RMAN is invoked by the command line and it runs as a console waiting to execute commands.
The database used to perform backup and recovery is called "target". It is necessary to connect
before to start executing commands, indicating the command line parameter "target", or using
the "connect" command. It can be used a database name configured using SQL*NET, or using "/"
to connect to the local database. The user must have sysdba privilege, so SYS is usually used.

RMAN stores metadata about the operations performed in a repository itself, along with
configuration variables in the controlfile of the target database or in a proprietary database
called the catalog.

To take a backup we use the BACKUP command. It can make identical physical copies (image
copies) or BACKUP SETS, a proprietary format, somewhat like TAR that can span multiple files,
that stores all data backed up in one or more files, called BACKUP PIECES. The latter is preferred
because it creates smaller files, as explained later.

There are several files in the database that are not required for recovery and which can be
recreated without loss of information, therefore they are not copied. Also, other files that are not
part of the data stored in the database are not copied either.
In short, these are not copied:
• temporary files (tempfiles) and online redo logs
• files from external tabes or bfiles
• database binary files
• database network configuration files

3 Session #492


The copied files are:
• datafiles
• controlfiles
• archived logs
• spfile

Using the prior examples for manual backups, with RMAN they are as follows:

consistent (cold) inconsistent (hot):
rman target / rman target /
startup mount; backup database plus archivelog;
backup database plus archivelog;

The difference between the scripts used for cold / hot cases is that in the first one the database
must be open in at least mount mode to run the backup command. And in the second it should
be in archivelog mode.

Archivelog needs to be included in a cold backup?. It depends. If the database was down
normally (immediate), then it is not necessary to do recovery, and archivelogs are not necessary.
If the database was closed with a "shutdown abort" command or the server was turned off, then
they are required to do recovery when we attempt to open it. This is only possible if the
database is in archivelog mode, because RMAN does not allow to take a backup of a closed
database in an inconsistent state if it is in NOARCHIVELOG mode
(http://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsynta007.htm#CHDBIAHI).

RMAN do not have the problem of fractured blocks while copying, because it knows the format of
the blocks and its contents is validated when copying, retrying the reading of those detected
inconsistent. Then, the database does not need to store additional redo while taking the backup.

CONCEPTS
Now that we know how to make a backup, we must know the concepts used by RMAN:
• device: destination of the backups. It can be disk or tape (SBT).
• channels: is a connection to the database used to read data and write it to the destination
device. The default value is one. Several can be used to achieve parallelism.
• Image copy: and identical copy of a single data file, archived redo log file, or control file.
• backup sets: an Oracle proprietary way of making backups, which includes all the backed up
data in a TAR like format, having an internal table of contents, can span several files and
loads multiple external files into one archive. It is identified by a unique number, a date and a
label (TAG). It is the only format allowed to tape (SBT).
• backup pieces: are the files that make up a backupset.

4 Session #492


• backup status: Indicates whether the backup is available for use (Available) or if the file no
longer exists in the destination (Expired). The latter is detected by manually running the
command Crosscheck, which is not doing automatically.
• obsolete backups: those not needed to meet our retention policy. They are not deleted
automatically. The commands REPORT OBSOLETE is used to see which are the files, and
DELETE OBSOLETE to delete them from destination.
• incarnation: is a number associated with the instance, which changes every time it is open
with resetlogs. It is important for the restore procedures, because the backups are useful only
in the same line of incarnations that have the current database.

CONFIGURATION
The BACKUP command can change its behavior with configuration variables or parameters that
implement extra functionality. These variables define the behavior of some commands, or
defaults values when not explicitly stated.

To view these settings, there is the command "show all". These belong to the destination
database to which we are connected, and they are stored in the RMAN metadata.

oracle@oraculo:~> rman target /
Recovery Manager: Release 11.2.0.2.0 - Production on Thu Feb 9 16:16:00 2012
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: XE (DBID=2642191927)

RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name XE are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF;
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 COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD
TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/u01/app/oracle/product/11.2.0/xe/dbs/snapcf_XE.f'; # default

The variables that we must set in order to get our backup policy are:

• Device: we will use disk or tape (SBT)? The default installation uses disk. To use tape you
need to install and configure the use of a library provided by tape vendor, called media library
(MML).
5 Session #492


• Parallelism: using multiple channels simultaneously for backup or restore of the base. Is
defined at the DEVICE. Available in Enterprise.
• Retention Policy: For how long we want our backs available on disk?. This is controlled by
setting the RETENTION POLICY, which can be defined by RECOVERY WINDOW or
REDUNDANCY. The first is days during which backups must be kept, regardless of amount.
The second quantity is only backrests.
• Backup optimization: Do not copy existing files identical on destination. It is useful to shorten
time in operations that failed due to lack of space and can reuse the good copies when retried
(eg duplication)
• Encryption: to seamlessly protect generated backups against third parties. Requires
Advanced Security option for disk devices, or Oracle Secure Backup for tape devices.

Another important configuration setting is outside RMAN.
One is related to the use of the Fast Recovery Area (FRA). It is controlled by parameters in the
target database: DB_RECOVERY_FILE_DEST_SIZE and DB_RECOVERY_FILE_DEST.
With the first one we can put a logical maximum to the disk space used by files inside the FRA.
This is important because archivelogs are automatically deleted when obsoleted by RMAN, so we
only need to take care on proper setting its initial value, which must be big enough to allow all
the files needed by our retention policy.
The other important parameter to consider when not using a recovery catalog is
CONTROL_FILE_RECORD_KEEP_TIME. It defines the amount of days control file records are
reused. Its default value is 7. This must be set consistent to our backup policy, to avoid lose
backup records.

SEEING ITS CONTENTS
To see the generated files and their contents, use the "List backup" command. In this example,
as we are not using a recovery Catalog, this information is stored in the controlfile.
Adding the clause "summary" you can see a summary rather than detail.

oracle@oraculo:~> rman
Recovery Manager: Release 11.2.0.2.0 - Production on Fri Feb 17 11:00:13 2012

RMAN> connect target
connected to target database: ENT11G (DBID=410442782)

RMAN> list backup summary;
List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
1 B F A DISK 13-FEB-12 1 1 NO TAG20120213T122058

To view the full content of a specific backup (to avoid seeing all cataloged backups), we can filter
by backup attributes, like its label (TAG):

6 Session #492


RMAN> list backup tag TAG20120213T122058;

List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
1 Full 1.03M DISK 00:00:01 13-FEB-12
BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20120213T122058
Piece Name:
/u01/app/oracle/fast_recovery_area/ENT11G/backupset/2012_02_13/o1_mf_nnndf_TAG20120213T122058_7ml72cnz_.bkp

List of Datafiles in backup set 1
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ----
5 Full 1044143 13-FEB-12 /u02/oradata/ent11g/prueba.dbf

In this example you can see that it is a backup of a single datafile (prueba.dbf) and was stored in
the default destination (the Fast Recovery Area). This can be changed by adding the clause
'format /path-to-bkp' to the backup command.

NOTE: Dates displayed by these commands, as well as used as parameters to some commands
in RMAN can be changed with the NLS_DATE_FORMAT environment variable at the operating
system. For example to include the time:

[oracle@oraculo ~]$ export NLS_DATE_FORMAT='DD/MON/YYYY HH24:MI:SS'
[oracle@oraculo ~]$ rman target /
Recovery Manager: Release 10.2.0.3.0 - Production on Wed Dec 21 20:31:46 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: Ent11g (DBID=943234298)

RMAN> list backup summary tag bkp_prod_121511060003;

List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- -------------------- ------- ------- ---------- ---
1 B F A DISK 13/FEB/2012 03:21:03 1 1 NO TAG20120213T122058

BACKUPS WITH ORACLE XE
If you use Oracle XE, the installation includes scripts to backup and restore the database using
RMAN: backup.sh and restore.sh. They are in the $ORACLE_HOME/config /scripts/ directory. They
are a good starting point to take as an example and customize as you wish.

INCREMENTAL BACKUPS
In a database with several terabytes of data, a full backup can take longer that the time
available for maintenance tasks. With incremental backups this time can be reduced by copying
only the changed blocks since the last incremental backup.

There are two types of incremental backup: differential and cumulative.

7 Session #492


• Differential: copy only the changes since the last incremental backup
• Cumulative: copy all changes from the last full backup (level 0).

The level concept is similar to UNIX OS backup levels, but limited in the practice to 0 and 1,
instead of the 0-5 for OS. This simply provides a marker for which to reach back for the
increment or difference.
Therefore, to restore a database all differential backups are needed since the last full backup, or
the last cumulative backup following the last full backup. Incremental backups are differential by
default.

Example: the first incremental backup must be complete, and is identified with the level 0.

backup incremental level 0 tablespace users;

The next is level 1. If no level 0 backup exists when running a level 1, it creates a level 0 backup:

backup incremental level 1 tablespace users;

To take a cumulative backup:

backup incremental level 1 cumulative tablespace users;

If you have Enterprise version, you can enable the feature "Change Block Tracking" for this type
of backup. It keeps a bitmap of changed blocks of the database since it was enabled, avoiding to
analyze all the data blocks of the database each time the incremental backup is taken. This is
more efficient in scenarios where the total amount of changes are small compared to the size of
the database, so it needs to be evaluated to your specific environment. And is the way to handle
bigfile tablespaces.
As an example, using Oracle Managed Files (DB_CREATE_FILE_DEST parameter), it can be
enabled with this command, and then we can take the level 0 backup:

ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

Additionally, there are Incremental updated Backups, or merged incremental backups. This
allows you to take an incremental backup and apply it to the last full backup for a new full
backup, without reading all the destination database to create the full backup. The command to
take it is:

run {
backup incremental level 1 for recover of copy with tag 'BKP_L0' database;
recover copy of database with tag 'BKP_L0';
}

This type of backup requires more disk space, because it creates a new backup file in the default
destination. In the above example, only one copy is kept current at level 0, so a policy with
redundancy 1 is used. If we want to use a recovery window with more available copies, it is
8 Session #492


needed to add the clause 'UNTIL TIME ..' to the recover command. For more details on this type
of backup, see the Note "745798.1 Merged Incremental Backup Strategies".

COMPRESSION
There are several features in RMAN which helps in having more compact files.
The following prevents copying unnecessary blocks. They are built in and no configuration is
required to activate them:

• BLOCK COMPRESSION NULL (8i) - does not backup empty blocks never used (ie: unformatted
above High Water Mark (HWM))
• UNUSED BLOCK COMPRESSION (10.2) - does not backup unused blocks (ie: empty under
HWM)
• UNDO OPTIMIZATION (11.1) - does not backup undo segments from commited transactions
(considering UNDO_RETENTION).

A simple example to see the first optimization in action (NULL COMPRESSION) is to create a
tablespace and then make a backup:

oracle@oraculo:~> du -hs oradata/XE
1.5G .oradata/XE

oracle@oraculo:~> ls -lrt
/usr/lib/oracle/xe/app/oracle/flash_recovery_area/XE/backupset/2010_06_03/
total 1176688
-rw-r----- 1 oracle dba 1203748864 2010-06-03 00:57
o1_mf_nnndf_TAG20100603T005534_60g9xpkz_.bkp

The free space on the database is:

01:41:16 XE>select sum(bytes)/1024/1024 mb
from dba_free_space;
MB
----------
135.8125

Considering that RMAN does not include tempfiles nor redologs, 1.1Gb data were copied with
RMAN against 1.5Gb which they had copied manually.

The last feature, binary compression, must be explicitly enabled:

• Binary COMPRESSION (10g) - Compress data before sending it to the destination. It supports
incremental backups. Algorithm can be changed using the Advanced compression option
(11.2)

9 Session #492


There are two ways to take compressed backups: set it as the default method, or explicitly
stated in the BACKUP command.

a) Backup as compressed backupset …
b) CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;

The generated files are much smaller (from 1.1G to 200M), at the expense of using more CPU:

-rw-r----- 1 oracle dba 1203986432 2010-06-03 01:31
o1_mf_nnndf_TAG20100603T013020_60gcywnl_.bkp
-rw-r----- 1 oracle dba 235642880 2010-06-03 01:38
o1_mf_nnndf_TAG20100603T013720_60gdd066_.bkp

COMPRESSION WITH ORACLEXE

The script backup.sh does not have a parameter to create compressed backups. Also, if we
configured compression as our database default method (configure device...) It won't be used
because the script includes clauses which take precedence.

This choice can be justified because the maximum amount of data handled by XE is 11GB, and
with actual disk this size is not a problem, nor time required to manipulate this volume.

Furthermore, the same script backup.sh sets redundancy to 2. This ensures that we always have
a valid backup available, but not more than two. Then compression is even less necessary.

Both can be adjusted according to our policy, simply by modifying this script.
As an example, we take a backup without compression and with the compression setting:

a)
rman target /
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET;
exit;
./backup.sh

b)
rman target /
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
exit
./backup.sh

Once they finish, both generated files are identical:

ls -lrt /usr/lib/oracle/xe/app/oracle/flash_recovery_area/XE/backupset/2010_06_03/

10 Session #492


-rw-r----- 1 oracle dba 1203748864 2010-06-03 00:57
o1_mf_nnndf_TAG20100603T005534_60g9xpkz_.bkp
-rw-r----- 1 oracle dba 1203986432 2010-06-03 01:31
o1_mf_nnndf_TAG20100603T013020_60gcywnl_.bkp

Reviewing the content of the backup.sh script, we found:

echo "Backup in progress..."

rman target / >> $rman_backup << EOF
set echo on;
shutdown immediate;
startup mount;
configure retention policy to redundancy 2;
configure controlfile autobackup format for device type disk clear;
configure controlfile autobackup on;
sql "create pfile=''$rman_spfile2init'' from spfile";
backup as backupset device type disk database;
configure controlfile autobackup off;
alter database open;
delete noprompt obsolete;
EOF

The backup command explicitly includes parameters that indicate how to take backup, so it does
not consider the default values. If we are interested on taking compressed backups, we must
modify the code of the backup.sh script and include this explicitly:

...
backup as compressed backupset device type disk database;
...

INTEGRITY VALIDATION

By default, the BACKUP command validates block checksum when writing to destination
(physical integrity). Additionally, there are commands to validate logical integrity when taking
the backup, or directly on the data without the need for a backup, or over already taken backup
files.

To detect logical corruption in data blocks while taking the backup, the "check logical" clause
must be included :

backup blocks all check logical database;

To validate already taken backups, and their availability for the restore operation, the “validate”
clause must be included:

11 Session #492


restore validate database;
restore validate controlfile to 'c:tempcontrol01.ctl';
restore validate archivelog from sequence N1 until sequence N2;

Since version 11.1 we have the command VALIDATE,so this can be done independently of the
tasks of backup / recovery, with a variety of options that allows for example: validaing the entire
database, a specific backup, a datafile, and only a few blocks from a datafile:

validate database;
VALIDATE BACKUPSET 5;
validate datafile 3;
validate datafile 3 BLOCK 5 TO 20;

Also we can optimize validations executing it on parallel, distributing reading task over several
channels, taking advantage of the new parameter in 11.1 SECTION SIZE, which enables to split
the reading of a single datafile in smalls chunks:

RUN
{
ALLOCATE CHANNEL n1 DEVICE TYPE DISK;
ALLOCATE CHANNEL n2 DEVICE TYPE DISK;
VALIDATE DATAFILE 3 SECTION SIZE 1024M;
}

RECOVERY
There are several critical components in the database, and in case of isolated or combined
failures, there are many different scenarios and steps needed to recover the database to a
consistent state. In the official documentation there are 2 basic and 12 advanced cases.

To get just an overview on the subject, included here are only basic cases:

• recover the last full backup, using the existing controlfile:

RMAN> STARTUP MOUNT;
RMAN> RESTORE DATABASE;
RMAN> RECOVER DATABASE;
RMAN> ALTER DATABASE OPEN;

• recover only one tablespace in an open instance:

RMAN> SQL 'ALTER TABLESPACE mytbs OFFLINE IMMEDIATE';
RMAN> RESTORE TABLESPACE mytbs;
RMAN> RECOVER TABLESPACE mytbs;
RMAN> SQL 'ALTER TABLESPACE mytbs ONLINE';

It is important to note that:
• recovery uses backups known by the instance (cataloged), leaving in our hands ensuring
consistency with what we have available. This involves the tasks of obtaining appropriate

12 Session #492


backups from our archived media (tapes, DVD, etc), use the right controlfile for the set of
backups to be used, and catalog them in the destination database (either controlfile or
catalog).
• backups are useful only in the same line of incarnations known by the current database, so
the controlfile to use is critical.
• recovery is to a point in time, so we must have the appropriate sequence of full backups and
archivelogs (or incremental backups) to reach to the required point. In high-volume
databases, to detect that this is not working may take several hours, so it is imperative to
have a periodic test of these procedures, to anticipate any failures at a time where we have
time to analyze and correct them without pressure.

¿WHAT TO DO IF I STILL DO NOT USE RMAN?
After seeing the advantages of RMAN and the time we can save by adding it to our backup
policy, we have to plan the steps to get started.

The first is to define the policy, including the following:
• acceptable level of service:
• time frame for implementation and execution
• disk consumption and CPU usage expected to define the use of compression
• retention
• destination
• generated file names
• use of parallelism
• maximum sizes of files generated
• use of encryption

With these definitions, the RMAN environment must be configured at each database. A script can
be created to perform this configuration, and although it will be used only the first time RMAN be
used by our database, it will serve as a backup of the configuration and will be part of the
process of recreating the database on a new server .

Then it should implement the scripts that run the backup. They should incorporate controls to be
complete, and in addition to the statements that actually take the backup, should include:
• Delete obsolete backups
• List catalog (documentation)
• Validate logical integrity
• Detect errors in the execution of the script and notify operators

Once the backups are working, we must remember that you must practice the various recovery
scenarios, and run backups regularly taken to validate that there are no errors in the process, or
on the destinations where they reside (tapes, CD, external drives, etc..).

13 Session #492


NOTE: remember that the RMAN-generated files are not portable between platforms, so a backup
taken on Intel 32-bit (x86) can not be restored on Intel 64-bit (x86_64). There is an RMAN
command , CONVERT DATABASE, which works only over platforms which share the endian
format. Details of this on “Transporting Data Across Platfroms”,
http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmxplat.htm#CHDFHBFI

ADITIONAL TASKS

MONITORING

To validate the progress of a backup operation, the view V$SESSION_LONGOPS may be used
while the operation is running, with a query like this:

SELECT SID, SERIAL#, CONTEXT, SOFAR, TOTALWORK,
ROUND(SOFAR/TOTALWORK*100,2) "%_COMPLETE"
FROM V$SESSION_LONGOPS
WHERE OPNAME LIKE 'RMAN%'
AND OPNAME NOT LIKE '%aggregate%'
AND TOTALWORK != 0
AND SOFAR <> TOTALWORK;

To see the result of executed commands in RMAN since the last start of the base, the view
V$RMAN_OUTPUT may be used, which exists only in memory.
To view the status of the tasks performed or in progress, there is the view V$RMAN_STATUS.

To view the backups that have been taken on the current database, we may use the views:
• V$BACKUP_SET
• V$BACKUP_SET_DETAILS
• v$BACKUP_DATAFILE
• V$RMAN_BACKUP_JOB_DETAILS

If using a catalog, then there is more metadata available in RC_* views.

Finally, after running the command VALIDATE, if bad blocks are detected they appear in the
system view V$DATABASE_BLOCK_CORRUPTION.

MANTEINANCE

Our backup scripts should include crosscheck statements to detect backup files deleted outside
RMAN, and statements to periodically delete obsolete backups.
Both statements may be included in our backup script daily or weekly, or run separately.

In the case of having a standby database, from version 11.1 the deletion of obsolete can be done
14 Session #492


immediately to the back, having set the ARCHIVELOG DELETION POLICY TO APPLIED ON
STANDBY. In previous versions, the deletion of archivelogs must be separated from the backup
to ensure that archivelogs can be sent to the standby before being deleted.

if using the Fast Recovery Area, archivelogs are automatically deleted when obsoleted by the
retention policy. Also there are disk quota rules for deletion when free space is needed, who can
decide to delete files which are not obsoleted but has been backed up. For more details about
this, http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmcncpt.htm

WHEN ERRORS

The most common errors with RMAN are caused by recovery procedures using incorrect backup
files or controlfiles, such as:

RMAN-03002: failure of restore command at 12/20/2011 08:08:22
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 17 found to restore

In case of errors that put health of our procedures in doubt, the first thing to do is to validate
that we are doing the right thing by checking the official documentation (http://otn.oracle.com)
and My Oracle Support (http://support.oracle. com).

If you already did that and want to analyze the steps RMAN took to get the error, then you can
enable DEBUG in backup / restore commands, and use TRACE to see the channel's activity:

rman target / log rman.log trace rman.trc
run{
allocate channel t1 type sbt………trace=2;
debug on;
restore database;
debug off;
}

Thus we see all the internal operations performed by RMAN that can serve as a guide to track
the problem.

To address problems with the use of tape devices, it must be remembered that Media manager
libraries (MML) are from third parties, and therefore can not be controlled with RMAN commands,
We must review the documentation provided by the manufacturer.
Enabling trace on the channel generates a file called sbtio.log, with information generated by the
MML. This must be validated with the manufacturer.
Another alternative is to use the simulation driver provided by Oracle, DISKSBT:

run {

15 Session #492


allocate channel t1 type sbt parms
'SBT_LIBRARY=oracle.disksbt,ENV=(BACKUP_DIR=d:temp)' trace=2;
backup database;
}

This way it will rule out that the problem is in the read operation or at our instalation, thus we
can advance in the diagnosis and if necessary pass the problem to the manufacturer of the tape
drive.

OPTIMIZATION

Server running RMAN tasks increases mainly its I/O activity, so we should look to optimize the
access time to devices.

The points to check are:
• using async I/O (O.S. configuration)
• adequate parallelism (channels) to amount of tapes slots of the hardware
• performance of the MML
• identify whether the problem is in reading or writing.
• for example, comparing the time of "backup validate" (read-only operation) with the
time of backup.
• if using incremental backups and Enterprise Edition, enable block change tracking.
• to know the RMAN process architecture in detail helps in the optimization process. The MOS
note 360443.1 "RMAN Backup Performance" goes deeper on it.
• to use the standby database if Active DataGuard is available.

Since version 11.1 SECTION SIZE parameter exists, which allows to generate a backup piece of a
single datafile using smaller chunks (sections) in parallel, thus produce it in less time.
For example, to back up a tablespace with a datafile of 900Mb using three parallel channels:

CONFIGURE DEVICE TYPE sbt PARALLELISM 3;
CONFIGURE DEFAULT DEVICE TYPE TO sbt;
RUN {
BACKUP SECTION SIZE 300M TABLESPACE prueba;
}

For recovery operations, we must remember that the content of the scripts are executed serially.
For example, if we want to leverage that we have three tape drives and want to access them in
parallel, this sequence does not succeed:

run {
allocate channel t1 type sbt....;
restore datafile 2;
restore datafile 3;
16 Session #492


restore datafile 5;
restore datafile 7;
restore datafile 11;
}

Since the smallest unit of reading up to 11.1 was the datafile, the way of using channels in
parallel is:

run {
restore datafile 2,3,5,7,11;
}

BACKUP REPOSITORY (CATALOG) EXTERNAL

We can configure a database which is used exclusively as a repository of all information
maintained by RMAN. If you manage a single database, this can add a task management too. But
if you work with many, it gives us the possibility to have this information centrally.

FEATURES AVAILABLE ON ENTERPRISE EDITION ONLY

Remember that the following features are not available in Standard Edition:
• allocate disk parallel channels
• block change tracking
• encryption -- Advanced Security option or Oracle Secure Backup license

EXAMPLES

Here are some examples of using RMAN for specific tasks:

CLONING
Rman has the DUPLICATE command wich automates the process of creating a clone of a
database. Since version 11.2 there are many ways to clone a database: from active database,
and from pre-existing backups. This last one also could be connected or not to a target database,
and to a catalog. All the details about this can be found in the manual:
http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmdupdb.htm
As an example, we will see how to duplicate a database to a remote host with the same directory
structure, in 10g and in 11.2, assuming Oracle Net Connectivity has been already configured on
the new server to the source database.

17 Session #492


10G CLONING
These steps must be performed to implement a clone that can be automated without manual
intervention. Remember that the database created by cloning is done over the AUXILIAR
connection, and the source database is the RMAN TARGET connection.

1. set destination database environment: parameter file, password file and directories

2. reboot the destination database in nomount mode

3. get the SCN to which you want to restore from the source database. There are several ways
to do it. One possible is to look past SCN backed archivelogs with the following query:

select next_change#
from v$archived_log
where recid = (select max(recid) from v$archived_log
where backup_count>0);

4. execute the duplication on destination server:

rman catalog rman/clave@rman target sys/clave@origen
connect auxiliary /
run {
allocate auxiliary channel dupdb1 type disk;
set until scn $MAX_SCN;
duplicate target database to COPIA NOFILENAMECHECK;
}

5. disable archivelog on the cloned database

ONLINE CLONING (> 11.1)

Same 1 and 2 steps, and the 4th is:

rman nocatalog target sys/clave@origen
connect AUXILIARY sys/clave@copia
run {
DUPLICATE TARGET DATABASE TO 'COPIA' FROM ACTIVE DATABASE
PASSWORD FILE SPFILE NOFILENAMECHECK SET SGA_TARGET=1000M;
}
exit;

18 Session #492


CLONING A RAC DATABASE

Cloning a database in a RAC environment is similar to the single instance procedure, with the
following changes:

• pfile on destination database is configured as single instance (removing RAC configuration)
• clone the same way as single instance
• pfile parameters are adjusted, adding RAC settings removed before, and putting the correct
names for the control_files and the new database.
• restart the database to use the new parameters
• configure the new database in all the remaining RAC nodes: pfile, pwfile, tnsnames.ora
• once cloned, you must register the new database in CRS

Details of this procedure can be found in My Oracle Support notes 461479.1 and 452868.1

DATA RECOVERY ADVISOR

This functionality, available since version 11.1, analyze failures on the database and
recommends actions to correct them, having the possibility to execute the recommended scripts.
In this example we simulate the loss of a datafile:

oracle@test:> rm /u01/app/oracle/oradata/test11/users01.dbf

oracle@test:> rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Thu Jun 3 14:07:35 2010
connected to target database: TEST11 (DBID=3428713062)

RMAN> validate database;

Starting validate at 03-JUN-10
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=68 device type=DISK
RMAN-06169: could not read file header for datafile 4 error reason 5
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of validate command at 06/03/2010 14:07:50
RMAN-06056: could not access datafile 4

RMAN> list failure;

List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------

19 Session #492


122 HIGH OPEN 03-JUN-10 One or more non-system datafiles are
missing

RMAN> advise failure all;

List of Database Failures
=========================
Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- -------
122 HIGH OPEN 03-JUN-10 One or more non-system datafiles are
missing

analyzing automatic repair options; this may take some time
using channel ORA_DISK_1
analyzing automatic repair options complete

Mandatory Manual Actions
========================
no manual actions available

Optional Manual Actions
=======================
1. If file /u01/app/oracle/oradata/test11/users01.dbf was unintentionally renamed
or moved, restore it

Automated Repair Options
========================
Option Repair Description
------ ------------------
1 Restore and recover datafile 4

Strategy: The repair includes complete media recovery with no data loss
Repair script: /u01/app/oracle/diag/rdbms/test11/test11/hm/reco_2784754173.hm

The repair script has the following code:

# restore and recover datafile
sql 'alter database datafile 4 offline';
restore datafile 4;
recover datafile 4;
sql 'alter database datafile 4 online';

These steps are correct because we have a cataloged backup on our database, and available.
If this were not the case, the recommendation would be different:

analyzing automatic repair options; this may take some time
analyzing automatic repair options complete

Mandatory Manual Actions
========================

20 Session #492


1. If file /u01/app/oracle/oradata/test11/users01.dbf was unintentionally renamed
or moved, restore it
2. If you have an export of tablespace USERS, then drop and re-create the
tablespace and import the data.
3. Contact Oracle Support Services if the preceding recommendations cannot be used,
or if they do not fix the failures selected for repair

Optional Manual Actions
=======================
no manual actions available

Automated Repair Options
========================
no automatic repair options available

Back to the first case, having the backup known to the catalog, we accept to execute the
recommendation:

RMAN> repair failure;

Strategy: The repair includes complete media recovery with no data loss
Repair script: /u01/app/oracle/diag/rdbms/test11/test11/hm/reco_3604648805.hm

contents of repair script:
# restore and recover datafile
sql 'alter database datafile 4 offline';
restore datafile 4;
recover datafile 4;
sql 'alter database datafile 4 online';

Do you really want to execute the above repair (enter YES or NO)? Yes

executing repair script

sql statement: alter database datafile 4 offline

Starting restore at 03-JUN-10
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 00004 to
/u01/app/oracle/oradata/test11/users01.dbf
channel ORA_DISK_1: reading from backup piece
/u01/app/oracle/flash_recovery_area/TEST11/backupset/2010_06_03/o1_mf_nnndf_TAG2010
0603T140513_60hr69ob_.bkp
channel ORA_DISK_1: piece
handle=/u01/app/oracle/flash_recovery_area/TEST11/backupset/2010_06_03/o1_mf_nnndf_
TAG20100603T140513_60hr69ob_.bkp tag=TAG20100603T140513
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
Finished restore at 03-JUN-10

Starting recover at 03-JUN-10

21 Session #492


starting media recovery
media recovery complete, elapsed time: 00:00:00

Finished recover at 03-JUN-10
sql statement: alter database datafile 4 online
repair failure complete

NEXT STEPS?
This paper provides a guide to start using RMAN. There are many areas to expand. The following
are some suggestions to continue:
• Exercise recovery scenarios separating roles of DBA's with one group generating failures and
the other trying to fix them.
• Using Enterprise Manager (EM). Many common operations with RMAN have their own screens
inside EM (ie: cloning, backup), so it is recommended to move as much as possible of our
backup policy to EM to take advantage of its reporting mechanisms, alerting and centralized
management.
• Learn and incorporate additional high availability functionalities included on Oracle
databases, such as Dataguard and Flashback.

REFERENCES
Oracle® Database Backup and Recovery Basics - 10.2
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14192/toc.htm

Oracle® Database Backup and Recovery Advanced User's Guide - 10.2
http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/toc.htm

Oracle® Database Backup and Recovery User's Guide – 11.2
http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/toc.htm

What's New in Backup and Recovery?
11.1 - http://docs.oracle.com/cd/B28359_01/backup.111/b28270/wnbradv.htm
11.2 - http://docs.oracle.com/cd/E24693_01/backup.11203/e10642/wnbradv.htm

MOS note 360443.1 - RMAN Backup Performance
MOS note 740911.1 - RMAN Restore Performance
MOS note 1116484.1 - Oracle Support Master Note For Oracle Recovery Manager (RMAN)

22 Session #492

RMAN - Eliminate the Mystery of Oracle Backups

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to RMAN - Eliminate the Mystery of Oracle Backups

Similar to RMAN - Eliminate the Mystery of Oracle Backups (20)

More from Nelson Calero

More from Nelson Calero (20)

Recently uploaded

Recently uploaded (20)

RMAN - Eliminate the Mystery of Oracle Backups