RMAN Environment overview

Overview of the RMAN Environment

Installed with the database, Recovery Manager (RMAN) is an Oracle database client which performs backup and recovery tasks on your databases and automates administration of your backup strategies. It greatly simplifies backing up, restoring, and recovering the database.

The RMAN environment consists of the utilities and databases that play a role in backing up your data. At a minimum, the environment for RMAN must include the following: 

• The target database.  This is the database to be backed up by RMAN.
• The RMAN client is a command-line-oriented database client, much like SQL*Plus, with its own command syntax. From the RMAN client you can issue RMAN commands and some SQL statements to perform and report on backup and recovery operations.

Some environments will also use these optional components:

• A flash recovery area:  a disk location in which the database can store and manage files related to backup and recovery.
• Media management software:  software provided by media manager vendors which is required for RMAN to interface with backup devices such as tape drives.
• A recovery catalog database:  a separate database schema used to record RMAN activity against one or more target databases.

Deciding Whether to Use a Flash Recovery Area (FRA)

It is recommended that you take advantage of the FRA to store as many backup and recovery-related files as as possible, including disk backups and archived redo logs.

Some features of Oracle database backup and recovery, such as Oracle Flashback Database and guaranteed restore points, require the use of an FRA. However, having an FRA for use by these features does not force you to use it to store all recovery-related files.

Even when its use is not required, however, the FRA offers a number of advantages over other on-disk backup storage methods. Backups moved to tape from the flash recovery area (via RMAN and media manager) are retained on disk until space is needed for other required files, reducing the need to restore backups from tape. At the same time, obsolete files no longer needed to meet your recoverability goals and files backed up to tape become eligible for deletion and are deleted when space is needed. These deletions are managed by Oracle when space is required.  The DBA no longer has to manually delete old backups, and, it is less likely that a DBA accidentally deletes redundancy set files.  Note that if backups written to the FRA are not copied via RMAN and media manager to tape, the automatic deletion of obsolete backups does not occur and pre-Oracle10g cleanup methods are required.

Knowledgebase Article Reference:

Deciding Whether to use a Recovery Catalog

RMAN maintains metadata about the target database and its backup and recovery operations in the RMAN repository. Among other things, RMAN stores information about its own configuration settings, the target database schema, archived redo logs, and all backup files on disk or tape. RMAN's LIST, REPORT, and SHOW commands display RMAN repository information.

The primary store for RMAN repository data is always the control file of the target database. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter controls how long backup records are kept in the control file before those records are re-used to hold information about more recent backups.

Another copy of the RMAN repository data can also be saved in the recovery catalog.

Using a recovery catalog preserves RMAN repository information if the control file is lost, making it much easier to restore and recover following the loss of the control file. (A backup control file may not contain complete information about recent available backups.) The recovery catalog can also store a much more extensive history of your backups than the control file, due to limits on the number of control file records.

In addition to RMAN repository records, the recovery catalog can also hold RMAN stored scripts, sequences of RMAN commands for common backup tasks. Centralized storage of scripts in recovery catalog can be more convenient than working with command files.

Except for stored scripts, all of RMAN's features work equally well with or without a recovery catalog.

Starting and Exiting RMAN

The RMAN client is started by issuing the rman command at the command prompt of your operating system.
RMAN must connect to a target database (with SYSDBA privileges) to perform backup and recovery tasks. RMAN can also connect to a recovery catalog database if you are using one. Specify target and recovery catalog databases using command line options or using the CONNECT command.

This command illustrates connecting RMAN to a target database and a recovery catalog at startup:

% rman TARGET / CATALOG cat_usr/pwd@cat_str

Connect to a target database without using a recovery catalog:

% rman TARGET SYS/pwd@target_str

Starting RMAN without connecting to a database:

% rman

Once started, RMAN displays an "RMAN>" prompt for your commands.

Configuring Persistent Settings for the RMAN Environment

You can use the RMAN CONFIGURE command to create persistent settings in the RMAN environment, which apply to all subsequent operations, even if you exit and restart RMAN. These configured settings can specify disk and SBT channel behavior, backup destinations, policies affecting backup strategy, and others.

This command shows all configurable settings:

RMAN> SHOW ALL;

Backing up the Controlfile and Spfile

The control file can be automatically backed up after each RMAN backup and database structure change as a way to protect the RMAN repository.  If an spfile is being used, it is also backed up.  When using RMAN without a recovery catalog, it is recommended that the controlfile autobackup be set to ON.  The following command configures RMAN to create these control file autobackups:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

By default, RMAN automatically generates names for control file autobackups and stores them in the FRA if defined. The following command configures RMAN to write control file autobackups to the /mybackupdir directory:

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT
      FOR DEVICE TYPE DISK TO '/mybackupdir/cf%F';

The %F element of the format string combines the DBID, day, month, year, and sequence number to generate a unique filename. %F must be included in any control file autobackup format.

You can back up the control file when the database is mounted or open. RMAN uses a snapshot control file to ensure a read-consistent version. If CONFIGURE CONTROLFILE AUTOBACKUP is ON (by default it is OFF), then RMAN automatically backs up the control file and server parameter file after every backup and after database structural changes. The controlfile autobackup contains metadata about the previous backup, which is crucial for disaster recovery.  Configuring controlfile autobackup on is recommended and is the only way RMAN can restore a controlfile backup if all controlfiles are lost and there is no recovery catalog in use.

If the autobackup feature is not set, then you must manually back up the control file in one of the following ways:

• Run BACKUP CURRENT CONTROLFILE
• Include a backup of the control file within any backup by using the INCLUDE CURRENT CONTROLFILE option of the BACKUP command
• Back up datafile 1, because RMAN automatically includes the control file and SPFILE in backups of datafile 1 when the controlfile autobackup is set to OFF.

A manual backup of the control file is not the same as a control file autobackup. In manual backups, only RMAN repository data for backups within the current RMAN session is in the control file backup, and a manually backed-up control file cannot be automatically restored.

Backing up Database Files

Use the RMAN BACKUP command to back up files. You can configure default devices and channels in advance.  The BACKUP command backs up your data to the configured default device and channels for the type of backup requested.

If you specify BACKUP AS COPY, then RMAN copies the files as image copies, bit-for-bit copies of database files created on disk. These are identical to copies of the same files that you can create with operating system commands like cp on Unix or COPY on Windows.  However, using BACKUP AS COPY will be recorded in the RMAN repository and RMAN can use them in restore operations. Image copies cannot be created on tape.

This command creates image copy backups of all datafiles in the database:

RMAN> BACKUP AS COPY DATABASE;

If you specify BACKUP AS BACKUPSET, then RMAN stores its backups in backup sets. A backup set, consisting of one or more backup pieces, contains the physical file data being backed up.  This backupset is written in a format that only RMAN can access. Only RMAN can create and restore backup sets. Backup sets can be written to disk or tape, and they are the only type of backup which RMAN can use to write backups to tape.

The following command creates a backup of the database and archived logs on tape, in backup set format, using the configured channels:

RMAN> BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG;

Note:
Backing up datafiles as backup sets on disk can save disk space and time because RMAN will skip backing up some unused datafile blocks. Backup sets, once written on disk, can be moved to tape with the BACKUP BACKUPSET command. See the description of unused block compression in Oracle Database Backup and Recovery Reference for details.

Backing Up Individual Files

You can back up individual tablespaces, datafiles and control files, server parameter files, and backup sets with various options, as in these examples:

RMAN> BACKUP ARCHIVELOG from time 'sysdate-2';

RMAN> BACKUP TABLESPACE system, users, tools;

RMAN> BACKUP AS BACKUPSET DATAFILE
'ORACLE_HOME/oradata/trgt/users01.dbf',
'ORACLE_HOME/oradata/trg/tools01.dbf';

RMAN> BACKUP DATAFILE 1,3,5;

RMAN> BACKUP CURRENT CONTROLFILE TO '/backup/curr_cf.copy';

RMAN> BACKUP SPFILE;

RMAN> BACKUP BACKUPSET ALL;

Backup Options

Here are some often-used BACKUP command options:

Parameter                                Example                        Explanation 
FORMAT                               FORMAT'/tmp/%U'     Specifies a location and name for backup pieces and copies. You must use substitution variables to generate unique filenames.

Parameter                        Example                        Explanation
TAG                                TAG 'monday_bak'       Specifies a user-defined string as a label for the backup. If you do not specify a tag, then RMAN assigns a default tag with the date and time.

The following BACKUP commands illustrate these options:

RMAN> BACKUP FORMAT='AL_%d/%t/%s/%p' ARCHIVELOG LIKE '%arc_dest%';

RMAN> BACKUP TAG 'weekly_full_db_bkup' DATABASE MAXSETSIZE 10M;

RMAN> BACKUP COPIES 2 DEVICE TYPE sbt BACKUPSET ALL;

Incremental Backups :

If you specify BACKUP INCREMENTAL, RMAN will create incremental backups of your database. Incremental backups capture on a block-by-block basis changes in your database since a previous incremental backup. The starting point for an incremental backup strategy is a level 0 incremental backup, which backs up all blocks in the database. Level 1 incremental backups, taken at regular intervals, contain only changed blocks since a previous incremental backup. These can be cumulative (including all blocks changed since the most recent level 0 backup) or differential (including only blocks changed since the most recent incremental backup, whether it is level 0 or level 1).

Incremental backups are generally smaller and faster to create than full database backups. Recovery from an incremental backup is faster than recovery using redo logs alone. During a restore from incremental backup, the level 0 backup is used as the starting point, then changed blocks are updated based on level 1 backups where possible to avoid re-applying changes from redo one at a time. Recovering with incremental backups requires no additional effort on your part. If incremental backups are available, RMAN will use them during recovery.

Enterprise Edition includes RMAN's change tracking feature for incremental backups which improves incremental backup performance by recording changed blocks in each datafile in a change tracking file. If change tracking is enabled, RMAN uses the change tracking file to identify changed blocks for incremental backup, thus avoiding the need to scan every block in the datafile. 

Incrementally Updated Backups:

RMAN's incrementally updated backups feature allows for a more efficient incremental backup routine. Changes from level 1 backups can be used to roll forward an image copy level 0 incremental backup, so that it includes all changes as of the SCN at which the level 1 incremental backup was created. Recovery using the updated level 0 incremental backup is faster, because all changes from the level 1 incremental backup have already been applied.

Backing Up Archived Redo Logs

Archived redo logs are the key to successful media recovery. Back them up regularly. You can back up logs with BACKUP ARCHIVELOG, or back up logs while backing up datafiles and control files by specifying BACKUP ... PLUS ARCHIVELOG.

To back up archived redo logs, use the BACKUP ARCHIVELOG command at the RMAN prompt. This example uses a configured disk or sbt channel to back up one copy of each log sequence number for all archived redo logs:

RMAN> BACKUP ARCHIVELOG ALL;

Even if your redo logs are being archived to multiple destinations and you use RMAN to back up archived redo logs, RMAN selects only one copy of the archived redo log file to include in the backup set. (Since logs with the same log sequence number are identical, there is no need to include more than one copy.)

You can also specify a range of archived redo logs by time, SCN, or log sequence number, as in the following example:

RMAN> BACKUP ARCHIVELOG
      FROM TIME 'SYSDATE-30' UNTIL TIME 'SYSDATE-7';

You can specify the DELETE INPUT or DELETE ALL INPUT clauses for the BACKUP ARCHIVELOG command to delete archived logs after they are backed up, eliminating the separate step of manually deleting the archived redo logs. With DELETE INPUT, RMAN only deletes the specific copy of the archived redo log chosen for the backup set. With DELETE ALL INPUT, RMAN will delete each backed-up archived redo log file from all log archiving destinations. 

 

Restoring and Recovering Database Files

Use the RESTORE and RECOVER commands for RMAN restore and recovery of physical database files. Restoring datafiles is retrieving them from backups as needed for a recovery operation. Recovery is the application of changes from redo logs and incremental backups to a restored datafile, to bring the datafile to a desired SCN (point in time) or to current time. 

Recovering the Whole Database : 

Use the RESTORE DATABASE and RECOVER DATABASE commands on the whole database. For example:

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

Note that the database must not be open when restoring or recovering the entire database.

Recovering Current Tablespaces :

Use the RESTORE TABLESPACE and RECOVER TABLESPACE commands on individual tablespaces when the database is open. Take the tablespace that needs recovery offline, restore and then recover the tablespace, and bring the recovered tablespace online. The following steps recover the users tablespace:

RMAN> SQL 'ALTER TABLESPACE users OFFLINE';
      RESTORE TABLESPACE users;
      RECOVER TABLESPACE users;
      SQL 'ALTER TABLESPACE users ONLINE;

Recovering Current Datafiles :

Use the RESTORE DATAFILE and RECOVER DATAFILE commands on individual current datafiles when the database open. Take the datafile that needs recovery offline, restored recover the datafile, and bring the datafile online. For example, to restore and recover datafile 7:

RMAN> SQL 'ALTER DATABASE DATAFILE 7 OFFLINE';
      RESTORE DATAFILE 7;
      RECOVER DATAFILE 7;
      SQL 'ALTER DATABASE DATAFILE 7 ONLINE';

Recovering Individual Data Blocks : 

RMAN can recover individual corrupted datafile blocks. When RMAN performs a complete scan of a file for a backup, any corrupted blocks are listed in V$DATABASE_BLOCK_CORRUPTION. Corruption is usually reported in alert logs, trace files or results of SQL queries. Use BLOCKRECOVER to repair all corrupted blocks:

RMAN> BLOCKRECOVER CORRUPTION LIST;

You can also recover individual blocks, as shown in this example:

RMAN> BLOCKRECOVER DATAFILE 7 BLOCK 233, 235 DATAFILE 4 BLOCK 101;

Reporting on RMAN Operations

The RMAN LIST and REPORT commands, generate reports on backup activities based on the RMAN repository. Use SHOW ALL to display the current RMAN configuration.

Listing Backups

Use LIST to display information about backup sets, proxy copies, and image copies recorded in the repository. The LIST command displays the files against which you can run CROSSCHECK and DELETE commands. Use this command to list:

• Backups and copies that do not have the status AVAILABLE in the RMAN repository
• Backups and copies of datafiles that are available and can possibly be used in a restore operation
• Specified archived logs, backup sets, backup pieces, control file copies, datafile copies, and proxy copies
• Backups and copies restricted by tag, completion time, recoverability, or device
• Incarnations of a specified database or of all databases known to the repository
• Stored scripts in the recovery catalog

Reporting on Database Files and Backups

The REPORT command performs more complex analysis than LIST. Use the REPORT command to answer questions such as the following:

• Which files need a backup?
• Which files have not had a backup for some time? 
• Which files are not recoverable due to unrecoverable operations? 
• Which backup files can be deleted? 
• What was the physical schema of the database at a previous time 

 

Managing the RMAN Repository

RMAN repository metadata is always recorded in the control file of the target database. You can also create a recovery catalog in a separate database, and RMAN will record its metadata there as well.

Monitoring Control File Records : 

If you do not use a recovery catalog, then eventually RMAN control file records are overwritten. Set this initialization parameter in the parameter file of the target database to determine how long records are kept:

CONTROL_FILE_RECORD_KEEP_TIME =

You can configure a retention policy to be used by RMAN to determine which backups are considered obsolete.  This allows you to remove files from the repository that are no longer needed to meet your retention requirements.  This policy can be based on a recovery window (the maximum number of days into the past for which you can recover) or redundancy (how many copies of each backed-up file to keep).

The RECOVERY WINDOW parameter of the CONFIGURE command specifies the number of days between the current time and the earliest point of recoverability. RMAN does not consider any full or level 0 incremental backup as obsolete if it falls within the recovery window. Additionally, RMAN retains all archived logs and level 1 incremental backups that are needed to recover to a random point within the window.

Run the CONFIGURE RETENTION POLICY command at the RMAN prompt. This example ensures that you can recover the database to any point within the last week:

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS

The REDUNDANCY parameter of the CONFIGURE RETENTION POLICY command specifies how many backups of each datafile and control file that RMAN should keep. In other words, if the number of backups for a specific datafile or control file exceeds the REDUNDANCY setting considers the extra backups as obsolete. The default retention policy is REDUNDANCY=1.

As you produce more backups, RMAN keeps track of which ones to retain and which are obsolete. RMAN retains all arcd logs and incremental backups that are needed to recover the nonobsolete backups.

Assume that you make a backup of datafile 7 on Monday, Tuesday, Wednesday, and Thursday. You now have four backups of the datafile. If REDUNDANCY is 2, then the Monday and Tuesday backups are obsolete. If you make another backup on Friday, then the Wednesday backup becomes obsolete.

Run the CONFIGURE RETENTION POLICY command at the RMAN prompt, as in the following example:

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

RMAN does not automatically delete backups rendered obsolete by the retention policy. Instead, RMAN shows them as OBSOLETE in the REPORT OBSOLETE output and in the OBSOLETE column of V$BACKUP_FILES. RMAN deletes obsolete files if you run the DELETE OBSOLETE command.

 Note, backups in the flash recovery area are susceptible to deletion based on RMAN retention policy configuration. 

 

Crosschecking and Deleting Backups

Crosscheck is needed when an archivelog file or backup is manually removed, i.e., not deleted by RMAN.  This command ensures that data about backups in the recovery catalog or control file is synchronized with corresponding data on disk or in the media management catalog.  The CROSSCHECK command operates only on files that are recorded in the recovery catalog or the control file. 

The CROSSCHECK command does not delete any files that it is unable to find, but updates their repository records to EXPIRED. Then, you can run DELETE EXPIRED to remove the repository records for all expired files as well as any existing physical files whose records show the status EXPIRED.

If some backup pieces or copies were erroneously marked as EXPIRED, for example, because the media manager was misconfigured, then after ensuring that the files really do exist in the media manager, run the CROSSCHECK BACKUP command again to restore those files to AVAILABLE status.

Crosschecking Backups

RMAN> # checks RMAN backups on configured devices
      CROSSCHECK BACKUP;

      # checks RMAN image copies on configured devices>
      CROSSCHECK COPY;

If backups are stored with a media manager and sbt channels are not configured, then you must allocate maintenance channel before CROSSCHECK and DELETE commands on sbt devices:

RMAN> ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
      CROSSCHECK BACKUP;

The DELETE command removes RMAN backups and copies from DISK and sbt devices, marks theects as DELETED in the control file, and removes the records from the recovery catalog (if you use a catalog). For example:

RMAN> DELETE BACKUPSET 101, 102, 103;
      DELETE CONTROLFILECOPY '/tmp/cf.cpy';
      DELETE NOPROMPT ARCHIVELOG UNTIL SEQUENCE = 7300;
      DELETE BACKUP OF SPFILE TABLESPACE users DEVICE TYPE sbt;
      DELETE BACKUP OF DATABASE LIKE '/tmp%'; # pattern match
      DELETE ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;