Overview

The main Oracle tool for database backup and recovery is Recovery Manager (RMAN). RMAN is a superb tool for both backing up and restoring your database. You should be using this because no one knows how to backup and restore an Oracle database better than Oracle. Plus it is free. If you ever have an event where you will need to contact Oracle support to restore or recover data, in most cases they will require a standard and recent RMAN backup of your database.

With RMAN it is vital to ensure two things before you ever need to perform a restore operation:

1. The records required to do this will still be in your control file.
2. The corresponding backupset files are available on the backup media.

The spfile CONTROL_FILE_RECORD_KEEP_TIME (CFRKT) parameter determines how long RMAN backup records are stored (in the control file). The RMAN setting for the RETENTION POLICY TO RECOVERY WINDOW OF n DAYS determines when backup set files will become OBSOLETE and can be deleted from disk or tape.

Control files in an Oracle databases contain a circular reuse area. It is in this area that RMAN information is stored. The control file will grow in size as needed to retain information in this area based on your CFRKT settings. For extreme control of long term backups a dedicated Oracle Management Server (OMS) can be created. With an OMS a "catalog" is used in addition to the control file.

Traditional RMAN backups do not automatically delete backupset files from disk or tape. To delete them in a way that RMAN "knows" about, you must use the DELETE OBSOLETE command routinely. This will delete all physical backup set files that are older than your RETENTION POLICY TO RECOVERY WINDOW value and update the control file accordingly.

To ensure that your control file is in sync with those files already actually on disk, you must issue the corresponding CROSSCHECK command. If your RMAN backups go to disk, and are also backed up via an OS backup to tape, then you have to run a CROSSCHECK after restoring the backupset files from tape.

Essential RMAN Concepts

RMAN> show all;
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'C:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\SNCFDB1.ORA'; #default

RMAN Incremental Merge Backups

For Oracle Database 10g and later Oracle recommends backing up your database using RMAN Incremental Merge Backups (IMB) rather than the traditional method. This method of using RMAN works by creating incrementally updated backups that apply incremental database changes to a corresponding image copy backup. Incremental Merge Backup is Oracle's official name for this method. Oracle also refers to it as Incrementally Updated Backup in some texts.

This strategy offers the following benefits:

• Other than the initial image copy creation, all subsequent backups are incremental thus take dramatically less time.
• Restore operations are significantly faster than traditional RMAN backed up databases.
• IMB are self maintaining, i.e. they do not require the routine overhead of crosschecks & deletion of obsolete backup pieces.
• The syntax for RMAN restore and recover operations is the same as the traditional method.
• You also have the added option where, in case of failure, you only need to execute "switch database to copy" and the database will immediately start to work with the image copy datafiles.

The only downside to using IMB is that it takes up more disk space. You should test IMB for yourself to prove\disprove if this is a real problem for you. IMB is based on the concept that disk technology is getting cheaper, more disks can be used for backup purposes.

If you do not have the disk space use the traditional RMAN backup method. Also, according to Oracle, OS level disk compression cannot be used to implement IMB. If OS level disk compression is enabled database failure and data corruption will occur at some point.

Understanding IMB

Configure
RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE disk FORMAT 'R:\rman\%%U.bkp';
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP on;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE disk TO 'R:\rman\%%F';
RMAN> CONFIGURE DEVICE TYPE disk BACKUP TYPE TO compressed backupset;
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'R:\rman\snapshot.ctl';

RMAN> CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK clear;
RMAN> CONFIGURE BACKUP OPTIMIZATION clear;
RMAN> CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK clear;
RMAN> CONFIGURE DEFAULT DEVICE TYPE clear;
RMAN> CONFIGURE MAXSETSIZE clear;
RMAN> CONFIGURE RETENTION POLICY clear;

Backup
RMAN> run {
recover copy of database with tag 'incremental_merge_backup';
backup incremental level 1 cumulative  copies=1 for recover of copy with tag 'incremental_merge_backup' database;
}

During the initial run:

• The RECOVER command actually has no effect, because it cannot find any incremental backups with a tag of incremental_merge_backup.
• However, the BACKUP command will create a new Incremental Level 0 backup that is labeled with a tag of incremental_merge_backup because no backups have been created yet with this tag.

During the second run:

• The RECOVER command still will have no effect, because it cannot find any Level 1 incremental backups with a tag of incremental_merge_backup.
• The BACKUP command will create its first Incremental Level 1 backup that is labeled with a tag of incremental_merge_backup.

During the third and subsequent runs:

• The RECOVER command finds the incremental level 1 image copy backups from the previous night's run tagged as incremental_merge_backup and applies them to the existing datafile image copies.
• The BACKUP command will create the next Incremental Level 1 backup that is labeled with a tag of incremental_merge_backup.

After the third run RMAN would then choose the following files during a media recovery scenario:

• The image copy of the database tagged as incremental_merge_backup.
• The most recent incremental level 1 backup.
• All archived redo logs since the image copy was taken.

Oracle Block Change Tracking

Block Change Tracking can dramatically improve the performance of incremental backups. With Block Change Tracking RMAN no longer needs to scan all the blocks in the datafiles to find changed blocks. This is because it uses a tracking file to identify changed blocks for incremental backups. Enabling this starts a new background process called Change Tracking Writer (CTWR) that manages the tracking file. This feature requires the Enterprise Edition.