Planning your RMAN Implementation

A DBA can be forgiven almost anything except a failed recovery. If you are unable to restore
and recover a production database well lets not even go there!
This post will highlight some of the areas you need to configure to setup an effective backup
strategy using RMAN.
What needs to be backed up?
Datafiles
Controlfiles
Archivelogs
Parameter files
Network configuration Files
Wallets
Password files
Oracle Home
The first four items on this list can be backed up using RMAN, the remaining items will require
an alternative backup method such as an OS Copy or Netbackup Snapshot
Where should the backups be stored?
If you plan to use a Flash Recovery Area(FRA) or to backup to disk, ensure that the FRA is not
created on the same disks as the database. Otherwise, the disk becomes a single point of failure.
It is best practice to copy your backups off the server and preferably store a copy off site.
If your backups are going straight to tape, it is good practice to keep your archivelogs available
on disk for as long as possible as this will help reduce recovery time.
To set up the FRA:
alter system set db_recovery_file_dest=path to a separate disk
alter system set db_recovery_file_dest_size= (Ideally you would create this area big enough to
save all backups copies, as a minimum it should be large enough to hold the backups and archive
log files that are not copied to tapes yet)
How long should I keep the backup?
This will depend on the SLA agreements you have in place. If for instance you have committed
to providing Point in Time recovery to any time during the last month, you would need to keep
all archivelog backups for one month, plus the Level 0 backup taken at the start of the period, it
would also be wise to keep the subsequent Level 0s and Level 1s to reduce recovery time.
If on the other hand you only agree to restore to the start of the previous business day, then you
only need to keep the backups for two days.
A recommended backup strategy for an OLTP environment?

This strategy would be used to recover a database to any point in time during the last four weeks.
The data in the database is dynamic and changes frequently, there are no static tables.
An RMAN catalog is used and the backups are written to the FRA on disk.
Configuring RMAN
export ORACLE_SID=PROD1
[oracle@dbserver ~]$ rman
RMAN> connect target /
RMAN> connect catalog rman_owner/***@RMAN
Ensure that RMAN retains all backups needed to recover the database to any point in time in the
last 32 days:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 32 DAYS;
Backup optimization skips the backup of files in certain circumstances if the identical file or an
identical version of the file has already been backed up. For example if a particular backup fails
and is resubmitted.
A datafile backup needs to have the same dbid, checkpoint, and resetlogs data in order to be
ignored during the next backup.
For archive logs, the same file means the same dbid, thread, sequence, and resetlogs data.
RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
As backup information is stored in the controlfile, as well as datafile info etc, it is recommened
that RMAN automatically backs up the control file and the current server parameter file (if used
to start up the database) whenever a successful backup completes.
This will enable you to recover even if you lose the current controlfile.
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
Set the location of the controlfile autobackup to a separate location to your database files and
controlfile.
The sting you enter must contain the substitution variable %F (and no other substitution
variables)
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE
DISK TO /data/PROD1/%F';
Depending on the number of IO devices available on the server, set up the number of channels
that will be used by default for all backups and restores.
This saves on creating channels at the beginning of every script.
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO
BACKUPSET;
When RMAN needs to resynchronize the recovery catalog with a read-consistent version of the
control file, it creates a temporary snapshot control file.
The default location for the snapshot control file is platform-specific and depends on the Oracle

home of each target database.

You can change the location to ensure you do not fill up the Oracle Home filesystem
RMAN>CONFIGURE SNAPSHOT CONTROLFILE NAME TO
/home/oracle/snapshots/snapcf_PROD1.f'; # default
Configure the database
To enable hot backups and point in time recovery that database needs to be in archivelog mode.
To check if the database is already in archivelog mode issue this query:
select LOG_MODE from v$database;
If the output is not ARCHIVELOG then follow these instructions to set up archiving, ensure you
have set up the FRA beforehand.
sqlplus / as sysdba
Shutdown immediate
startup mount
alter database archivelog;
alter database open;
The strategy I am going to suggest in the trailing paragraphs makes use of incremental backups.
To speed up the level 1 incrementals create a block change tracking file as follows:
sqlplus / as sysdba
alter database enable block change tracking using file path and name to new file';
The block change tracking file keeps track of changed database blocks since the last backup. It is
referenced during backups so that RMAN avoids reading entire files to find the changed blocks.
Configure the backups
Monthly Backup
We begin by creating the Monthly backup script.
This will be a Level 0 incremental backup that is similar to a full backup, but can be used for
subsequent incremental Level 1 backups.
This script will be scheduled to run the first weekend of every month
As we already configured the channels in RMAN there is no need to reconfigure them in the
backup.
As we already configured RMAN to always include the controlfile it is not necessary to include
it in the script.

[oracle@dbserver ~]$ rman

RMAN> connect target /
RMAN> connect catalog rman_owner/***@RMAN
run {
backup incremental level 0 DATABASE plus ARCHIVELOG TAG MONTHLY_BACKUP;
sql alter system archive log current;
DELETE NOPROMPT OBSOLETE RECOVERY WINDOW OF 31 DAYS;
}
Weekly Backup
This will be a level 1 incremental backup.An incremental backup copies only data file blocks
that have changed since a specified previous backup.
An incremental backup can be cumulative or differential.We will use a a cumulative level 1
backup for the weekly backup that will be taken every Week-end except the first week-end of the
month.
The cumulative backup will backup all block changes since the last level 0.
run {
backup incremental level 1 CUMULATIVE DATABASE plus ARCHIVELOG TAG
WEEKLY_BACKUP;
sql alter system archive log current;
DELETE NOPROMPT OBSOLETE RECOVERY WINDOW OF 31 DAYS;
}
Daily Backup
For the daily backup we will use a level 1 DIFFERENTIAL backup. This will backup all block
changes since the last level 0 or the last level 1.
By default incremental backups are differential, this backup would run every night except on
week-ends when the monthly or daily backup is executed.
run {
backup incremental level 1 DATABASE plus ARCHIVELOG TAG DAILY_BACKUP;
sql alter system archive log current;
DELETE NOPROMPT OBSOLETE RECOVERY WINDOW OF 31 DAYS;
}
The advantages of this backup strategy is that in the event of a recovery you would only ever
need to apply more than a day of redo for complete recovery.
Other considerations
This strategy writes all backups to disk, this could become expensive in terms of storage. It is
advisable to backup the FRA when the backup completes.

This script will require an agent for media library is installed & Media management layer(MML)
is configured correctly.
An example of MML is Netbackup and the agent will warrant a license.
RUN
{
ALLOCATE CHANNEL ch00 TYPE SBT_TAPE;
ALLOCATE CHANNEL ch01 TYPE SBT_TAPE;
BACKUP RECOVERY AREA DELETE INPUT;
RELEASE CHANNEL ch00;
RELEASE CHANNEL ch01;
}
As of 11g you can also backup the FRA via a NFS attached file system. We would use the
BACKUP RECOVERY AREA TO DESTINATION clause to accomplish this.
It could be useful to move the backup to cheaper storage, but mostly, it is much faster to restore
from disk, and it is not wise to leave the backups on the same server as the database.
Considerations for Data Warehouse
The strategy listed above would also work for DSS environments, but you might want to
consider moving data in historic tablespaces into READ ONLY mode to avoid backing them up.
As the backups will become obsolete after 31 days, you could move the READ ONLY
tablespaces into READ WRITE shortly before you perform your monthly backup.
The alternative is to do a separate backup of the historic data, vault it so that it never expires and
then move the tablespaces into READ ONLY mode permanently.
Backup using Image Copy Example
Alternative backup strategy using incremental image copies. This strategy needs the same
amount of storage as the database uses as it makes a physical copy of the database.
RUN
{
RECOVER COPY OF DATABASE
WITH TAG incr_update';
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG incr_update
DATABASE;
}
The first time this script run it will create an image copy of the database, it will not recover any
incrementals or apply them as none exist.
The next time it runs it will create and incremental copy of the changed blocks and again will not
recover or apply the changes to the image copy.

The third time it runs it will apply the previous days incremental to the image copy and take
another incremental.
This strategy provides very fast recovery as you can use the RMAN SWITCH TO COPY
command to switch to the copy, then apply only the archives you want to get you back to where
you want to be.
The example only allows a 24 hour recovery window, this can be increased by adding the UNTIL
TIME SYSDATE x as in the following example.
RUN
{
RECOVER COPY OF DATABASE
WITH TAG incr_update
UNTIL TIME SYSDATE 31;
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG incr_update
DATABASE;
}