If you specify only the minimum required options for an RMAN command such as
DATABASE, RMAN determines the destination device, locations for backup output, and tag for the backup automatically based on your configured environment and built-in RMAN defaults. However, you can provide arguments to
BACKUP to override these defaults and configured settings. The most common are described in the following sections:
BACKUP command takes a
DEVICE TYPE clause that specifies whether to back up to disk or to an SBT device, as shown in this example:
BACKUP DATABASE DEVICE TYPE DISK;
BACKUP is used without a
DEVICE TYPE clause, the backup is stored on the configured default device (DISK or sbt) as set using
TYPE as described in "Configuring the Default Device Type for Backups".
As noted, RMAN can create backups on disk as image copies or as backup sets. Setting the default output type is described in "Configuring the Default Backup Type for Disk Backups". You can override this default with the
BACKUPSET clauses to the
BACKUP command. To back up your data to disk as image copies, use
BACKUP AS COPY DEVICE TYPE DISK DATABASE;
To back up your data into backup sets, use the
BACKUP AS BACKUPSETclause. You can let backup sets be created on the configured default device, or direct them specifically to disk or tape, as shown here:
BACKUP AS BACKUPSET DATABASE; BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE; BACKUP AS BACKUPSET DEVICE TYPE SBT DATABASE;
RMAN generates unique filenames for the output from the backup based on the following set of rules, listed in order of priority:
You can specify a
FORMAT clause with the individual
BACKUP command to direct the output to a specific location, as shown here:
BACKUP DATABASE FORMAT="/tmp/backup_%U";
Backups in this case are stored with generated unique filenames in the location
/tmp/backups/. Note that the
%U, used to generate a unique string at that point in the filename, is required.
You can also use the
FORMAT clause to name an ASM disk group as backup destination, as shown in this example:
RMAN> BACKUP DATABASE FORMAT '+dgroup1'; # sets an ASM disk group
%U is required in this instance, because ASM generates unique file names as needed.
FORMAT setting is configured for the specific channel used for the backup, then this setting controls the generated filename.
FORMAT setting is configured for the device type used for the backup, then this setting controls the generated filename.
If the backup is a disk backup and a flash recovery area is configured, then the backup is stored under an automatically generated name in the flash recovery area.
If none of the other conditions in this list apply, then the default location and filename format are platform-specific.
RMAN attaches an identifier called a tag to every backup it creates, as a way of identifying that backup that can be used with later RMAN commands.
When you use the
BACKUP command, you can specify the to be assigned to the backups taken with a particular command. You could use this tag to identify backups taken at a given time, such as
2003_year_end. You can also use a tag repeatedly for a series of backups created over time. For example, you might label a series of weekly incremental backups with a tag such as
In practice, tags are often used to distinguish a series of backups created as part of a single strategy, such as an incremental backup strategy. Many forms of the
BACKUP command let you associate a tag with a backup, and many
RECOVER commands let you specify a tag to restrict which backups to use in the
If you do not specify a tag with a BACKUP command, then RMAN generates a unique tag and assigns it to the backups created by the command.
To specify a tag to identify a group of backups, use the
TAG clause of the
BACKUP command. For example, enter:
RMAN> BACKUP DATABASE TAG = 'weekly_backup'; # gives the backup a tag identifier
If a backup is not assigned a tag using the
TAG clause to the
BACKUP command, then RMAN generates a tag automatically and assigns it to the backup.
Note:The characters used in a tag must be limited to the characters that are legal in filenames on the target file system. For example, ASM does not support the use of the
-character in the filenames it uses interally, so a tag including a
weekly-incremental) is not a legal tag name if you are storing backups in ASM disk groups.
See Also:Oracle Database Backup and Recovery Reference for the default format description in
For any use of the
BACKUP command that creates backupsets, you can take advantage of RMAN's support for binary compression of backupsets, by using the
AS COMPRESSED BACKUPSET option to the
BACKUP command. The resulting backupsets are compressed using an algorithm optimized for efficient compression of Oracle database files. No extra uncompression steps are required during recovery if you use RMAN's integrated compression.
The primary disadvantage of using RMAN binary compression is performance overhead during backups and restores.Backup performance while creating compressed backupsets is CPU bound. If you have more than one CPU, you can use increased parallelism to run jobs on multiple CPUs and thus improve performance.
Note:If you are backing up to tape and your tape device performs its own compression, you should not use both RMAN backupset compression and the media manager vendor's compression. In most instances you will get better results using the media manager's compression. See the discussion of tuning RMAN's tape backup performance in Oracle Database Backup and Recovery Advanced User's Guide for details.
This example backs up the entire database and archived logs to the configured default backup destination (disk or tape), producing compressed backupsets:
BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;
This example backups up several datafiles to the default device, using binary compression:
BACKUP AS COMPRESSED BACKUPSET DATAFILE 1,2,4;
Predictably, creating compressed backupsets imposes significant extra CPU overhead during backup and restore, which can slow the backup process. The performance penalty may be worth paying, however, in some circumstances:
If you are using disk-based backups and disk space in your flash recovery area or other disk-based backup destination is limited
If you are performing your backups to some device over a network and reduced network bandwidth is more important than CPU usage
If you are using some archival backup media such as CD or DVD, where reducing backup sizes saves on media costs and archival storage
For more information on performance considerations when using binary compression of backup sets, see the description of the
AS COMPRESSED BACKUPSET option of the
BACKUP command, in Oracle Database Backup and Recovery Reference.