This section contains these topics:
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 BACKUPstatement. RMAN does not require the use of backup mode for the creation of online backups. Do not use
ALTER DATABASE/TABLESPACE BEGIN BACKUPbefore an RMAN backup.
You can perform whole database backups with the database mounted or open. To perform a whole database backup, from the RMAN prompt, use the
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.
After starting RMAN, run the
TABLESPACE command at the RMAN prompt. This example backs up the
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.
This example uses an
sbt channel to back up datafiles
4 and a datafile copy stored at
/tmp/system01.dbf to tape:
BACKUP DEVICE TYPE sbt DATAFILE 1,2,3,4 DATAFILECOPY '/tmp/system01.dbf';
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.
While connected to the target database, run the
DATAFILECOPY command at the RMAN prompt. This example backs up datafile
/tmp/system01.dbf to tape:
BACKUP DEVICE TYPE sbt DATAFILECOPY '/tmp/system01.dbf';
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
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:
Include a backup of the control file within any backup by using the
CONTROLFILE option of the
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.
See Also:Oracle Database Backup and Recovery Advanced User's Guide to learn more about control file autobackups
To include the current control file in a backup, specify the
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
TABLESPACE command completes, so that the control file autobackup contains the record of the backup that was taken.
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 (
CONTROLFILE) and the autobackup of the control file and server parameter file.
After starting RMAN, run the
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';
As explained in "Backing Up Control Files with RMAN", RMAN automatically backs up the current server parameter file in certain cases. The
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.
Archived redo logs are the key to successful media recovery. Back them up regularly. You can back up logs with
ARCHIVELOG, or back up logs while backing up datafiles and control files by specifying
To back up archived redo logs, use the
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';
When taking a backup of archived redo logs that includes the most recent log (that is, a
ARCHIVELOG command is run without the
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.
You can specify the
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
INPUT, RMAN only deletes the specific copy of the archived redo log chosen for the backup set. With
INPUT, RMAN will delete each backed-up archived redo log file from all log archiving destinations.
For example, assume that you archive to
/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
INPUT rather than
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_dest3 intact) .
If you issue
'...', and there are no archived redo log files to back up, then RMAN does not signal an error.
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
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.
After starting RMAN, run the
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.