4.3 Backing Up Database Files and Archived Logs with RMAN

This section contains these topics:

Making Consistent and Inconsistent Backups with RMAN
Specifying Options Affecting Output of the RMAN BACKUP Command
Making Whole Database Backups with RMAN
Backing Up Individual Tablespaces with RMAN
Backing Up Individual Datafiles and Datafile Copies with RMAN
Backing Up Control Files with RMAN
Backing Up Server Parameter Files with RMAN
Backing Up Archived Redo Logs with RMAN

4.3.1 Making Consistent and Inconsistent Backups with RMAN

A consistent backup of the database is one taken when the database is in a consistent state, that is, one taken after the database has been shut down normally (using SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE or SHUTDOWN TRANSACTIONAL). At this point, all changes in the redo log have been applied to the datafiles. If you mount the database and take a backup at this point, then you can restore the database from this backup at a later date and open it without performing media recovery.

Any backup taken when the database has not been shut down normally is an inconsistent backup. When a database is restored from an inconsistent backup, Oracle must perform media recovery before the database can be opened, applying any pending changes from the redo logs.

As long as your database is running in ARCHIVELOG mode, and you back up your archived redo log files as well as your datafiles, inconsistent backups can be the foundation for a sound backup and recovery strategy. Inconsistent backups are an important part of the backup strategy for most databases, because they offer superior availability. For example, backups taken while the database is still open are inconsistent backups.

Note:

When performing user-managed backups, taking online backups required that you place your datafiles into backup mode using the ALTER DATABASE/TABLESPACE BEGIN BACKUP statement. RMAN does not require the use of backup mode for the creation of online backups. Do not use ALTER DATABASE/TABLESPACE BEGIN BACKUP before an RMAN backup.

4.3.2 Making Whole Database Backups with RMAN

You can perform whole database backups with the database mounted or open. To perform a whole database backup, from the RMAN prompt, use the BACKUP DATABASE command. The simplest form of the command requires no parameters, as shown in this example:

RMAN> BACKUP DATABASE;

This example shows the procedure for taking a whole database backup to the default destination:

RMAN> BACKUP DATABASE;  # uses automatic channels to make backup
RMAN> SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; # switches logs and archives all logs

By archiving the logs immediately after the backup, you ensure that you have a full set of archived logs through the time of the backup. This guarantees that you can perform media recovery after restoring this backup.

4.3.3 Backing Up Individual Tablespaces with RMAN

You can backup one or more individual tablespaces with the BACKUP TABLESPACE command. You can use this command when the database is mounted or open.

To back up a tablespace:

After starting RMAN, run the BACKUP TABLESPACE command at the RMAN prompt. This example backs up the users and tools tablespaces to tape, using the MAXSETSIZE parameter to specify that no backup set should be greater than 10 MB:

BACKUP DEVICE TYPE sbt MAXSETSIZE = 10M TABLESPACE users, tools;

Oracle translates the tablespace name internally into a list of datafiles.

4.3.4 Backing Up Individual Datafiles and Datafile Copies with RMAN

You can back up datafiles and datafile copies when the database is mounted or open.

4.3.4.1 Backing Up Datafiles

With RMAN connected to the target database, use the BACKUP DATAFILE command to back up individual datafiles. You can specify the datafiles by name or number.

This example uses an sbt channel to back up datafiles 1 through4 and a datafile copy stored at /tmp/system01.dbf to tape:

BACKUP DEVICE TYPE sbt 
  DATAFILE 1,2,3,4 
  DATAFILECOPY '/tmp/system01.dbf';

If CONFIGURE CONTROLFILE AUTOBACKUP is ON, then RMAN writes the current control file and SPFILE to a separate autobackup piece. Otherwise, these files are automatically included in the backup set that contains datafile 1.

4.3.4.2 Backing Up Datafile Copies

Use the BACKUP DATAFILECOPY command to back up datafile copies. Datafile copies exist on disk only.

To back up a datafile copy:

While connected to the target database, run the BACKUP DATAFILECOPY command at the RMAN prompt. This example backs up datafile /tmp/system01.dbf to tape:

BACKUP DEVICE TYPE sbt DATAFILECOPY '/tmp/system01.dbf';

4.3.5 Backing Up Control Files with RMAN

You can back up the control file when the database is mounted or open. RMAN uses a snapshot control file to ensure a read-consistent version. If CONFIGURE CONTROLFILE AUTOBACKUP is ON (by default it is OFF), then RMAN automatically backs up the control file and server parameter file after every backup and after database structural changes. The control file autobackup contains metadata about the previous backup, which is crucial for disaster recovery.

If the autobackup feature is not set, then you must manually back up the control file in one of the following ways:

Run BACKUP CURRENT CONTROLFILE
Include a backup of the control file within any backup by using the INCLUDE CURRENT CONTROLFILE option of the BACKUP command

Back up datafile 1, because RMAN automatically includes the control file and SPFILE in backups of datafile 1

Note:

If the control file block size is not the same as the block size for datafile 1, then the control file cannot be written into the same backup set as the datafile. RMAN writes the control file into a backup set by itself if the block size is different.

A manual backup of the control file is not the same as a control file autobackup. In manual backups, only RMAN repository data for backups within the current RMAN session is in the control file backup, and a manually backed-up control file cannot be automatically restored.

4.3.5.1 Including the Current Control File in a Backup of Other Files

To include the current control file in a backup, specify the INCLUDE CURRENT CONTROLFILE option after specifying the backup object. In this example, the default configured channel is to an sbt device. This command backs up tablespace users to tape and includes the current control file in the backup:

BACKUP DEVICE TYPE sbt TABLESPACE users INCLUDE CURRENT CONTROLFILE;

If the autobackup feature is enabled, then RMAN also creates an autobackup of the control file after the BACKUP TABLESPACE command completes, so that the control file autobackup contains the record of the backup that was taken.

4.3.5.2 Backing Up the Current Control File Manually

After starting RMAN, run the BACKUP CURRENT CONTROLFILE command. This example backs up the current control file to the default disk device and assigns a tag:

BACKUP CURRENT CONTROLFILE TAG = mondaypmbackup;

If the control file autobackup feature is enabled, then RMAN makes two control file backups in this example: the explicit control file backup (BACKUP CURRENT CONTROLFILE) and the autobackup of the control file and server parameter file.

4.3.5.3 Backing Up a Control File Copy

This example creates a control file backup with the BACKUP CONTROLFILECOPY command.

To back up a control file copy:

After starting RMAN, run the BACKUP CONTROLFILECOPY command at the RMAN prompt. This example creates the control file copy '/tmp/control01.ctl' on disk and then backs it up to tape:

BACKUP AS COPY CURRENT CONTROLFILE FORMAT '/tmp/control01.ctl';
BACKUP DEVICE TYPE sbt CONTROLFILECOPY '/tmp/control01.ctl';

4.3.6 Backing Up Server Parameter Files with RMAN

As explained in "Backing Up Control Files with RMAN", RMAN automatically backs up the current server parameter file in certain cases. The BACKUP SPFILE command backs up the parameter file explicitly. For example:

BACKUP DEVICE TYPE sbt SPFILE;

The SPFILE that is backed up is the one currently in use by the instance. If the instance is started with a client-side initialization parameter file, then RMAN does not back up anything when this command is used.

4.3.7 Backing Up Archived Redo Logs with RMAN

Archived redo logs are the key to successful media recovery. Back them up regularly. You can back up logs with BACKUP ARCHIVELOG, or back up logs while backing up datafiles and control files by specifying BACKUP ... PLUS ARCHIVELOG.

4.3.7.1 Backing Up Archived Redo Log Files with BACKUP ARCHIVELOG

To back up archived redo logs, use the BACKUP ARCHIVELOG command at the RMAN prompt. This example uses a configured disk or sbt channel to back up one copy of each log sequence number for all archived redo logs:

BACKUP ARCHIVELOG ALL;

Even if your redo logs are being archived to multiple destinations and you use RMAN to back up archived redo logs, RMAN selects only one copy of the archived redo log file to include in the backup set. (Since logs with the same log sequence number are identical, there is no need to include more than one copy.)

You can also specify a range of archived redo logs by time, SCN, or log sequence number, as in the following example:

BACKUP ARCHIVELOG 
  FROM TIME 'SYSDATE-30' UNTIL TIME 'SYSDATE-7';

4.3.7.1.1 Automatic Online Redo Log Switches During Backups of Archived Logs

When taking a backup of archived redo logs that includes the most recent log (that is, a BACKUP ... ARCHIVELOG command is run without the UNTIL or SEQUENCE option) if the database is open, then before beginning the backup, RMAN will switch out of the current online redo log group, and all online redo logs that have not yet been archived, up to and including the redo log group that was current when the command was issued. This ensures that the backup contains all redo that was generated prior to the start of the command.

4.3.7.1.2 Using BACKUP ARCHIVELOG with DELETE INPUT or DELETE ALL INPUT

You can specify the DELETE INPUT or DELETE ALL INPUT clauses for the BACKUP ARCHIVELOG command to delete archived logs after they are backed up, eliminating the separate step of manually deleting the archived redo logs. With DELETE INPUT, RMAN only deletes the specific copy of the archived redo log chosen for the backup set. With DELETE ALL INPUT, RMAN will delete each backed-up archived redo log file from all log archiving destinations.

For example, assume that you archive to /arc_dest1, /arc_dest2, and /arc_dest3, and you run the following command:

BACKUP DEVICE TYPE sbt 
  ARCHIVELOG ALL 
  DELETE ALL INPUT;

In this case RMAN backs up only one copy of each log sequence number in these directories, and then deletes all copies of any log that it backed up from the archiving destinations. If you had specified DELETE INPUT rather than DELETE ALL INPUT, then RMAN would only delete the specific archived redo log files that it backed up (for example, it would delete the archived redo log files in /arc_dest1 if those were the files used as the source of the backup, but it would leave the contents of the /arc_dest2 and /arc_dest3 intact) .

If you issue BACKUP ARCHIVELOG ALL or BACKUP ARCHIVELOG LIKE '...', and there are no archived redo log files to back up, then RMAN does not signal an error.

4.3.7.2 Backing Up Logs with BACKUP ... PLUS ARCHIVELOG

You can add archived redo logs to a backup of other files by using the BACKUP ... PLUS ARCHIVELOG clause. Adding BACKUP ... PLUS ARCHIVELOG causes RMAN to do the following:

Runs the ALTER SYSTEM ARCHIVE LOG CURRENT command.
Runs BACKUP ARCHIVELOG ALL. Note that if backup optimization is enabled, then RMAN skips logs that it has already backed up to the specified device.
Backs up the rest of the files specified in BACKUP command.
Runs the ALTER SYSTEM ARCHIVE LOG CURRENT command.
Backs up any remaining archived logs generated during the backup.

This guarantees that datafile backups taken during the command are recoverable to a consistent state.

To back up archived redo logs with BACKUP ... PLUS ARCHIVELOG:

After starting RMAN, run the BACKUP ... PLUS ARCHIVELOG command at the RMAN prompt . This example backs up the database and all archived logs:

BACKUP DEVICE TYPE sbt
  DATABASE PLUS ARCHIVELOG;

Note:

If backup optimization is enabled, then RMAN skips backups of archived logs that have already been backed up to the specified device.