Introduction to Recovery Manager

1.

Recovery Manager (RMAN) is an Oracleutility that can back up, restore, and
recover database files. The product is a feature of theOracle database server and does not
require separate installation. Recovery Manager is a client/server application that uses
database server sessions to perform backup and recovery.

About Recovery Manager (RMAN)

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.

Recovery Manager is a client/server application that 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.
You can invoke RMAN as a command-line executable from the operating system prompt
or use some RMAN features through the Enterprise Manager GUI.
Why Use RMAN?
Most production database systems impose stringent requirements on backup and recovery.
As a DBA in charge of backup and recovery, you must:

Manage the complexity of backup and recovery operations

Minimize the possibility of human error
Make backups scalable and reliable
Utilize all available media hardware
Make backups proportional to the size of transactional changes,
not to the size of database

 Make recovery time proportional to the amount of data recovered

You have two basic methods for performing these backup and recovery tasks on an Oracle
release 8.0 or higher database:
Using operating system commands to perform backup and restore
operations, and SQL or SQL*Plus statements to perform recovery
Using Recovery Manager for backup, restore, and recovery

Note :-

RMAN was introduced in Oracle release 8.0 and is not compatible with
Oracle databases prior to release 8.0.

Why use one method rather than the other? As illustrated in Figure 1-1, RMAN uses
server sessions to perform backup and recovery operations and stores metadata in a
repository. RMAN automates backup and recovery, whereas the user-managed method
requires you to keep track of all database files and backups. For example, instead of
requiring you to locate backups for each datafile, copy them to the correct place using
operating system commands, and choose which logs to apply, RMAN manages these tasks
automatically.
The advantage of using RMAN is especially true if you use Oracle Managed Files. When
you let Oracle name and manage your datafiles, control files, and online redo logs, the
system becomes easier to use. On the other hand, it may be harder for you to keep track of
the filenames of the various database files because you have not named them yourself.
RMAN users do not suffer from this problem because RMAN handles all record keeping.
Figure 1-1 Comparison of RMAN Automated and User-Managed Procedures

Overview of the RMAN Environment

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

RMAN executable
Target database
Recovery catalog database
Media management software
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 database is optional. Nevertheless, maintaining a recovery catalog is strongly
encouraged. If you create a catalog on a separate machine, and if the production machine
fails completely, then you have all the restore and recovery information you need in the
catalog.

About the RMAN Executable

The RMAN executable is automatically included with the Oracle software installation. Its
location is platform-specific and is typically located in the same place as the other Oracle
executables. On Unix systems, for example, the RMAN executable is located
in $ORACLE_HOME/bin.

To start the executable, simply enter the filename on the command line. For example, on a
UNIX system, enter:
% rman

About the Target Database

The target database is the database that RMAN is backing up, restoring, or recovering.
You can use a single recovery catalog in conjunction with multiple target databases. For
example, assume that your data center contains 10 databases of varying sizes. You can use
a single recovery catalog located in a different data center to manage the metadata from all
of these databases.
About the RMAN Repository

The RMAN repository is a set of metadata that RMAN uses to store information about the
target database and its backup and recovery operations. Among other things, RMAN
stores information about:
Backup sets and pieces
Image copies (including archived redo logs)
Proxy copies
The target database schema
Persistent configuration settings
You can access this metadata by issuing LIST, REPORT, and SHOW commands in the RMAN
interface, or by using SELECT statements on the catalog views (only if you use a recovery
catalog). Figure 1-2illustrates how RMAN issues lists and reports.

Figure 1-2 RMAN Lists and Reports

You can either create a recovery catalog in which to store the repository, or let RMAN
store the repository exclusively in the target database control file. Figure 1-3 depicts
RMAN using a recovery catalog.
Figure 1-3 RMAN with Optional Recovery Catalog

Comparison Between RMAN and User-Managed Methods :-

Recovery Manager

User-Managed Method

Uses a media management API so that RMAN

works seamlessly with third-party media
management software. More than 20 vendors
support the API.

Does not have support of a published API.

When backing up online files, RMAN rereads

fractured data blocks to get a consistent read. You
do not need to place online tablespaces in backup
mode when performing backups.

Requires placing online tablespaces in backup

mode before backing them up, and then taking
the tablespaces out of this mode after the backup
is complete. Serious database performance and
manageability problems can occur if you neglect
to take tablespaces out of backup mode after an
online backup is complete.

Performs incremental backups, which back up

Backs up all blocks, not just the changed blocks.
only those data blocks that changed after a
Does not allow you to recover
previous backup. You can recover the database
a NOARCHIVELOGdatabase.
using incremental backups, which means that you
can recover aNOARCHIVELOG database. However,
you can only take incremental backups of
a NOARCHIVELOG database after a consistent
shutdown.

Computes checksums for each block during a

backup, and checks for corrupt blocks when
backing up or restoring. Many of the integrity
checks that are normally performed when
executing SQL are also performed when backing
up or restoring.

Does not provide error checking.

Recovery Manager

User-Managed Method

Omits never-used blocks from datafile backups so Includes all data blocks, regardless of whether
that only data blocks that have been written to are they contain data.
included in a backup.

Uses the repository to report on crucial

information, including:

Database schema at a specified time

Which files need a backup

Which files have not had a backup in a

specified number of days

Which backups can be deleted because

they are redundant or cannot be used for
recovery

Current RMAN persistent settings

Stores RMAN scripts in the recovery catalog.

Does not include any reporting functionality.

Requires storage and maintenance of operating

system-based scripts.

Allows you to easily create a duplicate of the

Requires you to follow a complicated procedure
production database for testing purposes, or easily when creating a test or standby database.
create or back up a standby database.

Performs checks to determine whether backups

on disk or in the media catalog are still available.

Requires you to locate and test backups

manually.

Performs automatic parallelization of backup and Requires you to parallelize manually by

restore operations.
determining which files you need to back up and

Recovery Manager

User-Managed Method
then issuing operating system commands in
parallel.

Tests whether files can be backed up or restored Requires you to actually restore backup files
without actually performing the backup or restore. before you can perform a trial recovery of the
backups.

Performs archived log failover automatically. If

Cannot failover to an alternative archived log if
RMAN discovers a corrupt or missing log during the backup encounters a problem.
a backup, then it considers all logs and log copies
listed in the repository as alternative candidates
for the backup.

RMAN Script Overview

RMAN (Oracle9i and higher) now allows the DBA to perform automated database backup
and recovery. This feature is supported by RMAN with its ability to define default values
for a number of settings, (i.e. channel configuration). Setting RMAN settings is performed
with the configure command.
This article presents an overview of all Oracle9i RMAN configuration parameters and
examples of how they can be set.

Viewing Values

Before getting into the configure command, lets first take a look at our default settings by
using the show command:
RMAN> SHOW ALL;

RMAN configuration parameters are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/u01/app/oracle/product/10.2.0/dbs/snapcf_TARGDB.f'; # default

From the above listing, you can see that the RMAN allows you to set default values for
some of the following:
The default retention policy. This determines which backups and copies are
eligible for deletion because they are no longer needed.
Turning ON and OFF backup optimization. Backup optimization eliminates
duplicate backups of identical datafiles (like those associated with a readonly tablespace) and archived redo logs.
A default device type for RMAN jobs, (disk or tape [sbt])
The default for automated backups of the control file to ON or OFF. You can
also control the default format of the control file backup output files and the
default device on which to create these backups.
The number of channels (for parallelization) that are automatically allocated
when performing automated backup and recovery/restore jobs.
A tablespace exclusion policy to configure specific tablespaces to be
excluded during full database backup operations. If there are no tablespace
exclusion policies defined, nothing will be displayed by the show
all command.
The maximum size for any given backup piece and the size of any backup set
when performing automated backups.

 The default filename for the snapshot controlfile.

This article will provide detailed information on all of these RMAN configuration
parameters and how they can be defined.

Using Substitution Variables

RMAN can make use of substitution variables in creating format strings to generate
filenames. Without due care, non-unique filenames can be generated and, under certain
circumstances, this can cause backup data to be overwritten and therefore lost. So be
careful; this is not a bug with Oracle, but rather a usage error.
Format Description
%p

specifies the backup piece number within the backup set. This value starts at 1 for each
backup set and is incremented by 1 as each backup piece is created.

%s

specifies the backup set number. This number is a counter in the control file that is
incremented for each backup set. The counter value starts at 1 and is unique for the lifetime
of the control file. If you restore a backup control file, then duplicate values can result. Also,
CREATE CONTROLFILE initializes the counter back to 1.

%d

specifies the database name.

%n

specifies the database name, padded on the right with 'x' characters to a total length of 8
characters. For example, if PROD1 is the database name, then PROD1xxx is the padded
database name.

%t

specifies the backup set timestamp, which is a 4-byte value derived as the number of
seconds elapsed since a fixed reference time. The combination of %s and %t can be used to
form a unique name for the backup set.

%u

specifies an 8-character name constituted by compressed representations of the backup set

number and the time the backup set was created.

%c

(Oracle8i or higher) - specifies the copy number of the backup piece within a set of
duplexed backup pieces. If you did not issue the set duplex command, then this variable will
be 1 for regular backup sets and 0 for proxy copies. If you issued set duplex, the variable
identifies the copy number: 1, 2, 3, or 4.

%U

(Oracle8i or higher) - specifies a convenient shorthand for %u_%p_%c that guarantees

uniqueness in generated backup filenames. If you do not specify a format, RMAN uses %U
by default. %U is the default in Oracle8i.

Using the configure Command to Clear Values

Before discussing each of the RMAN configuration parameters in detail, let's first take a
look at how to clear values. (Setting these configuration parameters to their default values)
Like setting an RMAN configuration parameter, you use the configure command, but will
use the clear option.
To set the MAXSETSIZE parameter back to its default value of UNLIMITED:
RMAN> configure maxsetsize clear;

Here is a list of commands that clear several RMAN settings back to their default values:
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>
RMAN>

CONFIGURE RETENTION POLICY CLEAR;

CONFIGURE BACKUP OPTIMIZATION CLEAR;
CONFIGURE DEFAULT DEVICE TYPE CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT CLEAR;
CONFIGURE DEVICE TYPE DISK CLEAR;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK CLEAR;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT CLEAR;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK CLEAR;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT CLEAR;
CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR;
CONFIGURE CHANNEL DEVICE TYPE SBT CLEAR;
CONFIGURE MAXSETSIZE CLEAR;
CONFIGURE SNAPSHOT CONTROLFILE NAME CLEAR;
# CONFIGURE EXCLUDE FOR TABLESPACE USERS_READ_TBS;

RETENTION POLICY
Used to control how long RMAN will keep backups. This can be configured by the
"number" of backups taken, or by the numbers of "days" to keep. Here is an example of
both:
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

Note that when configuring a retention policy, RMAN will not cause backups to be
automatically deleted. The retention policy will, however, mark backups as OBSOLETE
that have fallen outside the retention period. RMAN commands like " REPORT OBSOLETE"
and "DELETE OBSOLETE" will work with these obsolete backups.
If back up your database infrequently, you probably will prefer a redundancy policy that is
stated in terms of number of backups rather than backups later than n days old. In this
case, you would use the redundancy parameter as follows:
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 3;

Finally, if you do not want to use a retention policy, simply use:

RMAN> CONFIGURE RETENTION POLICY TO NONE;

BACKUP OPTIMIZATION
Used to enable or disable backup optimization. Backup file optimization can assist in
reducing the space used to backup the database. When performing an RMAN backup, a
check is done on the file before backup to see if the file already exists in a backupset with
the same information: (dbid, checkpoint, and resetlogs data).
For archive logs, the same file means the same dbid, thread, sequence, and resetlogs data.
If the DELETE INPUT option is used, RMAN deletes all the files that would have been
backed up, even when the file is not included due to file optimization.
The two possible values for backup optimization is ON and OFF as shown in the
following example syntax:
CONFIGURE BACKUP OPTIMIZATION OFF;
CONFIGURE BACKUP OPTIMIZATION ON;

Use caution when enabling backup optimization if you use a media manager that has an
expiration policy. The media manager can expire tapes containing backups (using its
media control software), and RMAN will not make new backups because of optimization.
One way to protect from this is to run CROSSCHECK periodically to synchronize the
repository with the media manager.
Also note that you should consider how backup optimization works with regards to the
RETENTION POLICY. RMAN will only work with files within the retention period. For

example, consider performing a backup with optimization enabled and a retention period
of 3 days. RMAN will only compare the datafile with backup sets within the 3 day period
- even if the datafile it is about to backup hasn't changed within that 3 days.

DEFAULT DEVICE TYPE

Configures the default backup / restore device type for automatic channels. The two
values for now are TAPE (SBT) and DISK (DISK) - the default being DISK. By default,
the BACKUP and COPY commands only allocate channels of the default device type. For
example, if you configure automatic channels for DISK and sbt and set the default device
type to DISK, then RMAN only allocates disk channels when you run the BACKUP
DATABASE command. You can override this behavior either by manually allocating
channels in a RUN command, or by specifying DEVICE TYPE on the BACKUP
command itself. The RESTORE command allocates automatic channels of all configured
device types, regardless of the default device type. The RESTORE command obeys the
PARALLELISM setting for each configured device type.
The following two examples show the syntax for configuring the default device type to
TAPE (SBT) - then another command to re-configure the default device type to DISK:
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE DEFAULT DEVICE TYPE TO SBT;

CONTROLFILE AUTOBACKUP
Starting with Oracle9i, RMAN offers the ability to backup the control file and the
database parameter file (SPFILE only) and have this take place automatically by default
after EACH backup. By default, this feature is not enabled. This feature can be enabled or
disabled using the example syntax below:
CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE CONTROLFILE AUTOBACKUP OFF;

When the CONTROLFILE AUTOBACKUP feature is enabled, then RMAN performs a

control file autobackup in the following circumstances:
After every BACKUP or COPY command issued at the RMAN prompt.
Whenever a BACKUP or COPY command within a RUN block is followed by a
command that is neither BACKUP nor COPY.
At the end of every RUN block if the last command in the block was
either BACKUP or COPY.
After database structural changes such as adding a new tablespace, altering
the state of a tablespace or datafile (for example, bringing it online), adding a
new online redo log, renaming a file, adding a new redo thread, and so forth.
This type of autobackup, unlike autobackups that occur in the preceding
circumstances, goes only to disk. You can run: CONFIGURE CONTROLFILE
AUTOBACKUP FOR DEVICE TYPE DISK to set a nondefault disk location.
The "first channel" allocated during the BACKUP or COPY job creates the autobackup and
places it "into its own backup set"; for post-structural autobackups, the "default disk
channel" makes the backup.
RMAN writes both the CONTROLFILE and the SPFILE (if the database was started with
an SPFILE) to the same backup piece. After the CONTROLFILE AUTOBACKUP
completes, Oracle writes a message containing the complete path of the backup piece and
the device type to the alert log.
RMAN automatically backs up the current control file using the default format of %F (see
entry for CONFIGURE CONTROLFILE AUTOBACKUP FORMAT for an explanation
of this substitution variable). You can change this format using the CONFIGURE
CONTROLFILE AUTOBACKUP FORMAT and SET CONTROLFILE AUTOBACKUP
FORMAT commands.
When this feature is disabled, any BACKUP command that includes datafile 1 (including
BACKUP DATABASE) automatically includes the current control file and server
parameter file in the backup set. Otherwise, RMAN does not include these files.
NOTE: You may see occasions where RMAN will sometimes automatically include the
CONTROLFILE and SPFILE in the backupsets during a backup. This is normal and is

documented (above). When CONTROLFILE AUTOBACKUP is not enabled, the

CONTROLFILE and SPFILE, (if the database was started with an spfile), are included
automatically when datafile 1 is backed up. Consider the following backup:
RMAN> backup datafile 1;

It will include the CONTROLFILE and the SPFILE (when the database is started with a
spfile).

CONTROLFILE AUTOBACKUP FORMAT

Configures the default filename format for the control file autobackup on the specified
device type. By default, the initial format is %F for all devices. Any default format string
specified withCONFIGURE must include the %F substitution variable (see BACKUP). This
variable translates into c-IIIIIIIIII-YYYYMMDD-QQ, where:

IIIIIIIIII

YYYYMMDD

QQ

- stands for the DBID. (The DBID is printed in decimal so that it

can be easily associated with the target database.
- is a time stamp in the Gregorian calendar of the day the backup is
generated.
- is the sequence in hexadecimal number that starts with 00 and has a
maximum of 'FF' (256).

Specify CLEAR to return the format to the default %F.

NOTE: The %F tag is essential for RMAN to be able to restore the file without a recovery
catalog.

Here is an example of how to set the format of the autobackup controlfile:

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO
'/orabackup/rman/ORA920/%F';

PARALLELISM

Configure RMAN to use [n] number of disk channels for backup, restore, recovery, and
maintenance operations. Device types that are eligible for use in jobs that use automatic
channels can sets the degree of channel parallelism. (The DISK device type is the default)
The PARALLELISM parameter specifies the number of automatic channels of the specified
device type allocated for RMAN jobs. RMAN always allocates the number of channels
specified byPARALLELISM, although it may actually use only a subset of these channels. By
default, PARALLELISM = 1.
Take the following example; you can set PARALLELISM for DISK backups to 3. If you
configure automatic channels of type disk and tape, and set the default device type as disk,
then RMAN allocates three disk channels when you run BACKUP DATABASE at the RMAN
prompt.
To change the parallelism for a device type to [n], run:
CONFIGURE DEVICE TYPE [DISK | SBT] PARALLELISM [n];

Here are several examples of how to configure PARALLELISM to 3 for sbt and then
change it to 2:
CONFIGURE DEVICE TYPE sbt PARALLELISM 3;
CONFIGURE DEVICE TYPE sbt PARALLELISM 2;

Another example that configures parallelism to 2 for automatic disk channel.

CONFIGURE DEVICE TYPE DISK PARALLELISM 2;

NOTE: If you configure [n] manually numbered channels, the PARALLELISM setting can
be greater than or less than [n]. For example, you can manually number 10 automatic
channels and configure PARALLELISM to 2 or even 12.

DATABASE (and ARCHIVELOG) BACKUP COPIES

Specifies the number of copies of each backup set for DATAFILE (both datafiles and
control files) or ARCHIVELOG files on the specified device type, from 1 (default) to 4. If
duplexing is specified in the BACKUP command or in a SET BACKUP COPIES command, then
the CONFIGURE setting is overridden.

Here is the general syntax:

{ARCHIVELOG| DATAFILE}
BACKUP COPIES FOR DEVICE
TYPE deviceSpecifier
TO integer;

NOTE: Control file autobackups on disk are a special case and are never duplexed. RMAN
always writes one and only copy.

Here are several examples of how to set this parameter:

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 2;

To clear this parameter, use the following:

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK CLEAR;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK CLEAR;

CHANNEL CONFIGURATION
Specifies the standard or AUXILIARY channel that you are configuring or clearing, as
well as the device type (DISK or sbt) of the channel. You can either configure a "generic
channel" or specify a channel by number, where "integer" is less than 255.
Next let's look at setting defaults for channels. You can either set default settings
for all channels with the configure channel device type command or you can set defaults
for a specificchannel using the configure channel n device type, where n is the channel
you want to set for.
Now, let's take a look at the general syntax:
CHANNEL integer DEVICE TYPE deviceSpecifier allocOperandList;
integer
deviceSpecifier

You can specify a channel by number. You may

also exclude an integer, in which case you
are specifying a general channel.
{DISK | SBT}

allocOperandList

/* Specifies control options for the

/* allocated channel
[PARMS
= 'channel_parms']
[CONNECT
= (quoted string)]
[FORMAT
= 'format_sring']
[MAXPIECESIZE = integer [K|M|G]]
[RATE
= integer [K|M|G]]
[MAXOPENFILES = integer]
[SEND
= 'command']

*/
*/

I generally use this parameter to configure the location (directory) and file format where
RMAN will write disk backups to. Here are some of the substitution variables that can be
used in the backup set file name: |
%d
%s
%p
%t

Database name
Backup set number
Backup piece number
4-byte timestamp

When automated channels are allocated, Oracle assigns default names to these channels.
These default names depend on the type of default device used. The following table
provides the default name format that will be used for each device:
Default Device Type

Default Name Format

Example

Disk

ORA_DISK_n

ORA_DISK_1, ORA_DISK_2

Tape

ORA_SBT_TAPE_n

ORA_SBT_TAPE_1, ORA_SBT_TAPE_1

Now let's look at setting the number of channels to be allocated during an automated
backup or recovery operation. This example will set the default level of parallelism for
disk operations to two. Now, if an automated backup is started, two channels will be
allocated to perform the backup in parallel:
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT
'/orabackup1/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t';
RMAN> CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT
'/orabackup2/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t';

NOTE: When setting the default level of parallelism, you should set it to the number of
disks or tape drives attached to which you will be backing up.

You can also control the size of a backup set piece or the entire backup itself. In the
following example, I will limit channel 1 to create each individual backup piece at a
maximum size of 1024MB. Take note that this command does not limit the overall size of
the backup:

RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT

'/orabackup1/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t' MAXPIECESIZE 1024m;

You can also set to limit all channels to have a limit of 1024MB by using:
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
'/orabackup/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t' MAXPIECESIZE 1024m;

You can also limit the speed or rate of the backup channel:
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT
'/orabackup/rman/ORA920/backup_db_%d_S_%s_P_%p_T_%t' MAXPIECESIZE 1024m RATE 5m;

NOTE: If you configure a generic channel (that is, if you do not specify a channel
number), then RMAN uses the generic settings for every parallelized channel except any
channel number that you have explicitly configured. In other words, a generic channel
setting specifies options for all channels not configured explicitly.
NOTE: The RATE parameter is intended to slow down a backup so that you can run it in the
background with as little effect as possible on OLTP operations. The RATE parameter
specifies units of bytes/second. Test to find a value that improves performance of your
queries while still letting RMAN complete the backup in a reasonable amount of time. Note
that RATE is not designed to increase backup throughput, but to decrease backup throughput
so that more disk bandwidth is available for other database operations.
NOTE: The CONNECT parameter specifies a connect string to the database instance
where RMAN should conduct the backup or restore operations. Use this parameter to
spread the work of backup or restore operations across different instances in an Oracle Real
Application Clusters configuration. If you do not specify this parameter, and if you did not
specify the AUXILIARY option, then RMAN conducts all operations on the target database
instance specified by the command-line parameter or the instance connected to when you
issued the CONNECT command. Typically, you should not use the CONNECT parameter
in conjunction with the AUXILIARY option.
NOTE: We can also assign specify an assigned name to channels that you allocate when
using the allocate channel command. For example the following command will create a
channel named c1:
RMAN> run {...
allocate channel c1 device type disk;
...}

NOTE: If AUXILIARY is specified, then this configuration is used only for channels
allocated at the auxiliary instance. If no auxiliary device configuration is specified, and if
RMAN needs to automatically allocate auxiliary channels, then RMAN uses the target

database device configuration. It is not necessary to specify configuration information for

auxiliary channels unless they require different parameters from the target channels.
NOTE: For generic channels of a specified device type, a new command erases previous
settings for this device type. Assume that you run these commands:
CONFIGURE CHANNEL DEVICE TYPE sbt MAXPIECESIZE 1G;
CONFIGURE CHANNEL DEVICE TYPE sbt RATE 1700K;

The second command erases the MAXPIECESIZE setting of the first command.
NOTE: It is useful to understand how the CLEAR command works for this parameter.
CLEAR Clears the specified channel. For example, CONFIGURE CHANNEL 1 DEVICE TYPE
DISK CLEAR returns only channel 1 to its default, whereas CONFIGURE CHANNEL DEVICE
TYPE DISK CLEAR returns the generic disk channel to its default. Note that you cannot
specify any other channel options (for example, PARMS) when you specify CLEAR.

MAXSETSIZE
Specifies the maximum size of each backup set created on a channel. By default
MAXSETSIZE is set to UNLIMITED, meaning that it is disabled.
Here is the general syntax:
CONFIGURE MAXSETSIZE TO { integer [K|M|G] | UNLIMITED | CLEAR };
TO integer

TO UNLIMITED
CLEAR

Specifies the maximum set size in bytes, kilobytes (K),

megabytes (M), or gigabtyes (G). The default setting is
in bytes and is rounded down to kilobtyes. For example,
if you set MAXSETSIZE to 5000, RMAN sets the maximum set
size at 4 kilobytes (that is, 4096 bytes), which is the
lower kilobyte boundary of 5000. The minimum value must
be greater than or equal to the database block size.
Specifies that there is no size limit for backup sets.
Resets the maximum set size to its default value.

The following command will set the maximum size of a backup set to 1.5GB:
RMAN> CONFIGURE MAXSETSIZE TO 1500m;

NOTE: Take careful note when setting this parameter. While the size of your database may
be small enough for MAXSETSIZE, your database may grow beyond beyond
MAXSETSIZE which will cause your database backups to fail.
For some time, there have been some question as to what this parameter limits. While the

documentation states that it limits the size of a backup set, it seems to place limits on the
datafile sizes - even though I am using backup sets and not image copies. For example, I
have set MAXSETSIZE to 500m and attempted to backup a database, only to get the error:
RMAN-06183: datafile or datafilecopy larger than SETSIZE: file# 1
/u10/app/oradata/TARGDB/users01.dbf

The file (users01.dbf) is larger than 500MB but the backupset is considerably smaller than
that (there is very little data in there at present). The Oracle documentation states that
MAXSETSIZE limits the size of the backupsets, NOT the size of the datafiles which can be
backed-up. All I can say, is that Oracle states that this is expected behavior, and I think it is
a bug in the documentation.

If you want to set the value backup to its default, use:

RMAN> CONFIGURE MAXSETSIZE CLEAR;

SNAPSHOT CONTROLFILE
A snapshot control file is created by RMAN during the backup process that serves as a
point-in-time copy of the database control file. This will ensure that that backups being
taken is consistent to a given point in time. For example, if you add a datafile or
tablespace to a database after the backup has started, (assuming an online backup and
before the backup has ended), that datafile and/or tablespace will not be included in the
backup. It is sometimes required that the location and name of the snapshot control file be
changed from its default.
To set the snapshot control file to a different location (and name) use the following:
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/orabackup/rman/ORA920/scontrolfile.ctl';

NOTE: The default value for the snapshot control file name is platform-specific and
dependent on the Oracle home. For example, the default on some UNIX system
is?/dbs/snapcf_@.f. If you clear the control file name, and you change the Oracle home,
then the default location of the snapshot control file changes as well.

EXCLUDE TABLESPACE
Excludes the specified tablespace from BACKUP DATABASE commands. Note that you cannot
exclude the SYSTEM tablespace. By default, each tablespace is not excluded, that is, the
exclude functionality is disabled.
The exclusion is stored as an attribute of the tablespace, not the individual datafiles, so the
exclusion applies to any files that are added to this tablespace in the future.
If you run CONFIGURE ... CLEAR on a tablespace after excluding it, then it returns to the
default configuration of "not excluded."
You can still back up the configured tablespace by explicitly specifying it in
a BACKUP command or by specifying the NOEXCLUDE option on a BACKUP DATABASE command.
The general syntax is:
EXCLUDE FOR TABLESPACE tablespace_name;

In this example, I want to exclude the tablespace named 'READ_ONLY_TBS' from the
backup:
RMAN> CONFIGURE EXCLUDE FOR TABLESPACE READ_ONLY_TBS;