Installed with the database, Recovery Manager (RMAN) is an Oracle database client which performs backup and recovery tasks on your databases and automates the 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.
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:
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;
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;
Here are some often-used BACKUP command options:
|FORMAT||FORMAT=’/tmp/%U’||Specifies a location and name for backup pieces and copies. You must use substitution variables to generate unique filenames.|
|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;
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;
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.
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 = [number_of_days_to_keep]
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.
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.
RMAN> # checks RMAN backups on configured devices CROSSCHECK BACKUP;
RMAN> # 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;