RMAN Introduction

Recovery Manager (RMAN) is an Oracle utility that can back up, restore, and recover database files. The product is a feature of the Oracle database server and does not require separate installation.

RMAN uses database server sessions to perform backup and recovery. It stores metadata about its operations in the control file of the target database and, optionally, in a recovery catalog schema in an Oracle database.

The RMAN environment consists of the utilities and databases that play a role in a backup and recovery strategy. A typical environment uses the following:

RMAN executable
Target database
Recovery catalog database (optional)
Media management software (optional)

Of these components, only the RMAN executable and target database are required. RMAN automatically stores its metadata in the target database control file, so the recovery catalog is optional

RMAN backup of the datafiels, archived redo log files, online redo log files, controlfiles is done in a proprietary format. And the backup contains only the used blocks.

Component	Description	Required or Not required
Target database	The control files, datafiles, and optional archived redo logs that RMAN is in charge of backing up or restoring. RMAN uses the target database control file to gather information about the database and to store information about its own operations. The actual work of the backup and recovery jobs is performed by server sessions on the target database.	Yes
RMAN executable	The client application that manages backup and recovery operations for a target database. The RMAN client uses Oracle Net to connect to a target database, so it can be located on any host that is connected to the target host through Oracle Net.	Yes
Recovery catalog database	A database containing the recovery catalog schema, which contains the metadata, that RMAN uses to perform its backup and recovery operations.	No
Recovery catalog database	A database containing the recovery catalog schema, which contains the metadata, that RMAN uses to perform its backup and recovery operations.	No
Recovery catalog Schema	The user within the recovery catalog database that owns the metadata tables maintained by RMAN. RMAN periodically propagates metadata from the target database control file into the recovery catalog.	No
Standby database	A copy of the primary database that is updated using archived logs created by the primary database. RMAN can create or back up a standby database.	No
Media management application	A vendor-specific application that allows RMAN to back up to a storage system such as tape. When doing backups or restores, the RMAN client connects to the target instance and directs the instance to talk to its media manager. No direct communication occurs between the RMAN client and the media manager: all communication occurs on the target instance.	No
Media management catalog	A vendor-specific repository of information about a media management application.

RMAN compatibility: errors
When compatibility of components is broken RMAN will rise one of the following errors:
RMAN-6186 - associated message: "PL/SQL package %s.%s version %s in %s database is too old"
RMAN-6429 - associated message: "%s database is not compatible with this version of RMAN".

Table	Table Data contains
AL	Archived logs uniquely identified by dbinc_key, recid and stamp.
BCB	Corrupt block ranges in datafile backups.
BCF	Control file backups (in backup sets).
BDF	All datafile backups (in backup sets).
BP	All backup pieces of backup sets.
BRL	Backups redo logs (in backup sets).
BS	All backup sets for all database incarnations.
CCB	Corrupt block ranges in datafile copies.
CCF	Control file copies.
CDF	All datafile copies.
CKP	Records all recovery catalog checkpoints.
DB	All target databases that have been registered in this recovery catalog.
DBINC	All incarnations of the target databases registered in this recovery catalog.
DF	All datafiles of all database incarnations.
DFATT	Datafile attributes that change over time.
OFFR	Stores datafile offline ranges.
ORL	All redo logfiles for all database incarnations.
RCVER	Recovery catalog version.
RLH	Records all redo log history for all threads.
RR	Redo ranges for all database incarnations.
RT	Redo threads for all database incarnations.
SCR	1 row for each stored script.
SCRL	1 row for each line of each stored script.
TS	All tablespaces of all database incarnations.
TSATT	Tablespace attributes that change over time.

RC_ARCHIVED_LOG	Information about all archive logs
RC_BACKUP_CONTROLFILE	Backup control files in backup sets.
RC_BACKUP_CORRUPTION	Corrupt blocks in datafile backups and copies.
RC_BACKUP_DATAFILE	Datafile backups (in backup sets).
RC_BACKUP_PIECE	Backup pieces.
RC_BACKUP_REDOLOG	Redo log backups (in backup sets).
RC_BACKUP_SET	Backup sets.
RC_CHECKPOINT	rc_checkpoint is replaced by rc_resync, but is still used by some tests.
RC_CONTROLFILE_COPY	Controlfile copies
RC_COPY_CORRUPTION	Corrupt block ranges in datafile copies for all database incarnations.
RC_DATABASE	Information about databases and their current incarnations
RC_DATABASE_INCARNATION	Information about all incarnations registered in recovery catalog.
RC_DATAFILE	Information about all datafiles registerIn recovery catalog
RC_DATAFILE_COPY	Datafile copies (on disk).
RC_LOG_HISTORY	Information about redo log history
RC_OFFLINE_RANGE	Offline ranges for datafiles
RC_REDO_LOG	Information about online redo logs.
RC_REDO_THREAD	Information about redo threads
RC_RESYNC	Information about recovery catalog resyncs (checkpoints).
RC_STORED_SCRIPT	Stored scripts
RC_STORED_SCRIPT_LINE	Each line of each stored script
RC_TABLESPACE	Information about all tablespaces registered in Recovery catalog.

An RMAN channel represents one stream of data to a device type and corresponds to one server session. It is the channel that reads and writes RMAN backup files. The I/O device could be a disk or a tape. It needs to define the number of processes simultaneously accessing an I/O device, maximum size of file/s created on the I/O devices, maximum rate at which database files are read and maximum number of files open at a time are some the input parameters for the channel server process to perform backup/r3ecovery jobs for RMAN.

Allocation of one or more RMAN channels is necessary to execute most backup and recovery commands. The server session performs the backup, restore, and recovery operations. Only one RMAN session communicates with the allocated server sessions.

You can either allocate channels manually within a RUN block, or pre-configure channels for use in all RMAN sessions using automatic channel allocation. RMAN comes pre-configured with a DISK channel that you can use for backups and copies to disk. You can also run the CONFIGURE CHANNEL command RMAN to specify automatic channels to disk or tape. In this way, you do not have to allocate channels every time you perform a backup, restore, or recovery operation.

When you run a command that requires a channel, and you do not allocate a channel manually, then RMAN automatically allocates the channels using the options specified in the CONFIGURE command. For the BACKUP command, RMAN allocates only a single type of channel, such as DISK or sbt_tape. For the RESTORE command and the various maintenance commands (for example, DELETE), RMAN determines which device types are required, and allocates all necessary channels.

If you specify channels manually, then the ALLOCATE CHANNEL command (executed only within a RUN command) and ALLOCATE CHANNEL FOR MAINTENANCE command (executed only at the RMAN prompt) specify the type of I/O device that the server session will use to perform the backup, restore, or maintenance operation.

Whether the ALLOCATE CHANNEL command or CONFIGURE CHANNEL causes the media manager to allocate resources is vendor-specific. Some media managers allocate resources when you issue the command; others do not allocate resources until you open a file for reading or writing.

A proxy copy is a special type of backup in which RMAN turns over control of the data transfer to a media manager that supports this feature. The PROXY option of the BACKUP command specifies that a backup should be a proxy copy.

For each file that you attempt to back up using the BACKUP PROXY command, RMAN queries the media manager to determine whether it can perform a proxy copy. If the media manager cannot proxy copy the file, then RMAN uses conventional backup sets to perform the backup. An exception occurs when you use the PROXY ONLY option, which causes Oracle to issue an error message when it cannot proxy copy.

Oracle records each proxy-copied file in the control file. RMAN uses this data to resynchronize the recovery catalog. Use the V$PROXY_DATAFILE view to obtain the proxy copy information. Use the CHANGE PROXY command or DELETE PROXY command to change the status of or delete a proxy backup.

The proxy functionality was introduced in Oracle8i Release 1 (8.1.5). If a proxy version of RMAN is used with a non-proxy target database, RMAN will not use proxy copy to create backup sets. If you make backups using proxy copy and then downgrade Oracle to a non-proxy version, RMAN will not use proxy copy backups when restoring and will issue a warning when the best available file is a proxy copy.

A backup set, which is a logical object, contains one or more physical backup pieces. By default, one backup set contains one backup piece. Backup pieces are operating system files that contain the backed up datafiles, control files, or archived redo logs. For example, you can back up ten datafiles into a single backup set containing a single backup piece (that is, a single output file). You cannot split a file across different backup sets or mix archived logs and datafiles into one backup set.

RMAN can create backup sets that are written to disk or tertiary storage. If you specify DEVICE TYPE DISK, then you must back up to random access disks. You can make a backup on any device that can store an Oracle datafile: in other words, if the statement CREATE TABLESPACE tablespace_name DATAFILE 'filename' works, then 'filename' is also a valid backup path name.

Using a media management system that is available and supported on your operating system, you can write backup sets to sequential output media such as magnetic tape. If you specify a device type such as sbt that is other than DISK, then you can back up to any media supported by the media management software.

A backup set is a complete set of backup pieces that make up a full or incremental backup of the objects specified in the BACKUP command. Backup sets are in an RMAN-specific format. An image copy, which is a complete image of a single datafile, control file, or archived log, is not in an RMAN-specific format.

You can back up datafiles, control files, archived redo logs, and the current server parameter file. You can also back up another backup set, as when you want to back up a disk backup to tape, or an image copy. For example, you can issue commands such as the following, each of which uses an automatic channel configuration:

BACKUP DATABASE;
BACKUP TABLESPACE users, tools;
BACKUP (SPFILE) (CURRENT CONTROL FILE);
BACKUP BACKUPSET 12;
BACKUP DATAFILECOPY '/tmp/system01.dbf';

When backing up datafiles, the target database must be mounted or open. If the database is in ARCHIVELOG mode, then the target can be open or closed: you do not need to close the database cleanly. If the database is in NOARCHIVELOG mode, then you must close it cleanly before making a backup.

You cannot make a backup of a transported tablespace until after it has been specified read/write.

RMAN creates physical binary files while performing backup operations. These files are written to the chosen medium. They are in one word the datafiles, controlfiles, archived redo log files and spfile.

Here are some important relational mechanism that works between the datafiles and backup pieces.

01. A datafile cannot span backup sets.
02. A datafile can span backup pieces as long as those backup pieces are part of single backup set
03. Datafiles and controlfiles can co-exist on a single backup set
04. Archived log files are never on the backup set which has datafiles and controlfiles

RMAN cannot handle the tapes on its own. It needs a MML to take care of that. If it is to the disks RMAN needs nobody’s help. This MML developed by various vendors like Legato, Veritas, and Tivoli etc,

Argument	Value	Description
target	quoted-string	connect-string for target database
catalog	quoted-string	connect-string for recovery catalog
nocatalog	none	if specified, then no recovery catalog
cmdfile	quoted-string	name of input command file
log	quoted-string	name of output message log file
trace	quoted-string	name of output debugging message log file
append	none	if specified, log is opened in append mode
debug	optional-args	activate debugging
msgno	none	show RMAN-nnnn prefix for all messages
send	quoted-string	send a command to the media manager
pipe	string	building block for pipe names
timeout	integer	number of seconds to wait for pipe input

Argument	Value	Description
target	quoted-string	connect-string for target database
catalog	quoted-string	connect-string for recovery catalog
nocatalog	none	if specified, then no recovery catalog
cmdfile	quoted-string	name of input command file
log	quoted-string	name of output message log file
trace	quoted-string	name of output debugging message log file
append	none	if specified, log is opened in append mode
debug	quoted-string	activate debugging
msgno	none	show RMAN-nnnn prefix for all messages
send	quoted-string	send a command to the media manager
pipe	string	building block for pipe names
timeout	integer	number of seconds to wait for pipe input

Both single and double quotes (' or ") are accepted for a quoted-string.
Quotes are not required unless the string contains embedded white-space.

connected to target database: KANS10G (DBID=754098840)
using target database controlfile instead of recovery catalog

If flash recovery destination is defined in the init.ora file for the database the snapshot for the controlfile is created there by default.

Otherwise snapshot controlfile is created at the default destination unless otherwise it is set to another destination.

connected to target database: SRIDEVI (DBID=937156271)
using target database controlfile instead of recovery catalog

“using target database controlfile instead of recovery catalog” tells you that you are connected to the target database to perform backup and recovery functions using nocatalog

The snapshot of the controlfile is created at the %ORACLE_HOME%/database and is given a default name as under:

The snapshot controlfile created when RMAN is invoked with nocatalog is sncfsridevi.ora located at %ORCALE_HOME%\database\ that is the default location.
On UNIX systems it is $ORCLE_HOME/db.

Argument	Value	Description
target	quoted-string	connect-string for target database
rcvcat	quoted-string	connect-string for recovery catalog
debug	none	if specified, activate debugging mode
cmdfile	quoted-string	name of input command file
msglog	quoted-string	name of output message log file
trace	quoted-string	name of output debugging message log file
append	none	if specified, msglog opened in append mode
nocatalog	none	if specified, then no recovery catalog

Recovery Manager: Release 8.1.6.3.0 - Production
RMAN-06005: connected to target database: SRINIVAS (DBID=2653120470)
RMAN-06009: using target database controlfile instead of recovery catalog

The snapshot controlfile created when RMAN is invoked with nocatalog is sncfsrinivas.ora located at %ORCALE_HOME%\database\ that is the default location.
On UNIX systems it is $ORCLE_HOME/db.

This can be changed to a user-defined destination using
SET SNAPSHOT CONTROLFILE
command

Same is the case with Oracle release 8.0.x versions. They are nit illustrated, as those versions are not installed on this PC

Here is what metalink says if you want to change the default destination for the snapshot controlfile (relevant from Oracle 8.0 to 8.1.x versions)

When RMAN needs to resynchronize from a read-consistent version of the control file, it creates a temporary snapshot control file.
The default name for the snapshot control file is port-specific.
Use the set snapshot controlfile name command to change the name of the snapshot control file; subsequent snapshot control files that RMAN creates use the name specified in the command.

set snapshot controlfile name to 'd:\oracle\oradata\<sid_name>\snap.ctl';

You can also set the snapshot control file name to a raw device. This operation is important for OPS databases in which more than one instance in the cluster use RMAN because server sessions on each node must be able to create a snapshot control file with the same name and location.

For example, enter: (UNIX)
set snapshot controlfile name to '<mt_point>/oracle/oradata/<sid_name>/snap.ctl';

If one RMAN job is already backing up the control file while another needs to create a new snapshot control file, you may see the following message:

Under normal circumstances, a job that must wait for the control file enqueue will wait for a brief interval and will then successfully retrieve the enqueue. Recovery Manager makes up to five attempts to get the enqueue and then fails the job. The conflict is usually caused when two jobs are both backing up the controlfile, and the

job that starts backing up the control file first waits for service from the media manager.

Recovering the database in case everything is lost using Oracle RMAN with NOCATALOG backups before Oracle 9i Version was not possible as controlfile only can recognize the RMAN backups and all those controlfiles are lost, even though you have a backup controlfile done by RAMAN with Nocatalog.

If the lost controlfiles have a backup at another destination from where that can be restored to the database those files may be useful as they may contain RMAN backup information depending upon the time RMAN backup of the controlfiles and took place. The default controlfile keep time is 7 (seven) days. After seven days the controlfile entries are overwritten. So in the context we are not sure if we have a RMAN entries in the controlfile or not.

For some reasons it as suggested to set the control_file_keep_time to 0(zero) because of a bug by oracle in some other context to avoid something else by Oracle Support. This was because controlfile refused to grow beyond 65536.

This occurs when LGWR tries to write to "LOG_HISTORY" section (#9) of control file and LSN (log sequence number) is larger than 65535. It will crash the instance.

"MAXLOGHISTORY" is one of the database settings specified in CREATE DATABASE statement. It is the number of redo log files about which the control file can keep information.

This value determines how much space in the control file to allocate for the names of the archive redo logs files. The default value is operating system dependent. However, we have seen it default to 65535 on certain platforms. You need to set it to an appropriate value, which is sufficient for automatic media recovery of the database.

You must recreate the control file when you want to change “MAXLOGHISTORY” value.

When Oracle 8.0.4 databases crashed and controlfiles were to be used to restore the databases. The alert log file entries spoke volumes of this. Since that time we used to first run this script on Development Database before the database is upgraded. after it was conformed that this was fixed in 8.0.6 we gave up this PLSQL.

declare
i integer;
cid integer;
rid integer;
begin
cid: = SYS.DBMS_SQL.OPEN_CURSOR;
FOR i IN 1..70000 LOOP
SYS.DBMS_SQL.PARSE (cid, 'alter system switch logfile', dbms_sql.V7);
rid := SYS.DBMS_SQL.EXECUTE(cid);
END LOOP;
SYS.DBMS_SQL.CLOSE_CURSOR (cid);
.
EXCEPTION
WHEN OTHERS THEN
SYS.DBMS_SQL.CLOSE_CURSOR (cid);
end;
/

This anonymous PLSQL was used to develop test case to reproduce the bug for the TAR. A group that develops the case when TAR is opened supplied this.
Oracle 9i and other newer versions do not have this problem with the default NOCATALOG option of RMAN.
From the snapshot controlfile copy the controlfile can be recreated at those destinations identified by initialization parameter file.

DBMS_BACKUP_RESTORE.RESTORECONTROLEFILETO to restore the database in 8.1.6 as per my personal experience as also the experience of Code McDaniel (Doc id
118597.999)
I tested on 8.1.6.3.0.
Step wise what I did:

01. Backup entire database
02. Backup controlfile to trace and check if you have this kind of notation and command in that file
# Configure snapshot controlfile filename
execute sys.dbms_backup_restore.cfilesetsnapshotname ('d:\oracle\ora81\database\sncfsrinivas.ora');
This destination I have for my snapshot controlfile is that. If that were set to another destination it would be at that destination.
03. Shutdown the database
04. Rename all controlfiles
05. Issued startup to check database startup and Oracle spit out ORA-00205
06. Shutdown database with normal or immediate but not abort option
07. Connect internal
08. Run the trace file to recreate the controlfile commenting out “recover database”
09. Verify the existence of the controlfiles at the OS
10. Check for the errors in the alert log files
11. Once again shutdown with immediate option
12. Startup database
13. Take backup of the database immediately
14. The reason is we do not see any backup structures identified in the snapshot controlfile from RMAN
rman target system/manager@srinivas nocatalog
and then at “RMAN” prompt issue list backup command to list the backups and nothing is listed.

This part is scary. There are some differences on the size of the controlfile I have and the way Code McDaniel has mentioned. I did not see growth of the control as he saw. Mine was a test database in my name and the controlfile was of 2896 KB before and after.

Please do not take this for implementation unless you test make sure of yourself that this helps. Document all the steps you have followed during the tests.