Getting started with Server-Managed Recovery (SMR) 
and Recovery Manager (RMAN) 
  
Introduction: 

This document explains the basic operation of SMR & RMAN. Because of the 
enormous flexibility of RMAN only the most basic features will be covered 
here. For more information, please read the Oracle8 Server Backup & Recovery 
Guide or Oracle8i Recovery Manager User's Guide. For comprehensive examples, 
please view the online case*.rcv scripts in $ORACLE_HOME/rdbms/demo. 

For the sake of clarity, I have excluded RMAN error messages and return 
codes unless necessary. It is usually obvious when an error occurs! 
  

Contents: 

1.   What is RMAN & SMR? 
2.   Terminology 
3.   The recovery catalog 
4.   Starting RMAN 
5.   Register the target database 
6.   Adding existing backups to the recovery catalog 
7.   Backing up in noarchivelog mode 
8.   Backing up in archivelog mode 
9.   Incremental backups 
10. Cumulative incremental backups 
11. Checking Backup Progress 
12. Recovery 
13. Scripts 
14. Parallelization 
15. Corruption detection 
16. Channels 
17. Reports 
18. Hints, tips, & best practices 
19.  Limitations 
  
  

1. What is RMAN? 

RMAN can be used to backup and restore database files, archive logs, and 
control files. It can also be used to perform complete or incomplete 
database recovery. Note that RMAN cannot be used to backup initialization 
files or password files. 
  

RMAN starts Oracle server processes on the database to be backed up or 
restored. The backup, restore, and recovery is driven through these processes 
hence the term 'server-managed recovery'. 

Note that SMR can also be controlled from OEM's Backup Manager GUI. This 
article will not discuss Backup Manager. 
  

2. Terminology 

2.1. Backup sets 

 A backup set is characterised by the following: 

       - Contains one or more datafiles or archivelogs 
       - Stored in an Oracle proprietary format 
       - Comprises a complete set of backup pieces 
       - Constitutes a full or incremental backup 
  

2.2. Backup pieces 

A backup set is comprised of a number of backup pieces. Each backup piece 
is a single output file. The size of a backup piece can be restricted; 
if the size is not restricted, the backup set will comprise one backup 
piece. Backup piece size should be restricted to no larger than the 
maximum file size that your filsystem will support. 

2.3. Image copies 

An image copy is a copy of a single file (datafile, archivelog, or 
controlfile). It is very similar to an O/S copy of the file. It is not 
a backupset or a backup piece. No compression is performed. 

2.4. Full backup sets 

A full backup is a backup of one or more datafiles that contains all used 
blocks in the datafile. Blocks that have never been used are not backed up 
i.e. oracle performs backup set compression. 

2.5. Incremental backup sets 

An incremental backup is a backup of one or more datafiles that contains 
only those blocks that have been modified since a previous backup at the 
same or lower level. As with full backups, compression is performed. 

2.6. File multiplexing 

Datablocks from multiple datafiles can be multiplexed in the same 
backupset. 

2.7. Recovery catalog resyncing 

Resyncing the recovery catalog involves synchronising the recovery 
catalog with the target database controlfile. Certain operations perform 
this implicitly. To resync manually, issue the 'resync catalog;' command 
from RMAN. The catalog should be resynced frequently, especially if 
the target database generates many archive logs. It should also be 
resynced after making any structural changes to the target database. 
Although the target database's controlfile is automatically updated 
whenever new controlfile records are created (for example, creation of 
new archived logs or new datafiles), if the target is not resync'd 
and a backup controlfile is restored, the new records must be cataloged 
manually (catalog archivelog '<logname>';). 

2.8. Snapshot Controlfile 

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 to file_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. The snapshot control file name can also 
be set 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 snaphost control file with the same name 
and location. 

2.9. Resetlogs Operation 

Whenever you open the database with the RESETLOGS option, all datafiles 
get a new RESETLOGS SCN and timestamp. Archived redo logs also have 
these two values in their header. Because Oracle will not apply an archived 
redo log to a datafile unless the RESETLOGS SCN and timestamps match, 
the RESETLOGS operations prevents you from corrupting your datafiles with 
old archived logs. 

2.1.0 Database Incarnation 

Whenever you perform incomplete recovery or perform recovery using a 
backup control file, you must reset the online redo logs when you open the 
database. The new version of the reset database is called a new incarnation. 
All archived redo logs generated after the point of the RESETLOGS on the 
old incarnation are invalid in the new incarnation. 

2.1.1. Resetting the Recovery Catalog 

Before you can use RMAN again with a target database that you have 
opened with the RESETLOGS option, notify RMAN that you have reset 
the database incarnation. The reset database command directs RMAN 
to create a new database incarnation record in the recovery catalog. 
This new incarnation record indicates the current incarnation. RMAN 
associates all subsequent backups and log archiving done by the target 
database with the new database incarnation. If you issue the ALTER 
DATABASE OPEN RESETLOGS statement but do not reset the 
database, then RMAN cannot access the recovery catalog because it 
cannot distinguish between a RESETLOGS command and an accidental 
restore of an old control file. By resetting the database, you inform 
RMAN that the database has been opened with the RESETLOGS option. 
In the rare situation in which you wish to undo the effects of opening 
with the RESETLOGS option by restoring backups of a prior incarnation 
of the database, use the 'reset database to incarnation key' command to 
change the current incarnation to an older incarnation. 
  

3. The recovery catalog 

The recovery catalog is a repository of information that is used and 
maintained by RMAN. RMAN uses the information in the recovery 
catalog to determine how to execute requested backup and restore actions..'. 

The recovery catalog can be in a schema of an existing Oracle8 database. 
However if RMAN is being used to backup multiple databases, it is probably 
worth creating a dedicated recovery catalog database. THE RECOVERY CATALOG 
DATABASE CANNOT BE USED TO CATALOG BACKUPS OF ITSELF. 

To set up the recovery catalog, firstly ensure that catalog and catproc 
have been run, then execute the following: 

    SVRMGR> spool create_rman.log 
    SVRMGR> connect internal 
    SVRMGR> create user rman identified by rman 
    temporary tablespace temp 
    default tablespace rcvcat quota unlimited on rcvcat; 
    SVRMGR> grant recovery_catalog_owner to rman; 
    SVRMGR> grant connect, resource to rman; 
  

Note: Following steps only apply for an Oracle8 8.0.x catalog creation. 

    SVRMGR> connect rman/rman 
    SVRMGR> @?/rdbms/admin/catrman 

Check create_rman.log for errors. The above commands assume that the 
TEMP and RCVCAT tablespaces have been created. 

In Oracle8i the catalog is created a little differently. 

Note: Following steps only apply to Oracle8i 8.1.5 and greater. 

From the UNIX shell run: 

    % set ORACLE_SID=RCAT 
    % rman catalog rman/rman 
    RMAN> create catalog; 

This will generate the recovery catalog schema in the default tablespace for 
RMAN. 

Also ensure that catproc has been run on the target database as SYS 
(do _not_ use SYSTEM); RMAN makes extensive use of RPCs. 

It is very important that the recovery catalog database is backed up 
regularly and frequently. 

Note: Although you are not required to use a recovery catalog with RMAN, 
it is recommended. Because most of the information in the recovery catalog 
is available via the target database's controlfile, RMAN can use this 
information for recovery purposes. 
  

4. Starting RMAN 

RMAN has a command line interface, or can be run from Enterprise Manager. 
For the purposes of this document, only the CLI will be covered. 

The command line interface has following syntax: 

    rman target <qstring> [rcvcat <qstring> | cmdfile <qstring> | 
    msglog <qstring> | append | trace <qstring>] 

Argument     Quoted String Description 

TARGET A connect string containing a userid and password for the 
                database on which Recovery Manager is to operate. 

                rman target system/manager@target 

RCVCAT A connect string that contains a userid and password for the 
                database that contains the recovery catalog. 

                rman rcvcat rman/rman@rcvcat 

CMDFILE The name of a file that contains the input commands for 
                RMAN. If this argument is specified, RMAN operates in batch 
                mode; otherwise, RMAN operates in interactive line mode. 

MSGLOG The name of a file where RMAN records commands and output 
                Results. If not specified, RMAN outputs to the screen. 

APPEND This parameters causes the msglog file to be opened in append 
                mode. If this parameter is not specified and a file with the 
                same name as the msglog file already exists, it is overwritten. 

TRACE     A file name where RMAN will dump a trace information. 
                (useful feature for RMAN jobs debugging) 
  
  

For the purposes of the following examples, assume that 

    - the target database is called "targdb" and has the same TNS alias 
    - "targdba" has been granted SYSDBA privileges 
    - the recovery catalog database is called "rcat" and has the same TNS alias 
    - the schema containing the recovery catalog is "rman" (same password) 

Before invoking RMAN, set the NLS_DATE_FORMAT and NLS_LANG environment 
variables. Much of the RMAN LIST output is date/time related. It is often 
necessary to have this information displayed as accurately as possible 
when performing time-based recovery. Example NLS settings: 

    NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 
    NLS_DATE_FORMAT=DD-MON-YYYY HH24:MI:SS 

For RMAN to connect to the recovery catalog and the target database, the 
recovery catalog database must be OPEN, while the target instance must be 
at least STARTED. If not, RMAN will give an error. To perform backups with 
the target database open, the target MUST be in archivelog mode. 

4.1. Connecting to RMAN without a recovery catalog 

Set ORACLE_SID to be the target database, and issue the following: 

    % rman nocatalog 
    RMAN> connect target 
    or if the target database uses a password file, 
    RMAN> connect target targdba/<password>@targdb 

4.2. Connecting to RMAN with a recovery catalog 

    % rman rcvcat rman/rman@rcat 
    RMAN> connect target 
    or if the target database uses a password file, 
    % rman rcvcat rman/rman@rcat target targdba/<password>@targdb 
  

Note: Recovery Manager automatically requests a connection to the target 
database as SYSDBA. In order to connect to the target database as SYSDBA, 
you must either: 

1. Be part of the operating system DBA group with respect to the 
target database. This means that you have the ability to CONNECT 
INTERNAL to the target database without a password. 

-or - 

2. Have a password file setup. This requires the use of the "orapwd" 
command and the initialization parameter "remote_login_passwordfile". 

Note: The connect string (for example, @targdb) should be a valid TNS 
alias, as specified in the local to the rman utility tnsnames.ora file . 
  

4.3. Using RMAN 
  

Once connected to the target database, you can specify RMAN commands 
either interactively or by using stored scripts. An example of 
using RMAN interactively would be: 

    RMAN> resync catalog; 

An example of calling a stored script would be: 

    RMAN> execute script alloc_1_disk; 

To create/replace a stored script: 

    RMAN> replace script alloc_1_disk { 
    2> allocate channel d1 type disk; 
    3> } 
  

5. Register the target database 

Database status: 
Recovery catalog: open 
Target: mounted or open 

The target database must be registered with the recovery catalog before 
using RMAN against the database for the first time: 

    RMAN> register database; 
  

6. Adding existing backups to the recovery catalog 

Database status: 
Recovery catalog: open 
Target: mounted or open 

If user-created backups existed under version 8.x prior to registering with 
the target database, these can be added to the recovery catalog as follows: 

    RMAN> catalog datafilecopy '/supp/ .... /systargdb.dbf'; 

To view this file in the catalog, use the following command: 

    RMAN> list copy of database; 
  

7. Backing up in noarchivelog mode 

Database status: 
Recovery catalog: open 
Target: database mounted 

Recovery catalog database is OPEN, target database is started (optionally 
mounted). Because the target database is not in archivelog mode, it must 
not be open when performing backups of datafiles. This would be equivalent 
of making filesystem copies of datafiles without putting tablespaces into 
hot backup mode. If the database is open and not in archivelog mode, RMAN 
will generate an error when you attempt to perform a datafile backup 

7.1. Example of how to back up a complete database 

    RMAN> run { 
    2> # backup the complete database to disk 
    3> allocate channel dev1 type disk; 
    4> backup 
    5> full 
    6> tag full_db_sunday_night 
    7> format '/oracle/backups/db_t%t_s%s_p%p' 
    8> (database); 
    9> release channel dev1; 
    10> } 

Line# 
2: Comment line (anything after the '#' is a comment) 
3&9: See section 15 - Channels 
5: Full backup (default if full or incremental not specified) 
6: Meaningful string (<=30 chars) 
7: Filename to use for backup pieces, including substitution variables. 
8: Indicates all files including controlfiles are to be backed up 

To view this backup in the catalog, use the following command: 

    RMAN> list backupset of database; 
  

7.2. Example of how to back up a tablespace 

    RMAN> run { 
    2> allocate channel dev1 type disk; 
    3> backup 
    4> tag tbs_users_read_only 
    5> format '/oracle/backups/tbs_users_t%t_s%s' 
    6> (tablespace users); 
    7> release channel dev1; 
    10> } 

Line# 
6: Specifying only the USERS tablespace for backup 

To view this tablespace backup in the catalog, use the following command: 

    RMAN> list backupset of tablespace users; 

If for example the USERS tablespace is going to be put READ ONLY after 
being backed up, subsequent full database backups would not need to 
backup this tablespace. To cater for this, specify the 'skip readonly' 
option in subsequent backups. 

Note that although this is a tablespace backup, the target database 
does NOT have to be open, only mounted. This is because tablespace 
information is stored in the controlfile in o8. 
  

7.3. Example of how to backup individual datafiles 

    RMAN> run { 
    2> allocate channel dev1 type 'SBT_TAPE'; 
    3> backup 
    4> format '%d_%u' 
    5> (datafile '/oracle/dbs/sysbigdb.dbf'); 
    6> release channel dev1; 
    7> } 

Line# 
2: Allocates a tape drive using the media manager layer (MML) 
Note that no tag was specified and is therefore null. 

To view this tablespace backup in the catalog, use the following command: 

    RMAN> list backupset of datafile 1; 

7.4. Copying datafiles 

    RMAN> run { 
    2> allocate channel dev1 type 'SBT_TAPE'; 
    3> copy datafile '/oracle/dbs/temp.dbf' to '/oracle/backups/temp.dbf'; 
    4> release channel dev1; 
    5> } 

To view this file copy in the catalog, use the following command: 

    RMAN> list copy of datafile '/oracle/dbs/temp.dbf'; 

Copying a datafile is different to backing up a datafile. A datafile copy 
is an image copy of the file. A backup of the file creates a backupset. 

7.5. Backing up the controlfile 

    RMAN> run { 
    2> allocate channel dev1 type 'SBT_TAPE'; 
    3> backup 
    4> format 'cf_t%t_s%s_p%p' 
    5> tag cf_monday_night 
    6> (current controlfile); 
    7> release channel dev1; 
    8> } 

Note that a database backup will automatically back up the controlfile. 
  

8. Backing up in archivelog mode 

Database status: 
Recovery catalog: open 
Target: instance started, database mounted or open 

The commands are identical to those in section 7 except that the target 
database is in archivelog mode. 

8.1. Backing up archived logs 

The following script backs up all archive logs: 

    RMAN> run { 
    2> allocate channel dev1 type disk; 
    3> backup 
    4> format '/oracle/backups/log_t%t_s%s_p%p' 
    5> (archivelog all); 
    6> release channel dev1; 
    7> } 

The following script backs up archive logs from sequence# 90 to 100: 

    RMAN> run { 
    2> allocate channel dev1 type disk; 
    3> backup 
    4> format '/oracle/backups/log_t%t_s%s_p%p' 
    5> (archivelog from logseq=90 until logseq=100 thread 1); 
    6> release channel dev1; 
    7> } 

The following script backs up all archive logs generated in the past 
24 hours. Furthermore it actually deletes the logs after backing them 
up. If the backup fails, logs will NOT be deleted: 

    RMAN> run { 
    2> allocate channel dev1 type disk; 
    3> backup 
    4> format '/oracle/backups/log_t%t_s%s_p%p' 
    5> (archivelog from time 'sysdate-1' all delete input); 
    6> release channel dev1; 
    7> } 

To view the archive logs in the catalog, use the following command: 

    RMAN> list backupset of archivelog all; 

Note that RMAN will backup specified logs if it finds them. If it can't 
find a log, it will report rman-6089 error: 
"archived log %s not found or out of sync with catalog", 
and it will abort a backup session. 
  

8.2. Backing up the online logs 

Online logs CANNOT be backed up using RMAN; they must be archived first. 
To do this, you can issue SQL commands from RMAN e.g. 

    RMAN> run { 
    2> allocate channel dev1 type disk; 
    3> sql "alter system archive log current"; 
    4> backup 
    5> format '/oracle/backups/log_t%t_s%s_p%p' 
    6> (archivelog from time 'sysdate-1' all delete input); 
    7> release channel dev1; 
    8> } 

The above script might be run after performing a full 'database open' 
backup. It would ensure that all redo to recover the database to a 
consistent state would be backed up. 

Note, you cannot tag archive log backupsets. 
  

9. Incremental backups 

A level N incremental backup backs up blocks that have changed since the 
most recent incremental backup at level N or less. 

9.1. Level 0 - the basis of the incremental backup strategy 

    RMAN> run { 
    2> allocate channel dev1 type disk; 
    3> backup 
    4> incremental level 0 
    5> filesperset 4 
    6> format '/oracle/backups/sunday_level0_%t' 
    7> (database); 
    8> release channel dev1; 
    9> } 

Line# 
4: Level 0 backup - backups of level > 0 can be applied to this 
5: Specifies maximum files in the backupset 

A list of the database backupsets will show the above backup. The 'type' 
column is marked 'Incremental'; the 'LV' column shows '0'. 

9.2. Example backup strategy using incremental backups 

A typical incremental backup cycle would be as follows: 

    - Sun night - level 0 backup performed 
    - Mon night - level 2 backup performed 
    - Tue night - level 2 backup performed 
    - Wed night - level 2 backup performed 
    - Thu night - level 1 backup performed 
    - Fri night - level 2 backup performed 
    - Sat night - level 2 backup performed 

If the database suffered a failure on Sat morning and this resulted in 
a restore operation, RMAN could recover to the point of failure by 
restoring the backups from Sunday, Thursday, and Friday. This is 
because Thursdays level 1 backup contains all changes since Sunday, and 
Friday's level 2 backup contains all changes since Thursday. Whether 
the database could be completely recovered would depend on whether 
archive logging is enabled. 
  

10. Cumulative incremental backups 

A cumulative incremental backup backs up all blocks that have changed since 
the the most recent incremental backup at level N-1 or less (contrast with 
non-cumulative incremental backups that backup blocks that have changed 
since the the most recent incremental backup at level N or less). This 
means that more work is done in performing the backup (duplication of 
backup effort), but time may be saved when restoring (potentially fewer 
backupsets to restore). 

    RMAN> run { 
    2> allocate channel dev01 type disk; 
    3> backup incremental level 1 cumulative database; 
    4> release channel dev01; 
    5> } 
  
  

11. Checking backup progress 

To check the backup progress run the following sql against the target 
database: 

select sid, serial#, context 
          round(sofar/totalwork*100,2) "% Complete", 
         substr(to_char(sysdate,'yymmdd hh24: mi:ss'),1,15) "Time Now" 
from  v$session_longops 
where compnam = 'dbms_backup_restore';  -- for 8.0 
where substr(opname,1,4) = 'RMAN';          -- for 8.1 

This will produce an output such as: 

SID         SERIAL#    CONTEXT    % Complete            Time Now 
---------- ----------    ----------       -----------------      --------------- 
12                                         &nbs 14:21:07 
  
  

12. Recovery 

As with backup, recovery is probably best explained with a few examples 

12.1. Database open, datafile deleted 

Datafile has been deleted from a running database. There are two methods 
of open database recovery: restore the datafile and recover either the 
datafile, or the tablespace. The next two examples show both methods: 

(a) Datafile recovery 

    RMAN> run { 
    2> allocate channel dev1 type disk; 
    3> sql "alter tablespace users offline immediate"; 
    4> restore datafile 4; 
    5> recover datafile 4; 
    6> sql "alter tablespace users online"; 
    7> release channel dev1; 
    8> } 

(b) Tablespace recovery 

    RMAN> run { 
    2> allocate channel dev1 type disk; 
    3> sql "alter tablespace users offline immediate"; 
    4> restore tablespace users; 
    5> recover tablespace users; 
    6> sql "alter tablespace users online"; 
    7> release channel dev1; 
    8> } 

Note that if it is the system tablespace datafiles to be restored, the 
database must be closed. It is not possible to offline the system 
tablespace. 

12.2. Complete restore (lost online redo) and rollforward - database closed 

    RMAN> run { 
    2> allocate channel dev1 type disk; 
    3> set until logseq=105 thread=1; 
    4> restore controlfile to '/oracle/dbs/ctrltargdb.ctl'; 
    5> replicate controlfile from '/oracle/dbs/ctrltargdb.ctl'; 
    6> restore database; 
    7> sql "alter database mount"; 
    8> recover database; 
    9> sql "alter database open resetlogs"; 
    10> release channel dev1; 
    11> } 
    RMAN> reset database; 
Notes: 
- The 'set until' command dictates at which log sequence recovery will 
stop. It is critical that this command is issued BEFORE datafiles 
are restored, otherwise RMAN will attempt to restore the most recent 
set of datafiles, which could be ahead of the specified log 
- The 'replicate controlfile' copies the restored controlfile to 
the controlfiles referenced in init.ora 
- Because the database is opened with resetlogs, it is necessary to 
register the new incarnation of the database with the RESET DATABASE 
command. As with v7, it is important to take a full backup of the 
database immediately after a resetlogs 

12.3. Restore of a subset of datafiles, complete recovery 

    RMAN> run { 
    2> allocate channel dev1 type disk; 
    3> sql "alter database mount"; 
    4> restore datafile 2; 
    5> restore datafile 3; 
    6> restore archivelog all; 
    7> recover database; 
    8> sql "alter database open"; 
    9> release channel dev1; 
    10> } 
  

13. Scripts 

It is very easy to create and replace stored scripts with RMAN. E.g. 

    RMAN> create script alloc_disk { 
    2> # Allocates one disk 
    3> allocate channel dev1 type disk; 
    4> setlimit channel dev1 kbytes 2097150 maxopenfiles 32 readrate 200; 
    5> } 

    RMAN> replace script rel_disk { 
    2> # releases disk 
    3> release channel dev1; 
    5> } 

    RMAN> replace script backup_db_full { 
    2> # Performs a complete backup 
    3> execute script alloc_disk; 
    4> backup 
    5> .....<backup commands here> 
    6> execute script rel_disk; 
    7> } 

The first 2 scripts allocate and deallocate channels respectively. The 
alloc_disk script additionally specifies the maximum size of backup 
pieces created on this channel (kbytes), the maximum number of input files 
that a backup will have open (maxopenfiles), and the maximum number of 
buffers per second which will be read from each of the input datafiles. 

The 3rd script calls the previously stored scripts either side of 
performing a backup. 

Example of executing a stored script: 

    RMAN> run { 
    2> execute script backup_db_full; 
    3> } 

Note that a stored scripts must be called from within a job command 
list i.e. run { .... execute <script>; ....}. 

It is possible to create a job command list in a flat file and call that 
script from the O/S command line as an RMAN option. E.g. to call scripts 
stored in a file called 'weekly_cold_backup': 

    % rman <other RMAN options> cmdfile weekly_cold_backup 
  

14. Parallelization 

RMAN can parallelize it's operations. When creating backup sets, the 
granule of parallelization is the backup set. E.g. if your backup consists 
of 10 backup sets, RMAN will potentially use 10 channels. To create an 
environment for this to take place, you must allocate sufficient channels 
and dictate the number of backup sets created (using the filesperset 
parameter). E.g. if you are backing up a database consisting of 50 
datafiles and you allocate 20 channels and specify 'filesperset 10', 
only 5 channels will be used. This is because only 5 backup sets (50/10) 
will be created. 

It is also possible to parallelize datafile copy backups by allocating 
multiple channels, and specifying multiple datafiles in one copy command. 
  

15. Corruption detection 

SMR will back up datafiles that contain corrupt blocks. However it is 
possible to set a limit on the number of datablock corruptions; if this 
limit is exceeded the backup terminates. The limit is set using the 
'set maxcorrupt' clause. 

E.g. 

    RMAN> replace script backup_db_full { 
    2> # Performs a complete backup 
    3> execute script alloc_disk; 
    4> set maxcorrupt for datafile 1 to 0; 
    5> backup 
    6> .....<backup commands here> 
    7> execute script rel_disk; 
    8> } 

When the above script the backup will fail if ANY corrupt blocks are 
found in datafile 1. 

Block corruptions are detected by checksum mismatches during backups. The 
checksum option is enabled by default but can be disabled by specifying 
the 'nochecksum' option. 
  

16. Channels 

A channel is a connection from RMAN to a target database. The 'allocate 
channel' command starts a server process on the target instance. It also 
specifies the type of I/O device that the server process will use to 
perform the backup or restore operation. 

Channel control commands can be used to: 

    - Control the O/S resources RMAN uses 
    - Affect the degree of parallelism (see section 13) 
    - Specify limits on I/O bandwidth (set limit read rate) 
    - Specify limits on the size of backup pieces (set limit kbytes) 
    - Specify limits on the number of concurrently open files (set limit 
        maxopenfiles) 
  

17. Report & list commands 

17.1. List 

The list command queries the recovery catalog to produce a formatted 
listing of contents. E.g. 

    RMAN> list backupset of datafile 1; 

Output: 

    Key File Type LV Completion_time Ckp SCN Ckp Time 
    ------- ---- ------------ -- --------------- ---------- -------- 
    165 1 Full Oct 03 11:24 32022 Oct 03 11:24 
    208 1 Full Oct 24 14:27 52059 Oct 24 14:26 
    219 1 Full Oct 24 14:31 52061 Oct 24 14:31 
    << other entries here > 

    RMAN> list backupset of archivelog all; 

Output: 

    Key Thrd Seq Completion time 
    ------- ---- ------- --------------- 
    179 1 94 Oct 03 11:26 
    179 1 95 Oct 03 11:26 
    << other entries here > 

17.2. Report 

The report command also queries the recovery catalog, However, the report 
command syntax is constructed in such a way to produce a more useful 
listing. E.g. the following command can be used to list all datafiles 
in a database that have had UNRECOVERABLE operations performed on objects 
in those datafiles since the last backup: 

    RMAN> report unrecoverable database; 
  

18. Hints, tips, & best practices 

18.1. Resyncing the recovery catalog 

It is very important that the recovery catalog be as up to date as 
possible i.e. it should reflect the state of the target database. This 
is achieved by resyncing the catalog from the target controlfile. 

There are two types of resync operation: full and partial. Furthermore 
a resync can be explicit or implicit. 

A full resync updates the catalog with ALL controlfile information that 
has changed since the last resync. This includes changes to the physical 
structure of the database. A manual (explicit) resync performs a full 
resync, whilst full (implicit) resyncs are performed after an SMR backup. 

A partial resync only updates the catalog with redo log, backupset, and 
datafile copy information i.e. physical structure changes are NOT 
refreshed. A partial (implicit) resync is performed before an SMR backup. 

At a MINIMUM, you should resync the recovery catalog at intervals less 
than the init.ora parameter CONTROL_FILE_RECORD_KEEP_TIME. After this 
number of days, controlfile information will be overwritten. Because 
resyncing is a relatively cheap operation, it is advisable to resync 
as often as possible, especially if the database switches logs 
frequently. The following sample shell script could be scheduled to 
run hourly: 

    rman target un/pw@<target alias> rcvcat un/pw@<rcvcat alias> << EOF 
    resync catalog; 
    exit; 
    EOF 

18.2. Deleting archive logs 

As can be seen from an earlier example, it is possible to direct an SMR 
server session to delete archived redo logs once they have been backed 
up. This option should obviously be used with extreme caution! Only 
ever delete archivelogs if you are 100% satisfied that you have good 
copies/backups elsewhere. 

18.3. Keep it simple 

As with all backup & recovery strategies, they should be as simple as 
possible, and should be tested thoroughly. 

A few simple stored scripts should be adequate for the vast majority 
of backup & recovery requirements. 

18.4. RMAN errors 

When RMAN goes wrong it's spectacular! The error stacks are usually 
very long. If an error is reported, it is worth getting the complete 
stack sent to support as most of the errors will not help in diagnosing 
the problem. 

19. Limitations 

19.1 Enterprise Edition 

Only the following features are available with the Enterprise Edition software: 

    Multiple Channels 
    Incremental Backups 
    Duplexed Backups 

References 

Oracle8 Backup and Recovery Guide 
Oracle8i Recovery Manager User's Guide and Reference