5
Making Backups and Copies with Recovery Manager

This chapter describes how to use Recovery Manager to manage backup and copy operations, and includes the following topics:

Making Backups

Perform backups of any of the following objects using the RMAN backup command:

Database (all datafiles and current control file)
Tablespace
Datafile (current or image copy)
Archived redo log
Control file (current or image copy)

Although RMAN backs up and restores only datafiles, archived redo log files, and control files, the database depends on other files for production operation. You must define a backup and restore strategy for files that RMAN does not support. Examples include initialization files, password files, network configuration files, external procedure files, and external LOB files (BFILEs).

RMAN backs up the files into one or more backup sets on disk or tape. You can set parameters for the backup command to specify the filenames for the backup pieces, the number of files to go in each set, and which channel should operate on each input file.

Note:
Backups using the disk API are not supported (see "After Linking to the Media Manager on UNIX, RMAN Fails to Back Up to Tape"). To back up to disk, allocate a channel of type disk.

You can make RMAN backups when the database is open or closed. Closed backups can be consistent or inconsistent, depending on how the database was shut down; open backups are always inconsistent. Consistent backups can be restored without recovery. An inconsistent backup will require some media recovery when it is restored, but is otherwise just as valid as a consistent backup.

RMAN backup are further divided into full and incremental backups. Full backups are non-incremental, that is, every used block is backed up.

This section contains the following procedures:

Making Consistent and Inconsistent Backups

The procedures in this chapter allow you to make backups when the database is open or closed. Closed backups are either consistent or inconsistent; open backups are always inconsistent. Note that Oracle does not permit inconsistent backups in NOARCHIVELOG mode.

To make a consistent backup, the database:

Must be mounted, but not open.
Must not have crashed or aborted the last time it was open.

If these conditions are not met, the backup will be inconsistent.

Making Whole Database Backups

If you can afford to close your database, Oracle recommends taking closed, consistent backups of your whole database. If you cannot shut down your database, then your only option is to make an open backup.

To make a whole database backup:

Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:
```
% rman target / catalog rman/rman@rcat
```
To write the output to a log file, specify the file at startup. For example, enter:
```
% rman target / catalog rman/rman@rcat log /oracle/log/mlog.f
```
For a consistent backup, mount but do not open the database and ensure that the database was closed cleanly prior to mounting. If the database is open, or is mounted but not closed cleanly when last opened, the backup will be inconsistent.

Allocate one or more channels of type disk or type 'sbt_tape'. This example backs up all the datafiles as well as the control file. It does not specify a format parameter, so RMAN gives each backup piece a unique name automatically and stores it in the port-specific default location ($ORACLE_HOME/dbs on UNIX):

run { 
     allocate channel ch1 type disk;
     backup database;
     sql 'ALTER SYSTEM ARCHIVE LOG CURRENT'; # archives current redo log as well as 
                                             # all unarchived logs
}

Optionally, use the format parameter to specify a filename for the backup piece. For example, enter:

run { 
     allocate channel ch1 type 'sbt_tape';
     backup database
     format '/oracle/backup/%U';  # %U generates a unique filename
}

Optionally, use the tag parameter to specify a tag for the backup. For example, enter:

run { 
     allocate channel ch1 type 'sbt_tape';
     backup database
     tag = 'weekly_backup';   # gives the backup a tag identifier
}

Issue a list command to see a listing of your backup sets and pieces.

Backing Up Tablespaces and Datafiles

Back up tablespaces and datafiles when the database is either open or closed. Note that all open database backups are always inconsistent. Do not issue ALTER DATABASE BEGIN BACKUP before making an online tablespace backup.

To back up a tablespace:

Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:
```
% rman target / catalog rman/rman@rcat
```
If you want to write the output to a message log file, specify the file at startup. For example, enter:
```
% rman target / catalog rman/rman@rcat log "/oracle/log/mlog.f'
```
For a consistent backup, mount but do not open the database and ensure that the database was closed cleanly prior to mounting. If the database is open, or is mounted but not closed cleanly when last opened, the backup will be inconsistent.

Allocate one or more channels before issuing the backup command. This example backs up three tablespaces, using the filesperset parameter to specify that no more than three datafiles should go in each backup set, and also backs up the control file:

run { 
     allocate channel ch1 type disk;
     allocate channel ch2 type disk;
     allocate channel ch3 type disk;
     backup filesperset = 3
       tablespace inventory, sales
       include current controlfile;
}

Issue a list command to see a listing of your backup sets and pieces.

To back up a datafile:

Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:
```
% rman target / catalog rman/rman@rcat
```
If you want to write the output to a message log file, specify the file at startup. For example, enter:
```
% rman target / catalog rman/rman@rcat log '/oracle/log/mlog.f'
```
For a consistent backup, mount but do not open the database and ensure that the database was closed cleanly prior to mounting. If the database is open, or is mounted but not closed cleanly when last opened, the backup will be inconsistent.

Allocate one or more channels before issuing the backup command. This example backs up datafiles 1-6 as well as an image copy of a datafile:

run { 
     allocate channel ch1 type disk;
     backup
       (datafile 1,2,3,4,5,6
       filesperset 3)
       datafilecopy '/oracle/copy/tbs_1_c.f';
}

Issue a list command to see a listing of your backup sets and pieces.

To back up a datafile copy:

Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:
```
% rman target / catalog rman/rman@rcat
```
If you want to write the output to a message log file, specify the file at startup. For example, enter:
```
% rman target / catalog rman/rman@rcat log "/oracle/log/mlog.f'
```
Mount or open the database.

Allocate one or more channels before issuing the backup command. This example backs up datafile copy df1.copy to tape:

run { 
     allocate channel ch1 type 'sbt_tape';
     backup datafilecopy '/oracle/copy/df1.copy';
}

Issue a list command to see a listing of your backup sets and pieces.

Backing Up Control Files

You can make backups of the control file when the database is open or closed. RMAN uses a snapshot control file to ensure a read-consistent version.

Whole database backups automatically include the current control file, but the current control file does not contain a record of the whole database backup. To obtain a control file backup with a record of the whole database backup, make a backup of the control file after executing the whole database backup.

Include a backup of the control file within any backup by specifying the include current controlfile option.

To back up the current control file:

Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:
```
% rman target / catalog rman/rman@rcat
```
If you want to write the output to a log file, specify the file at startup. For example, enter:
```
% rman target / catalog rman/rman@rcat log "/oracle/log/mlog.f'
```
Mount or open the database.

Allocate a channel before issuing the backup command. This example backs up the current control file to tape and uses a tag:

run { 
     allocate channel ch1 type 'sbt_tape';
     backup current controlfile
     tag = mondayPMbackup;
}

Optionally, issue a list command to see a listing of your backup sets and pieces.

To back up a control file copy:

Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:
```
% rman target / catalog rman/rman@rcat
```
If you want to write the output to a log file, specify the file at startup. For example, enter:
```
% rman target / catalog rman/rman@rcat log "/oracle/log/mlog.f'
```
Mount or open the database.
Allocate a channel before issuing the backup command. This example backs up the control file copy '/oracle/copy/cf.f':
```
run { 
     allocate channel ch1 type disk;
     backup controlfilecopy '/oracle/copy/cf.f';
}
```
Optionally, issue a list command to see a listing of your backup sets and pieces.

To include the current control file in another backup:

Specify the include current controlfile option after specifying the backup object. For example, this command backs up tablespace FOO and includes the current control file in the backup:

run {
     allocate channel c1 type disk;
     backup tablespace foo 
       include current controlfile;
}

Backing Up Archived Redo Logs

The archived redo logs are the key to successful recovery. Back them up regularly. To back up archived logs, allocate one or more channels and issue backup archivelog with the desired filtering options:

run {
     allocate channel t1 type 'sbt_tape';
     backup archivelog all
       delete input;
}

See Also:
"Backing Up in an OPS Environment" to learn about special considerations when backing up in OPS mode.

Note if you archive to multiple locations, RMAN does not put multiple copies of the same log sequence number into the same backup set. The backup archivelog all command backs up exactly one copy of each distinct log sequence number,

If you specify the delete input option, then RMAN only deletes the specific copy of the archived redo log that it backs up. Note that you can specify the delete input option in the backup command, which deletes the archived redo logs after you have backed them up. For example, issue:

run {
     allocate channel t1 type 'sbt_tape';
     backup archivelog all
       delete input;
}

Thus, you can back up archived logs to tape and clear your disk space of old logs in one step.

See Also:
"Backing Up and Deleting Multiple Copies of an Archived Redo Log" for a scenario involving a backup of logs located in multiple destinations.

To back up archived redo logs:

Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:
```
% rman target / catalog rman/rman@rcat
```
If you want to write the output to a log file, specify the file at startup. For example, enter:
```
% rman target / catalog rman/rman@rcat log "/oracle/log/mlog.f'
```
Mount or open the database.

Allocate a channel before issuing the backup command. This example backs up all of the archived redo log files to tape and deletes the input logs from disk:

run { 
     allocate channel ch1 type 'sbt_tape';
     backup archivelog all         # Backs up all archived redo logs.    
       delete input;               # Optionally, delete the input logs
}

You can also specify a range of archived redo logs by time, SCN, or log sequence number. This example backs up all archived logs created more than 7 and less than 30 days ago:

run { 
     allocate channel ch1 type disk;
     backup archivelog 
       from time 'SYSDATE-30' until time 'SYSDATE-7';
}

Issue a list command to see a listing of your backup sets and pieces.

Backing Up in an OPS Environment

Backing up archived redo logs in an OPS environment poses special problems. To illustrate, assume the following:

Node 1 archives to its local file system
Node 2 archives to its local file system
Node 3 archives to its local file system

If you allocate channels and then issue backup archivelog all, the default channel attempts to validate all the logs on only one node, causing the job to fail. Solve this problem by specifying which channel should back up which logs.

To back up archived redo logs in an OPS environment:

Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:
```
% rman target / catalog rman/rman@rcat
```
If you want to write the output to a log file, specify the file at startup. For example, enter:
```
% rman target / catalog rman/rman@rcat log "/oracle/log/mlog.f'
```
Mount or open the database.
Perform the following tasks within the run command:
- Allocate a channel for each node of the OPS cluster.
- Force each channel to back up only those logs to which it has access by using the like pathname parameter.
This example connects to three different nodes and informs each channel that it should only back up those logs contained in the directory to which it has access (where node1_arc_dest refers to a directory containing the logs on node 1, node2_arc_dest refers to a directory containing the logs on node 2, etc.):
```
run { 
     allocate channel node1 type 'sbt_tape' connect '@node1'; 
     allocate channel node2 type 'sbt_tape' connect '@node2'; 
     allocate channel node3 type 'sbt_tape' connect '@node3'; 
 
     backup (archivelog like '/node1_arc_dest%' channel node 1) 
            (archivelog like '/node2_arc_dest%' channel node 2) 
            (archivelog like '/node3_arc_dest%' channel node 3); 
}
```

See Also:
"backup" for backup syntax and a description of the like parameter, and "Backing Up in a Parallel Server Environment" for a scenario involving backing up archived logs in an OPS environment.

Making Incremental Backups

You can make consistent or inconsistent incremental backups of the database or individual tablespaces or datafiles. This procedure makes an incremental backup of a database that was shut down cleanly.

To make a consistent, incremental backup:

Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:
```
% rman target / catalog rman/rman@rcat
```
For a consistent backup, mount but do not open the database and ensure that the database was closed cleanly prior to mounting. If the database is open, or is mounted but not closed cleanly when last opened, the backup will be inconsistent.

Allocate a channel before issuing the backup command. This example makes a level 0 backup of the database:

run { 
     allocate channel ch1 type disk;
     backup 
       incremental level = 0
       database;
}

This example makes a differential level 1 backup of the SYSTEM tablespace and datafile sales.f. It will only back up those data blocks changed since the most recent level 1 or level 0 backup:

run { 
     allocate channel ch1 type disk;
     backup 
       incremental level = 1
       tablespace system
       datafile '/oracle/dbs/sales.f';
}

This example makes a cumulative level 2 backup of the tablespace TBS_2. It will only back up those data blocks changed since the most recent level 1 or level 0 backup:

run { 
     allocate channel ch1 type disk;
     backup 
       incremental level = 2 cumulative  # specify cumulative option
       tablespace tbs_1;
}

Optionally, issue a list command to see a listing of your backup sets and pieces.

Making Split Mirror Backups

Many sites keep an on-disk backup of the database in case a failure occurs on the primary database or an incorrect user action such as a drop table requires incomplete recovery. An on-disk datafile backup simplifies the restore step of recovery, making recovery much quicker and more reliable.

Note:
Never make backups, split mirror or otherwise, of online redo logs. Also, it is best to use the backup controlfile command rather than a split mirror to make control file backups.

A common way of creating an on-disk datafile backup is to use disk mirroring. For example, you can use the operating system to maintain three identical copies of each file in the database. In this configuration, you can split off a mirrored copy of the database once a day to use as a backup.

RMAN does not automate the splitting of the mirrors, but can make use of the split mirrors in backup and recovery operations. For example, RMAN can treat a split mirror of a datafile as a datafile copy, and can also back up this copy to disk or tape.

To make a split mirror backup of a tablespace:

Place the tablespaces that you want to back up into hot backup mode through ALTER TABLESPACE ... BEGIN BACKUP. For example, to place tablespace TBS_3 in hot backup mode enter:
```
ALTER TABLESPACE tbs_3 BEGIN BACKUP; 
```
Split the mirrors for the underlying datafiles contained in these tablespaces. See Oracle8i Backup and Recovery Guide for more information about splitting mirrors.
Take the tablespaces out of hot backup mode:
```
ALTER TABLESPACE tbs_3 END BACKUP;
```
Catalog the mirror copies as datafile copies using the catalog command. For example, enter:
```
catalog datafilecopy '/disk2/dbs/tbs_3.f';  # catalog split mirror
```

Back up these datafile copies using the rman backup command. For example, enter:

run {
     allocate channel c1 type disk;
     backup datafilecopy '/disk2/dbs/tbs_3.f';
}

When you are ready to resilver the split mirror, first use the change ... delete command to uncatalog the datafile copies you cataloged in step 4. For example, enter:
```
allocate channel for delete type disk;
change datafilecopy '/disk2/dbs/tbs_3.f' delete;
```
Resilver the split mirror for the affected datafiles.

Making Image Copies

In many cases, making a copy is better than making a backup, because copies are not in an RMAN-specific format and hence are suitable for use without any additional processing. In contrast, you must process a backup set with a restore command before it is usable. So, you can perform media recovery on a datafile copy, but not directly on a backup set, even if it contains only one datafile and is composed of a single backup piece.

Note:
You cannot make incremental copies, although you can use the level parameter to make a copy serve as a basis for subsequent incremental backup sets.

Use the copy command to create image copies. RMAN always writes the output file to disk. You can copy the following types of files:

Datafiles (current or copies)
Archived redo logs
Control files (current or copies)

To make consistent copies of all database files:

Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:
```
% rman target / catalog rman/rman@rcat
```
For a consistent backup, mount but do not open the database and ensure that the database was closed cleanly prior to mounting. If the database is open, or is mounted but not closed cleanly when last opened, the backup will be inconsistent.

Generate a report of the current database schema:

RMAN> report schema;
 
RMAN-03022: compiling command: report
Report of database schema
File K-bytes    Tablespace           RB segs Name
---- ---------- -------------------- ------- -------------------
1         35840 SYSTEM               YES     /oracle/dbs/tbs_01.f
2           978 SYSTEM               YES     /oracle/dbs/tbs_02.f
3           978 TBS_1                NO      /oracle/dbs/tbs_11.f
4           978 TBS_1                NO      /oracle/dbs/tbs_12.f

Copy all of the datafiles and include the current control file. For example, enter:

run { 
     allocate channel ch1 type disk;
     copy 
       datafile 1 to '/oracle/copy/df_1.f',
       datafile 2 to '/oracle/copy/df_2.f',
       datafile 3 to '/oracle/copy/df_3.f',
       datafile 4 to '/oracle/copy/df_4.f',
       current controlfile to '/oracle/copy/cf.f';
}

Issue a list copy command to see a listing of your copies.

To copy datafiles, archived redo logs, and control files:

Start RMAN and connect to the target database and, optionally, the recovery catalog database. For example, enter:
```
% rman target / catalog rman/rman@rcat
```
For a consistent backup, mount but do not open the database and ensure that the database was closed cleanly prior to mounting. If the database is open, or is mounted but not closed cleanly when last opened, the backup will be inconsistent.

Copy the desired datafiles, archived redo logs, and control files. For example, enter:

run { 
     allocate channel ch1 type disk;
     # allocate multiple channels for parallelization. For parallelization, issue one
     # copy command rather than multiple copy commands.
     allocate channel ch2 type disk;
     allocate channel ch3 type disk;
     copy 
       # copy datafiles and datafile copies
       datafile '/oracle/dbs/tbs_8.f' to '/oracle/copy/df_8.f',
       datafilecopy '/oracle/copy/df_2.cp' to '/oracle/dontouch/df_2.f',
       datafilecopy tag = 'weekly_df1_copy' to '/oracle/copy/df_1.f',

       # copy archived redo logs
       archivelog '/oracle/arc_dest/arcr_1_1.arc' to '/oracle/copy/arcr_1_1.arc',
       archivelog '/oracle/arc_dest/arcr_1_2.arc' to '/oracle/copy/arcr_1_2.arc',

       # copy a control file copy
       controlfilecopy '/oracle/copy/cf.f' to '/oracle/dontouch/cf.f';
}

Issue a list copy command to see a listing of your copies.

Backup and Copy Scenarios

Following are some useful scenarios for performing backups and copies:

Reporting Datafiles Needing Backups

The following command reports all datafiles in the database that would require the application of 6 or more incremental backups to be recovered to their current state:

report need backup incremental 6 database;

The following command reports all datafiles from tablespace SYSTEM that have not had a backup (full or incremental) in five or more days:

report need backup days 5 tablespace system;

Skipping Files when Backing Up a Database

The following example, which assumes that the database is running in ARCHIVELOG mode, shows a common way to back up the database (skipping tablespaces that are offline):

run {
     allocate channel dev1 type 'sbt_tape';
     backup database
       skip readonly
       skip offline; 
}

You need to back up a read-only tablespace only once after it has been made read-only. You can use the skip readonly option to skip read-only datafiles. If you use the skip offline option, then the backup command does not attempt to access offline datafiles. Use this option if the offline datafiles are not available.

Spreading a Backup Across Multiple Disk Drives

Typically, you do not need to specify a format when backing up to tape because the default %U conversion variable generates a unique filename for all tape backups. When backing up to disk, however, you can specify a format if you want to spread your backup across several disk drives for improved performance. In this case, allocate one disk channel per disk drive and specify the format string on the allocate channel command. Specify the format so that the filenames are on different disks.

For example, issue:

run { 
     allocate channel disk1 type disk format '/disk1/%d_backups/%U'; 
     allocate channel disk2 type disk format '/disk2/%d_backups/%U'; 
     allocate channel disk3 type disk format '/disk3/%d_backups/%U'; 
     backup database; 
}

Backing Up a Large Database to Multiple Filesystems

In this scenario, you have a 40Gb database that you want to back up to disk. Because RMAN does not back up to raw disk, you must spread the backup across filesystems. You decide to back up to 4 filesystems and make each backup set roughly the same size: 10Gb. You want to make each backup piece no more than 2Gb so that each backup set contains 5 backup pieces.

You decide to use the format parameter of the allocate channel command so that each channel will write to a different filesystem. You use conversion variables to guarantee unique names for the backup pieces. For example, the following RMAN script spreads the backup across four filesystems (/fs1, /fs2, /fs3, /fs4), creating 4 backup sets in these directories and grouping the datafiles so that each backup set is about the same size.

run { 
     allocate channel fs1 type disk format='/fs1/%u.%p'; 
     allocate channel fs2 type disk format='/fs2/%u.%p'; 
     allocate channel fs3 type disk format='/fs3/%u.%p'; 
     allocate channel fs4 type disk format='/fs4/%u.%p'; 
 
     set limit channel fs1 kbytes=2000000;  #limit file size to 2Gb 
     set limit channel fs2 kbytes=2000000; 
     set limit channel fs3 kbytes=2000000; 
     set limit channel fs4 kbytes=2000000; 
 
     backup database; 
}

Specifying the Size of Backup Sets

When making backups, RMAN divides the total number of files requiring backups by the number of allocated channels to calculate the number of files to place in each backup set. Use the filesperset and setsize parameters to override this calculation and specify how many files should go in each backup set.

Using filesperset

When you specify the filesperset parameter, RMAN compares the filesperset value to the automatically calculated value (number of files / allocated channels) and takes the lowest of the two values, thereby ensuring that all channels are used. For example, if you are backing up 12 datafiles with 3 channels, and set filesperset = 2, RMAN puts 2 datafiles into each backup set rather than 4.

If the number of files specified or implied by the combined backupSpec clauses is greater than filesperset, for example, 8 total files need backing up when filesperset = 4, then RMAN creates multiple backup sets to maintain the correct ratio of files per backup set.

If you do not specify filesperset, RMAN compares the calculated value (number of files / allocated channels) to the default value of 64 and takes the lowest of the two values, again ensuring that all channels are used. The default value of 64 is high for most applications: specify a lower value or use the setsize parameter to limit the size of a backup set.

RMAN always attempts to create enough backup sets so that all allocated channels have work to do. An exception to the rule occurs when there are more channels than files to back up. For example, if RMAN backs up one datafile when three channels are allocated and filesperset = 1, then two channels are necessarily idle.

This example parallelizes a backup, specifying that no more than 3 datafiles go in any one backup set, and no more than 1 archived redo log in any one backup set:

run {
     allocate channel ch1 type disk;
     allocate channel ch2 type disk;
     allocate channel ch3 type disk;
     allocate channel ch4 type disk;
     backup 
       datafile 1,2,3,4,5,9,10,11,12,15
         filesperset = 3
       archivelog all
         filesperset = 1;
}

Using setsize

The setsize parameter specifies a maximum size for a backup set in units of 1K (1024 bytes). Thus, to limit a backup set to 2Mb, specify setsize = 2000. RMAN attempts to limit all backup sets to this size, which is useful in media manager configurations when you want each backup set to be no larger than one tape.

Configure your backup sets so that they fit on one tape volume rather than span multiple tape volumes. Otherwise, if one tape of a multi-volume backup set fails, then you lose the whole backup set.

The setsize parameter is easier to use than filesperset when you make backups of archived redo logs. This example backs up archived redo logs to tape, setting the size at 2Mb to ensure that each backup set fits on one tape volume:

run {
     allocate channel ch1 type 'sbt_tape';
     allocate channel ch2 type 'sbt_tape';
     backup setsize = 2000
       archivelog all;

}

Specifying the Size of Backup Pieces

Backup piece size is an issue in those situations where it exceeds the maximum file size of the file system or media management device. Use the kbytes parameter of the set channel limit command to limit the size of backup pieces.

For example, if your media manager only support files sized 8Mb or less, you can issue the following command when making tape backups of your database:

run {
     allocate channel c1 type 'sbt_tape';
     set limit channel kbytes = 8000;
     backup database;
}

Multiplexing Datafiles in a Backup

Assume you want to back up a database called FOO. The following conditions obtain:

You have three tape drives available for the backup.
The database contains 26 datafiles.
You want to multiplex datafiles into the backup, placing 4 datafiles into each backup set.

You set filesperset equal to 4 because it is sufficient to keep the tape drive streaming. In this example, you are not concerned about how datafiles are grouped into backup sets.

Issue the following commands:

create script foo_full {
   allocate channel t1 type 'SBT_TAPE';
   allocate channel t2 type 'SBT_TAPE';
   allocate channel t3 type 'SBT_TAPE';
   backup filesperset 4
   database format 'FOO.FULL.%n.%s.%p';
}

This script backs up the whole database, including all datafiles and the control file. Because there are 27 files to be backed up (26 datafiles and a control file) and a maximum of 4 files per backup set, Oracle creates seven backup sets. The backup piece filenames have the following format, where db_name is the database name, set_num is the backup set number, and piece_num is the backup piece number:

FOO.FULL.db_name.set_num.piece_num
# for example, a file may have the following name:
FOO.FULL.prod1.3.1

Assuming no backup sets have been recorded in the recovery catalog prior to this job, then set_num will range from 1 through 7 and piece_num will be 1 or more.

Note that in the SBT API version 2.0, media vendors can specify the maximum size of a backup piece, causing RMAN to comply with this restriction automatically.

Backing Up Archived Redo Logs

You can also back up archived redo logs to tape. You can specify the range of archived redo logs by time, SCN, or log sequence number.

Note:
If specifying by time range, set the NLS_LANG and NLS_DATE_FORMAT environment variables before invoking Recovery Manager. See "Setting NLS Environment Variables".

Specifying an archived log range does not guarantee that RMAN backs up all redo in the range. For example, the last archived log may end before the end of the range, or a log in the range may be missing. RMAN backs up the logs it finds and does not issue a warning. Online logs cannot be backed up; you must first archive them.

This example backs up the logs archived between 8:57 p.m. and 9:06 p.m. on November 18, 1998.

NLS_LANG=american
NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS'
run {
     allocate channel dev1 type 'sbt_tape';
     backup
     archivelog all
       from time  'Nov 13 1998 20:57:13'
       until time 'Nov 13 1998 21:06:05';
}

The following example backs up all archived logs from sequence# 288 to sequence# 301 and deletes the archived redo logs after the backup is complete. If the backup fails the logs are not deleted.

run {
     allocate channel dev1 type 'sbt_tape';
     backup
       archivelog from logseq 288 until logseq 301 thread 1
       delete input;
}

The following command backs up all archived logs generated during the last 24 hours. The example archives the current redo log first to ensure that all redo generated up to the present gets backed up.

run {  
     allocate channel dev1 type 'sbt_tape';  
     sql "ALTER SYSTEM ARCHIVE LOG CURRENT"; 
     backup archivelog from time 'SYSDATE-1';  
}

See Also:
Your operating system-specific documentation for more information about your environment variables.

Backing Up and Deleting Multiple Copies of an Archived Redo Log

In this scenario, you set your initialization parameters so that you automatically archive your redo logs to two locations: /oracle/arch/dest_1/* and /oracle/arch/dest_2/*. Therefore, you have two identical copies of the archived redo log for each log sequence number. You decide to back up each copy of your archived redo logs and then delete the originals.

Because the backup archivelog all command backs up exactly one copy of each distinct log sequence number, RMAN does not put two copies of the same log sequence number into the same backup set. Furthermore, if you specify the delete input option, RMAN only deletes the specific copy of the archived redo log that it backs up.

The easiest solution in this case is to back up both copies of each archived redo log and then delete both copies. Use the like parameter of the archivelogRecordSpecifier to indicate which destination to use. The like parameter allows you to match file filenames in both of your archive destinations. For example, execute the following:

run { 
     allocate channel t1 type 'sbt_tape'; 
     allocate channel t2 type 'sbt_tape'; 
     backup 
       filesperset=20 
       format='al_%d/%t/%s/%p' 
       (archivelog like '/oracle/arch/dest1/%' channel t1 delete input) 
       (archivelog like '/oracle/arch/dest2/%' channel t2 delete input); 
}

This example backs up the archived redo logs in the primary destination on one set of tapes and the logs from the second destination on another set of tapes. This scenario assumes that you have two tape drives available. Note that some tape subsystems will combine the two RMAN channels into a single data stream and write them to a single tape drive. You may need to configure your media management vendor to prevent this scenario from occurring.

Performing Differential Incremental Backups

A differential incremental backup contains only blocks that have been changed since the most recent backup at the same level or lower. The first incremental backup must be a level 0 backup that contains all used blocks.

run {
     allocate channel dev1 type 'sbt_tape';
     backup incremental level 0
       database;
}

An incremental backup at level 1 or higher will contain all blocks changed since the most recent level 1 backup. If no previous level 1 backup is available, RMAN copies all blocks changed since the base level 0 backup.

run { 
     allocate channel dev1 type 'sbt_tape'; 
     backup incremental level 1  
       database;  
}

If you add a new datafile or tablespace to the database, then make a level 0 backup before making another incremental backup. Otherwise, the incremental backup of the tablespace or the database will fail because Recovery Manager does not find a parent backup for the new datafiles.

run {
     allocate channel dev1 type 'sbt_tape';
     backup incremental level 0
       tablespace new_tbs;
}

Note that you can perform incremental backups in NOARCHIVELOG mode.

Performing Cumulative Incremental Backups

A cumulative incremental backup at level n contains only blocks that have been changed since the most recent backup at level n - 1 or lower. Cumulative backups require more storage space than differential backups, but they are preferable during a restore operation because only one backup for a given level is needed. Note that the first incremental backup must be a level 0 backup that contains all used blocks.

A cumulative backup at level 2 will contain all blocks changed since the most recent level 1 backup, copying all blocks changed since the base level 0 backup only if a previous level 1 is unavailable. In contrast to a cumulative backup, a differential backup at level 2 will determine which level 1 or level 2 backup occurred most recently and copy all blocks changed since that backup.

run { 
     allocate channel dev1 type 'sbt_tape'; 
     backup incremental level 2 cumulative  # blocks changed since level 0 or level 1 
       database;  
}

Duplexing Backup Sets

Prudence suggests making multiple copies of your backups to protect against disaster, media damage, or human error. Oracle allows you to make up to four backup sets simultaneously, each an exact duplicate of the others.

The set duplex command, which affects only the backup command, specifies the number of copies of each backup piece that RMAN should create. The set duplex command affects all channels allocated after issuing the command and is in effect until explicitly disabled (OFF) or changed during the session.

Note:
The set duplex command will generate an error if there are previously allocated channels.

For example, you can enter:

run {
     set duplex=3;
     allocate channel ch1 type 'sbt_tape';
     backup datafile 1;
}

This command will create three identical backups of datafile 1. Each backup piece will have a unique name since the %U default format guarantees it.

Note that you must set the BACKUP_TAPE_IO_SLAVES initialization parameter to TRUE in order to perform duplexed backups; otherwise, an error will be signaled. RMAN will configure as many slaves as needed for the number of backup copies you request.

See Also:
Oracle8i Reference for more information on the BACKUP_TAPE_IO_SLAVES initialization parameter.

Determining How Channels Distribute a Backup Workload

If you want to create multiple backup sets and allocate multiple channels, then RMAN automatically parallelizes its operation and writes multiple backup sets in parallel. The allocated server sessions divide up the work of backing up the specified datafiles, control files, and archived redo logs. Note that you cannot stripe a single backup set across multiple channels.

RMAN automatically assigns a backup set to a device. You can specify that Oracle should write all backup sets for a backupSpec to a specific channel using the channel parameter.

For example, this example parallelizes the backup operation by specifying which channels RMAN should allocate for which operations:

run {
     allocate channel ch1 type 'SBT_TAPE';
     allocate channel ch2 type disk;
     allocate channel ch3 type disk;
     backup 
       # channel ch1 backs up datafiles to tape
       (datafile 1,2,3,4 
       channel ch1)
       # channel ch2 backs up control file copy to disk
       (controlfilecopy '/oracle/copy/cf.f'
       channel ch2)
       # channel ch3 backs up archived redo logs to disk
       (archivelog from time 'SYSDATE-14'
       channel ch3);
}

Backing Up in NOARCHIVELOG Mode

This script puts the database into the correct mode for a consistent, whole database backup and then backs up the database. Note that the script performs a shutdown, startup, shutdown, and then startup again before performing a duplexed backup:

# Shut down the database cleanly using immediate priority. This type of shutdown lets  
# current calls to the database complete, but prevents further logons or calls. 
# If the database is not up now, you will get a message saying so but RMAN will not 
# treat this situation as an error.
  
shutdown immediate; 
  
# Start up the database in case it crashed or was not shutdown cleanly prior to
# starting this script. This will perform a crash recovery if it is needed. Oracle   
# uses the default INIT.ORA file. Alternatively, use this form:  startup force dba
# pfile=<filename>. Use the DBA option because you are going to shut down again right
# away and do not want to let users in during the short interval. Use the FORCE 
# option because it cannot hurt and might help in certain situations. 
  
startup force dba; 
shutdown immediate; 
  
# Here, we know that the database is cleanly closed and is now ready for a cold
# backup. RMAN requires that the database be started and mounted to perform a backup,
# so do that now. 
  
startup mount; 
run {
        # duplex the backup
        set duplex = 2;

     #  allocate channel t1 type 'SBT_TAPE'; 
     #  allocate channel t2 type 'SBT_TAPE'; 
        allocate channel t1 type disk; 
        allocate channel t2 type disk; 
  
        set limit channel t1 kbytes 2097150; 
        set limit channel t2 kbytes 2097150; 

        backup 
          incremental level 0 
          filesperset 5 
          database; 
}

# now that the backup is complete, open the database. 
alter database open;

Note that you can skip tablespaces, but any skipped tablespace that has not been offline or read-only since its last backup will be lost if the database has to be restored from a backup. When backing up to disk, make sure that the destination (file system or raw device) has enough free space.

Backing Up in a Parallel Server Environment

The following script distributes datafile and archived redo log backups across two nodes in a parallel server environment:

run { 
     allocate channel node_1 type disk connect 'sys/sys_pwd@node_1'; 
     allocate channel node_2 type disk connect 'sys/sys_pwd@node_2'; 
        backup filesperset 1  
          (tablespace system, rbs, data1, data2 
           channel node_1)
          (tablespace temp, reccat, data3, data4 
           channel node_2); 
        backup filesperset 20 
          (archivelog  
           until time 'SYSDATE'  
           like "/node1/arc/%" 
           delete input 
           channel node_1); 
          (archivelog  
           until time 'SYSDATE' 
           like "/node2/arc/%"
           delete input 
           channel node_2); 
}

Cataloging Operating System Copies

You can use operating system utilities to make datafile copies and then catalog them in the recovery catalog. Note that you can only catalog copies made to disk. Because the format of backup pieces is proprietary, operating system utilities cannot write backups that Recovery Manager can read.

You must make the datafile copies using operating system methods. If the database is open and the datafile is online, first issue ALTER TABLESPACE ... BEGIN BACKUP. The resulting image copy can be cataloged:

catalog datafilecopy '?/dbs/tbs_33.f';

Maintaining Backups and Copies

How long you must keep backups and copies depends on factors such as:

How frequently you take backups.
How far in the past point-in-time recovery is needed.

For example, if you back up all datafiles daily, do not require point-in-time recovery, and need only one backup per datafile, then you can delete previous backups as soon as the new one completes.

# delete a specific datafile copy 
change datafilecopy '?/dbs/tbs_35.f' delete; 

# delete archived redo logs older than 31 days 
change archivelog until time 'SYSDATE-31' delete';

You must allocate a channel before deleting a backup piece. The specified backup piece must have been created on the same type of device. Note that the allocate channel for maintenance command is not issued inside of a run command.

# delete a backup piece
allocate channel for maintenance type 'sbt_tape';
change backuppiece 'testdb_87fa39e0' delete;

release channel;

Handling Errors During Backups and Copies

By default a checksum is calculated for every block read from a datafile and stored in the backup or image copy. If you use the nochecksum option, then checksums are not calculated. If the block already contains a checksum, however, then the checksum is validated and stored in the backup. If the validation fails, the block is marked corrupt in the backup.

The set maxcorrupt for datafile command determines how many corrupt blocks in a datafile that backup or copy will tolerate. If any datafile has more corrupt blocks than specified by the maxcorrupt parameter, the command aborts. Note that if you specify the check logical option, RMAN checks for logical and physical corruption.

By default, the backup command terminates when it cannot access a datafile. You can specify various parameters to prevent termination:

If you specify... Then RMAN skips...

The skip inaccessible option

Inaccessible datafiles. Note that a datafile is only considered inaccessible if it cannot be read. Some offline datafiles can still be read because they still exist on disk. Others have been deleted or moved and so cannot be read, making them inaccessible.

The skip offline option

Offline datafiles.

The skip readonly option

Datafiles with read-only status.

If you specify...	Then RMAN skips...
The skip inaccessible option	Inaccessible datafiles. Note that a datafile is only considered inaccessible if it cannot be read. Some offline datafiles can still be read because they still exist on disk. Others have been deleted or moved and so cannot be read, making them inaccessible.
The skip offline option	Offline datafiles.
The skip readonly option	Datafiles with read-only status.

run {
     allocate channel dev1 type 'sbt_tape';
     set maxcorrupt for datafile 1,2,3 to 5;
     backup database
       skip inaccessible
       skip readonly
       skip offline; 
}

5 Making Backups and Copies with Recovery Manager

Making Backups

Making Consistent and Inconsistent Backups

Making Whole Database Backups

To make a whole database backup:

Backing Up Tablespaces and Datafiles

To back up a tablespace:

To back up a datafile:

To back up a datafile copy:

Backing Up Control Files

To back up the current control file:

To back up a control file copy:

To include the current control file in another backup:

Backing Up Archived Redo Logs

To back up archived redo logs:

Backing Up in an OPS Environment

To back up archived redo logs in an OPS environment:

Making Incremental Backups

To make a consistent, incremental backup:

Making Split Mirror Backups

To make a split mirror backup of a tablespace:

Making Image Copies

To make consistent copies of all database files:

To copy datafiles, archived redo logs, and control files:

Backup and Copy Scenarios

Reporting Datafiles Needing Backups

Skipping Files when Backing Up a Database

Spreading a Backup Across Multiple Disk Drives

Backing Up a Large Database to Multiple Filesystems

Specifying the Size of Backup Sets

Using filesperset

Using setsize

Specifying the Size of Backup Pieces

Multiplexing Datafiles in a Backup

Backing Up Archived Redo Logs

Backing Up and Deleting Multiple Copies of an Archived Redo Log

Performing Differential Incremental Backups

Performing Cumulative Incremental Backups

Duplexing Backup Sets

Determining How Channels Distribute a Backup Workload

Backing Up in NOARCHIVELOG Mode

Backing Up in a Parallel Server Environment

Cataloging Operating System Copies

Maintaining Backups and Copies

Handling Errors During Backups and Copies

5
Making Backups and Copies with Recovery Manager