Recovery Manager (RMAN) is an Oracle database client which performs backup and recovery tasks on an Oracle database.

The environment for RMAN must include:

• a target database to backed up
• the RMAN client

Optional RMAN components:

• Flash Recovery Area: a disk location in which the database can store and manage files related to backup and recovery
• Media Management Software: required for RMAN to interface with backup devices such as tape drives
• Recovery Catalog Database: a separate database schema used to record RMAN activity against one or more target databases

Target Database

Is the database which needs to be backed up.

Password File

To connect to a target database the password file must exist in ORACLE_HOME/dbs. See orapwd for more information.

RMAN backups can be stored in one of two formats:

• Image Copy
• Backup Set

Image Copies

An image copy is an exact copy of a single datafile, archived redo log file, or control file. Image copies are not stored in an RMAN-specific format. They are identical to the results of copying a file with the UNIX cp command. This is the same as a Cold Backup.

Backup Sets

A backup set is a collection of files (called backup pieces) each of which contain the backup to one or more database files. A backup set contains the data from one or more datafiles or archived redo logs, or control files or spfile. Datafiles and archivelogs cannot be mixed together in the same backup set.

You can use binary compression to reduce the size of your backup sets. The compression algorithm built into the Oracle server is tuned specifically for efficient compression of Oracle archived logs and datafiles, and will generally yield better compression than general-purpose compression utilities not tuned for Oracle database files.

RMAN is a command-line-oriented database client. From the RMAN client you can issue RMAN commands and SQL statements to perform and report on backup and recovery operations.

The RMAN executable is typically installed in the same directory as the other database executables. On Unix systems, for example, the RMAN executable is located in $ORACLE_HOME/bin.

The RMAN executable is located in $ORACLE_HOME/bin.

RMAN maintains metadata about the target database and its backup and recovery operations in the RMAN repository. The metadata includes:

• the target database schema
• archived redo logs
• all backup files on disk or tape

You can display RMAN repository information with the LIST REPORT and SHOW commands.

RMAN repository data is always stored in 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. The repository can also be kept in a recovery catalog, a separate database that keeps historical data on backup activities much longer than the control file and preserves backup information if the control file is lost.

The Automatic Disk-Based Backup and Recovery feature simplifies managing disk space and files related to backup and recovery, by managing all backup and recovery related files in a flash recovery area. You set the flash recovery area size and location, using the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE initialization parameters. You also specify a retention policy that dictates when backups may be discarded. RMAN then manages your backup storage, deleting obsolete backups and backups already copied to tape when space is needed, but keeping as many backups on disk as space permits.

In addition to RMAN repository records, the recovery catalog can also hold RMAN stored scripts, sequences of RMAN commands for common backup tasks.

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.

--
-- connect to a target database and a recovery catalog
--
% rman TARGET sys/password@targetSID CATALOG rman_user/password@rmanSID
--
-- Start rman, then connect to a target and catalog database
--
% rman
RMAN> connect TARGET sys/password@targetSID
RMAN> connect CATALOG rman_user/password@rmanSID

Once started, RMAN displays an "RMAN>" prompt for your commands. To quit the RMAN client, type EXIT at the RMAN prompt.

You can configure persistent settings in the RMAN environment, which apply to all subsequent operations, even if you exit and restart RMAN.

Configuring Retention Policies

The CONFIGURE RETENTION POLICY command can set the terms of a recovery window (how far into the past you need to be able to recover your database), or a redundancy value (how many backups of each file must be retained).

--
-- retains all backups needed to recover the database to any point in time
-- in the last 3 days
--
RMAN> configure retention policy to recovery window of 3 days;
--
-- keep at least two copies of each datafile and controlfile backup
--
RMAN> configure retention policy to redundancy 2;

Use DELETE OBSOLETE to immediately delete backups no longer required by the retention policy. The KEEP option of the BACKUP and CHANGE commands override the CONFIGURED RETENTION POLICY for individual backups i.e. to force the retention of a specific backup.

Configuring Control File Autobackups

--
-- configure RMAN to back up the control file after each backup or copy
--
RMAN> configure controlfile autobackup on;

By default RMAN names control file autobackups and stores them in the flash recovery area.

--
-- configure RMAN to write control file autobackups to the BackupDir
--
RMAN> configure controlfile autobackup format for device type disk to 'BackupDir/controlfile%F';

The %F element of the format string combines the DBID, day, month, year, and sequence number to generate a unique filename. %F is required for control file autobackups.

Configuring Disk Devices and Channels

--
-- to set default channels to use disk
--
RMAN> configure default device type to disk;

Restoring Default Values for Configured Settings

--
-- Reset any CONFIGURE setting to its default by running the command with the CLEAR option
--
RMAN> configure retention policy clear;
RMAN> configure controlfile autobackup format for device type disk clear;

Viewing Current Settings

--
-- show all configurable settings in RMAN
--
RMAN> show all;
--
-- show configured settings in SQL
--
SQL>
COLUMN name  FORMAT a20 wrap
COLUMN value FORMAT a65
SELECT	  name
	, value
FROM	  v$rman_configuration
/
CLEAR COLUMNS

Use the BACKUP AS COPY to make image copies of the database files (a.k.a. cold backup).

Use the BACKUP AS BACKUPSET to backup up files into backup sets. A backup set consists of one or more backup pieces, physical files containing the data. A backup set usually contains only one backup piece. Only RMAN can create and restore backup sets. You will usually configure the presistant settings in advance of the BACKUP command.

--
-- make an image copy (cold backup) of a database
--
RMAN> backup as copy database;
--
-- backup a database and archived logs to disk; in backup set format
--
RMAN> backup as backupset device type disk database plus archivelog;

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).

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. If incremental backups are available, RMAN will use them during recovery.

Validation confirms that a backup could be run, by confirming that all database files exist, are in their correct location, and are free of physical and logical corruption:

RMAN> backup validate database archivelog all;

Use the RESTORE DATABASE and RECOVER DATABASE commands on the whole database.

RMAN> startup force mount;
RMAN> restore database;
RMAN> recover database;
RMAN> alter database open;

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

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 can be reported in alert logs, trace files or results of SQL queries.

--
-- repair all corrupted blocks
--
RMAN> blockrecover corruption list;
--
-- recover individual blocks
--
RMAN> blockrecover datafile datafile# block block#;

You can run a RESTORE VALIDATE operation to confirm that a restore operation can be performed successfully. RMAN decides which backup sets, datafile copies, and archived logs are needed for the operation, and scans them to verify that they are usable.

--
-- confirm the recovery of a database
--
RMAN> restore database validate;

RMAN has extensive listing and reporting functionality allowing you to monitor you backups and maintain the recovery catalog:

--
-- Show copy information for all image copies
--
RMAN> list copy;
--
-- Show backup information for all backup pieces
--
RMAN> list backup;
--
-- Show all backup details for backup sets
--
RMAN> list backup of database;
RMAN> list copy of datafile 1, 2, 3;
--
-- which files need backing up under current retention policy
--
RMAN> report need backup database;
--
-- list all datafiles for which an unrecoverable operation has been performed
-- against an object in the datafile since the last backup of the datafile.
--
RMAN> report unrecoverable;
--
-- Show items that beed 7 days worth of
-- archivelogs to recover completely
--
RMAN> report need backup days = 7 database;  
--
-- Show/Delete items not needed for recovery
--
RMAN> report obsolete;
RMAN> delete obsolete;
--
-- Show/Delete items not needed for point-in-time
-- recovery within the last week
--
RMAN> report obsolete recovery window of 7 days; 
RMAN> delete obsolete recovery window of 7 days;
--
-- Show/Delete items with more than 2 newer copies available
--
RMAN> report obsolete redundancy = 2 device type disk;
RMAN> delete obsolete redundancy = 2 device type disk;
--
-- Show datafiles that connot currently be recovered
--
RMAN> report unrecoverable database;
RMAN> report unrecoverable tablespace USERS;

Status information for jobs in progress and completed jobs is stored in V$RMAN_STATUS. V$RMAN_OUTPUT contains the text ouptut of all RMAN jobs.

--
-- display status information on running RMAN job
--
SQL>
SELECT	  operation
	, status
	, mbytes_processed
	, start_time
	, end_time
FROM	  v$rman_status
/
--
-- To calculate the progress of an RMAN job,
-- run the following query in SQL*Plus while the RMAN job is executing
--
SQL>
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
/

RMAN repository metadata is always stored 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, you must pre-determined how log the control file will keep RMAN information. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter will set how long records RMAN control file records are kept.

--
-- init.ora parameter
--
control_file_record_keep_time = number_of_days_to_keep

The CROSSCHECK command checks whether RMAN backups and copies in the repository can still be accessed.

--
-- checks RMAN backups on configured devices
--
RMAN> crosscheck backup;

Deleting Backups and Copies

The DELETE command removes RMAN backups and copies from disk and tape devices, marks the objects as DELETED in the control file, and removes the records from the recovery catalog (if you use a catalog).

RMAN> delete backupset 101, 102, 103;
RMAN> delete noprompt archivelog until sequence = 7300;
RMAN> delete backup of spfile tablespace USERS device type disk;
RMAN> delete archivelog all backed up 2 times to device type disk;
--
-- delete backups marked as EXPIRED ("not found" by the CROSSCHECK command)
--
RMAN> delete expired;
--
-- delete backups that are obsolete under the retention policy
--
RMAN> delete noprompt obsolete;

RMAN supports the use of stored scripts and command files. A command file is a client-side text file containing RMAN commands, exactly as you enter them at the RMAN prompt.

--
-- execute the contents of a command file using the RMAN @ command
--
RMAN> @/directory/command_file.txt
--
--  launch RMAN with a command file to run
--
% rman @/directory/command_file.txt

Any file extension may be used.

Allocating Disk Space for the Recovery Catalog Database

Typical Recovery Catalog Space Requirements for 1 Year

Create the Recovery Catalog Schema in the Recovery Catalog Database

% sqlplus sys/password as sysdba@catalogDB
SQL>
create tablespace RECOVERY 
  datafile '/fsysx/ORACLE/SID/recovery01.dbf' SIZE 100M REUSE
  extent management local
/
--
-- create the RMAN schema
--
create user rman identified by password;
alter user rman
  temporary tablespace TEMP
  default tablespace RECOVERY
  quota unlimited on RECOVERY
/
grant create session to rman
/
--
-- grant rman the recovery_catalog_owner role.
--
grant recovery_catalog_owner to rman
/

Create the Recovery Catalog

--
-- create the catalog
--
% rman catalog rman/password@rmanSID
RMAN> create CATALOG tablespace rman_tablespace;

Register a Database

Each database to be backed up by RMAN must be registered:

--
-- register the database in the recovery catalog
--
% rman TARGET sys/password@targetSID CATALOG rmanuser/password@rmanSID
RMAN> register database;
--
-- verify that the registration was successful
--
RMAN> report schema;

Registering Multiple Databases in a Recovery Catalog

You can register multiple target databases in a single recovery catalog, if they do not have duplicate DBIDs. RMAN uses the DBID to distinguish one database from another.