| Oracle® Database Backup and Recovery Basics 10g Release 1 (10.1) Part Number B10735-01 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Basics 10g Release 1 (10.1) Part Number B10735-01 |
|
|
View PDF |
This chapter includes the following topics:
You generate an RMAN backup by running the BACKUP command from within the RMAN client. Often, an RMAN backup can be performed with a very simple command:
RMAN> BACKUP DATABASE;
Whenever you create a backup with RMAN, RMAN records the action in the RMAN repository. You can also record copies of files you create outside of RMAN (such as copies of datafiles created with host operating system commands) in the repository. When you attempt to restore the backups using the RESTORE command, RMAN queries the repository for information about available backups, then chooses among them to perform the restore efficiently.
RMAN backups can be taken when the database is mounted or open. (The database must at least be mounted, so that RMAN can have the use of the control file to write the RMAN repository.)
If the database is shut down normally and brought to a MOUNT state, and then a closed database backup is taken, the resulting backup is a consistent backup. When a database is restored from a consistent backup, it can be opened immediately. There is no redo to apply after the datafiles are restored.
If a database was not shut down normally before backup (that is, if the database was open, or exited abnormally, as in the case of a SHUTDOWN ABORT) then any backup you take is an inconsistent backup. When a database is restored from an inconsistent backup, Oracle must apply redo before the database can be opened. However, because inconsistent backups can be taken while the database is still available, inconsistent backups are a key part of many backup strategies.
RMAN can back up all database files needed for efficient recovery in the event of a failure. RMAN's BACKUP command supports backing up these types of files:
Although the database depends on other types of files for operation, such as network configuration files, password files, and the contents of the Oracle home, these files cannot be backed up with RMAN. Use some non-RMAN backup solution for any files not in the preceding list.
RMAN backups can be stored in one of two formats: as image copies or as backup sets.
An image copy is a bit-for-bit duplicate of a database file, identical to a copy made with an operating system command. (RMAN-created image copies are, however, recorded in the RMAN repository, unlike operating system-level file copies.) In principle, RMAN is not needed to restore a datafile from an image copy.
RMAN creates image copies when the AS COPY option is used with the BACKUP command. RMAN can create image copies of datafiles and datafile copies, control files and controlfile copies, archived redo logs, and backup pieces. RMAN supports creating image copies on disk, but not on media managers.
| See Also:
Oracle Database Backup and Recovery Advanced User's Guide for more detailed information about RMAN's handling of image copies |
RMAN can also store backup information in logical structures called backup sets. A backup set contains the data from one or more datafiles or archived redo logs, or control files or SPFILE. (Datafiles and archivelogs cannot be mixed together in the same backup set.) You can also back up existing backup sets into another backup set.
Only RMAN can create or restore from backup sets.When multiple files are backed up into the same backup set, they are read concurrently and their data is multiplexed together.
A backup set consists of one or more files called backup pieces, files in an RMAN-specific format. By default, a backup set consists of one backup piece. For example, you can back up ten datafiles into a single backup set containing a single backup piece (that is, one backup piece will be produced as output, and the backup piece and the backup set that contains it will be recorded in the RMAN repository). A file cannot be split across backup sets.
Backup sets are the only type of backup that RMAN supports on media manager devices such as tapes. Backup sets can also be created on disk. RMAN defaults to creating backups as backup sets on both disk and tape.
Never-used data blocks in datafiles are never copied into backup sets, saving storage space and overhead during the backup process. Unused block compression is fundamental to how RMAN writes datafiles into backup pieces, and cannot be disabled.
When storage space is more important to you than backup and restore times, you can use binary compression to reduce the size of your backup sets. The compression algorithm built into the Oracle server is tuned specifically for efficient compression of Oracle archived logs and datafiles, and will generally yield better compression than general-purpose compression utilities not tuned for Oracle database files.
Further, because it is integrated into Oracle, compressing backups requires only that you add the AS COMPRESSED BACKUPSET argument to your BACKUP command. Restoring from compressed backups requires no special action whatever.
Oracle Corporation recommends that you use RMAN's integrated binary compression instead of external compression utilities when you need to make compressed backups. For more 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 Recovery Manager Reference.
A full datafile backup is a backup that includes every used data block in the file. If the backup is created as a backupset, then unused block compression will cause unused blocks to be omitted. For an image copy, the entire file contents are reproduced exactly.
|
Note: A full backup is different from a whole database backup, which is a backup of all datafiles and the current control file. |
Incremental backups can only be created for datafiles. Incremental backups of datafiles capture datafile changes on a block-by-block basis, rather than requiring the backup of all used blocks in a datafile. The resulting backup sets are generally smaller than full datafile backups, unless every block in the datafile is changed.
During media recovery, RMAN examines the restored files to determine whether it can recover them with an incremental backup. When possible, RMAN chooses incremental backups over archived logs, because applying all changes to a block at once is faster than reapplying individual changes to the block from the redo logs.
RMAN supports attaching a tag to a backup as a way of identifying that backup. Tags can be unique for a particular backup or set of backups taken at a given time, such as 2003_year_end, or they can be re-used over time to identify a backup as being part of a series of backups, such as weekly_incremental. Many forms of the BACKUP command let you associate a tag with a backup, and many RESTORE and RECOVER commands let you specify which backups to use in the restore or recover operation by means of the tag provided when the backup was created.
In practice, tags are frequently used to distinguishing backups created in different strategies, especially incremental backup strategies.
This section contains these topics:
See Also:
|
Consistent backups can be restored without recovery. To make a consistent backup, the database must be mounted and must not have suffered an instance failure or closed with SHUTDOWN ABORT the last time it was open. If these conditions are not met, then the backup is inconsistent. An inconsistent backup requires media recovery when it is restored, but is otherwise just as valid as a consistent backup.
You can use SQL*Plus or RMAN to start up and shut down the database. The following example connects to the target database, shuts it down cleanly, and then mounts it in preparation for a backup:
% rman TARGET / RMAN> SHUTDOWN IMMEDIATE # closes database consistently RMAN> STARTUP MOUNT # uses SPFILE
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 following example backs up all the datafiles as well as the control file and server parameter file (if used) to the default configured device (in this example, disk). The backup will be stored in the default backup destination with an automatically generated filename. The default is determined as follows:
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.
The FORMAT parameter to the BACKUP DATABASE command lets you specify a different destination for backups and control the filename for the backup. For example, enter:
RMAN> BACKUP DATABASE FORMAT '/tmp/%U'; # %U generates a unique filename
You can also use the FORMAT argument to name an ASM disk group as backup destination, as shown in this example:
RMAN> BACKUP DATABASE FORMAT '+dgroup1'; # sets an ASM disk group
Optionally, use the TAG parameter to specify a backup tag. For example, enter:
RMAN> BACKUP DATABASE TAG = 'weekly_backup'; # gives the backup a tag identifier
RMAN assigns a default tag to backups.
| See Also:
Oracle Database Recovery Manager Reference for the default format description in |
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.
You can back up datafiles and datafile copies when the database is mounted or open.
Use the BACKUP DATAFILE command to back up individual datafiles. You can specify the datafiles by name or number.
To back up a datafile:
After starting RMAN and connecting to the target database, run the BACKUP DATAFILE command at the RMAN prompt. This example uses an sbt channel to back up datafiles 1-4 as well as a datafile copy:
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.
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';
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:
BACKUP CURRENT CONTROLFILEINCLUDE CURRENT CONTROLFILE option of the BACKUP command1, because RMAN automatically includes the control file and SPFILE in backups of datafile 1A 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 |
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 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.
To include the current control file in a backup set, 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.
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';
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.
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.
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';
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 commadn was issued. This ensures that the backup contains all redo that was generated prior to the start of the command.
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.
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:
ALTER SYSTEM ARCHIVE LOG CURRENT command.BACKUP ARCHIVELOG ALL. Note that if backup optimization is enabled, then RMAN skips logs that it has already backed up to the specified device.BACKUP command.ALTER SYSTEM ARCHIVE LOG CURRENT command.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. |
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.
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 some extra CPU overhead during backup and restore, which can slow the backup process. The performance penalty can be worth paying, however, in a number of circumstances:
Note that 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. |
You can make incremental backups of databases, individual tablespaces or datafiles.
As with other backups, if you are in ARCHIVELOG mode, you can make incremental backups if the database is open; if the database is in NOARCHIVELOG mode, then you can only make incremental backups when the database is closed.
The goal of an incremental backup is to back up only those data blocks that have changed since a previous backup.
The primary reasons for making incremental backups part of your strategy are:
NOLOGGING option. For example, direct load inserts do not create redo log entries and their changes cannot be reproduced with media recovery. They do, however, change data blocks and so are captured by incremental backups.NOARCHIVELOG databases. Instead of making a whole database backup every time, you can make incremental backups. Note that incremental backups of a NOARCHIVELOG database are only legal after a consistent shutdown.
| See Also:
Oracle Database Concepts for more information about |
One effective strategy is to make incremental backups to disk, and then back up these image copies to a media manager with BACKUP AS BACKUPSET. This avoids the problem of keeping the tape streaming that can occur when making incremental backups directly to tape. Because incremental backups are not as big as full backups, you can create them on disk more easily.
Each data block in a datafile contains a system change number (SCN), which is the SCN at which the most recent change was made to the block. During an incremental backup, RMAN reads the SCN of each data block in the input file and compares it to the checkpoint SCN of the parent incremental backup. If the SCN in the input data block is greater than or equal to the checkpoint SCN of the parent, then RMAN copies the block.
Note that if you enable the block change tracking feature, RMAN can refer to the change tracking file to identify changed blocks in datafiles without scanning the full contents of the datafile. Once enabled, block change tracking does not alter how you take or use incremental backups, other than offering increased performance. See "Improving Incremental Backup Performance: Change Tracking" for more details about enabling block change tracking.
Incremental backups can be either level 0 or level 1. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data, backing the datafile up into a backup set just as a full backup would. The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy.
A level 1 incremental backup can be either of the following types:
Incremental backups are differential by default.
The size of the backup file depends solely upon the number of blocks modified and the incremental backup level.
In a differential level 1 backup, RMAN backs up all blocks that have changed since the most recent cumulative or differental incremental backup, whether at level 1 or level 0. RMAN determines which level 1 backup occurred most recently and backs up all blocks modified after that backup. If no level 1 is available, RMAN copies all blocks changed since the level 0 backup.
If no level 0 backup is available, then the behavior depends upon the compatibility mode setting. If compatibility is >=10.0.0, RMAN copies all blocks changed since the file was created, and stores the results as a level 1 backup. In other words, the SCN at the time the incremental backup is taken is the file creation SCN. If compatibility <10.0.0, RMAN generates a level 0 backup, to be consistent with the behavior in previous releases.
Text description of the illustration brbsc009.gif
In the example shown in Figure 4-1, the following occurs:
An incremental level 0 backup backs up all blocks that have ever been in use in this database.
On each day from Monday through Saturday, a differential incremental level 1 backup backs up all blocks that have changed since the most recent incremental backup at level 1 or 0. So, the Monday backup copies blocks changed since Sunday level 0 backup, the Tuesday backup copies blocks changed since the Monday level 1 backup, and so forth.
In a cumulative level 1 backup, RMAN backs up all the blocks used since the most recent level 0 incremental backup. Cumulative incremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from any particular level. Cumulative backups require more space and time than differential backups, however, because they duplicate the work done by previous backups at the same level.
Text description of the illustration brbsc010.gif
In the example shown in Figure 4-2, the following occurs:
An incremental level 0 backup backs up all blocks that have ever been in use in this database.
A cumulative incremental level 1 backup copies all blocks changed since the most recent level 0 backup. Because the most recent level 0 backup was created on Sunday, the level 1 backup on each day Monday through Saturday backs up all blocks changed since the Sunday backup.
Choose a backup scheme according to an acceptable MTTR (mean time to recover). For example, you can implement a three-level backup scheme so that a full or level 0 backup is taken monthly, a cumulative level 1 is taken weekly, and a differential level 1 is taken daily. In this scheme, you never have to apply more than a day's worth of redo for complete recovery.
When deciding how often to take full or level 0 backups, a good rule of thumb is to take a new level 0 whenever 50% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental backups to determine when a new level 0 is appropriate. The following query displays the number of blocks written to a backup set for each datafile with at least 50% of its blocks backed up:
SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS FROM V$BACKUP_DATAFILE WHERE INCREMENTAL_LEVEL > 0 AND BLOCKS / DATAFILE_BLOCKS > .5 ORDER BY COMPLETION_TIME;
Compare the number of blocks in differential or cumulative backups to a base level 0 backup. For example, if you only create level 1 cumulative backups, then when the most recent level 1 backup is about half of the size of the base level 0 backup, take a new level 0.
After starting RMAN, run the BACKUP INCREMENTAL command at the RMAN prompt. This example makes a level 0 incrementnal backup of the database:
BACKUP INCREMENTAL LEVEL 0 DATABASE;
This example makes a differential level 1 backup of the SYSTEM tablespace and datafile tools01.dbf. It will only back up those data blocks changed since the most recent level 1 or level 0 backup:
BACKUP INCREMENTAL LEVEL 1 TABLESPACE SYSTEM DATAFILE 'ora_home/oradata/trgt/tools01.dbf';
This example makes a cumulative level 1 backup of the tablespace users, backing up all blocks changed since the most recent level 0 backup.
BACKUP INCREMENTAL LEVEL = 1 CUMULATIVE TABLESPACE users;
Oracle's Incrementally Updated Backups feature lets you create an image copy of a datafile, then regularly create incremental backups of your database and apply them to that image copy. The image copy is updated with all changes up through the SCN at which the incremental backup was taken. RMAN can use the resulting updated datafile in media recovery just as it would use a full image copy taken at that SCN, without the overhead of performing a full image copy of the database every day.
A backup strategy based on incrementally updated backups can help minimize time required for media recovery of your database. If you run scripts to implement this strategy daily, then at recovery time, you never have more than one day of redo to apply.
To create incremental backups for use in an incrementally updated backups strategy, you must use the BACKUP... FOR RECOVER OF COPY WITH TAG form of the BACKUP command. How the command works is best understood in the context of an example script that would implement the strategy.
This script, run on a regular basis, is all that is required to implement a strategy based on incrementally updated backups:
RUN { RECOVER COPY OF DATABASE WITH TAG 'incr_update'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; }
The syntax used in the script does not, however, make it clear how the strategy works. To understand the script and the strategy, it is necessary to understand the effects of these two commands when no datafile copies or incremental backups exist.
BACKUP INCREMENTAL LEVEL 1... FOR RECOVER OF COPY WITH TAG... command does not always create a level 1 incremental backup. If there is no incremental level 0 backup of an individual datafile to use with this level 1 backup, then executing this command creates a level 0 backup of the datafile with the specified tag.
Therefore, the first time the script runs, it creates the level 0 backup of the datafile needed to begin the cycle of incremental updates. In the second run and all subsequent runs, it produces level 1 incremental backups of the datafile.
RECOVER COPY OF DATABASE WITH TAG... command causes RMAN to apply any incremental level 1 backups to a set of datafile copies with the same tag. If there is no incremental backup or no datafile copy, the command generates a message but does not generate an error.
The first time the script runs, this command has no effect, because there is neither a datafile copy nor a level 1 incremental backup.
The second time the script runs, there is a datafile copy (created by the first BACKUP command), but no incremental level 1 backup, so again, the command has no effect.
On the third run and all subsequent runs, there is a datafile copy and a level 1 incremental from the previous run, so the level 1 incremental is applied to the datafile copy, bringing the datafile copy up to the checkpoint SCN of the level 1 incremental.
Note also the following details about how this example works:
In practice, you would schedule the example script to run once each day, possibly at midnight. On a typical night (that is, after the first two nights), when the script completed the following files would be available for a point-in-time recovery:
If, at some point during the following 24 hours, you need to restore and recover your database from this backup, for either complete or point-in-time recovery, you can restore the datafiles from the incrementally updated datafile copies, and apply changes from the most recent incremental level 1 and the redo logs to reach the desired SCN. At most, you will have 24 hours of redo to apply, which limits how long point-in-time recovery will take.
| See Also:
Oracle Database 2 Day DBA to see how this technique is used in the Oracle-suggested backup strategy in Enterprise Manager. |
The basic example can be extended to provide fast recoverability to a window greater than 24 hours. Alter the RECOVER COPY... WITH TAG to perform incomplete recovery of the datafile copies to the point in time in the past where you want your window of recoverability to begin. This example shows how to maintain a seven day window:
RUN { RECOVER COPY OF DATABASE WITH TAG 'incr_update' UNTIL TIME 'SYSDATE - 7'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; }
The effect of the script is as follows:
RECOVER COPY... UNTIL TIME statement has no effect, and the BACKUP INCREMENTAL... FOR RECOVER OF COPY statement creates the incremental level 0 copy.RECOVER COPY... UNTIL TIME statement has no effect because TIME 'SYSDATE - 7' is still a time in the future. The BACKUP INCREMENTAL... FOR RECOVER OF COPY statement creates differetial incremental level 1 backups containing the block changes for the previous day.RECOVER COPY... UNTIL TIME statement applies the level 1 incremental from seven days ago to the copy of the database. The BACKUP INCREMENTAL... FOR RECOVER OF COPY statement creates an incremental backup containing the changes for the previous day.As with the basic example, you have fast recoverability to any point in time between the SCN of the datafile copies and the present, using block changes from the incremental backups and individual changes from the redo logs. Because you have the daily level 1 incrementals, you still never need to apply more than one day of redo.
RMAN's change tracking feature for incremental backups improves incremental backup performance by recording changed blocks in each datafile in a change tracking file. If change tracking is enabled, RMAN uses the change tracking file to identify changed blocks for incremental backup, thus avoiding the need to scan every block in the datafile.
After enabling change tracking, the first level 0 incremental backup still has to scan the entire datafile, as the change tracking file does not yet reflect the status of the blocks. Subsequent incremental backup that use this level 0 as parent will take advantage of the change tracking file.
Using change tracking in no way changes the commands used to perform incremental backups, and the change tracking files themselves generally require little maintenance after initial configuration.
Change tracking is disabled by default, because it does introduce some minimal performance overhead on your database during normal operations. However, the benefits of avoiding full datafile scans during backup are considerable, especially if only a small percentage of data blocks are changed between backups. If your backup strategy involves incremental backups, then you should enable change tracking.
One block change tracking file is created for the whole database. By default, the block change tracking file is created as an Oracle managed file in DB_CREATE_FILE_DEST. You can also specify the name of the block change tracking file, placing it in any location you choose.
Oracle saves enough change-tracking information to enable incremental backups to be taken using any of the 8 most recent incremental backups as its parent.
Although RMAN does not support backup and recovery of the change-tracking file itself, if the whole database or a subset needs to be restored and recovered, then recovery has no user-visible effect on change tracking. After the restore and recovery, the change tracking file is cleared, and starts recording block changes again. The next incremental backup after any recovery is able to use change-tracking data.
The size of the change tracking file is proportional to the size of the database and the number of enabled threads of redo. The size is not related to the frequency of updates to the database. The space required for block change tracking is approximately 1/30,000 the size of the data blocks to be tracked. However, to avoid overhead of allocating space as your database grows, the change tracking file size starts at 10MB, and new space is allocated in 10MB incremenents. Thus, for any database up to approximately 1TB the file size is 10MB, for up to 2TB the file size is 20MB, and so on.
You can enable or disable change tracking when the database is either open or mounted. To alter the change tracking setting, you must use SQL*Plus to connect to the target database with administrator privileges.
To store the change tracking file in the database area, set DB_CREATE_FILE_DEST in the target database. Then issue the following SQL statement to enable change tracking:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
You can also create the change tracking file in a location you choose yourself, using the following SQL statement:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/mydir/rman_change_track.f' REUSE;
The REUSE option tells Oracle to overwrite any existing file with the specified name.
To disable change tracking, use this SQL statement:
SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
If the change tracking file was stored in the database area, then it is deleted when you disable change tracking.
From SQL*Plus, you can query V$BLOCK_CHANGE_TRACKING.STATUS to determine whether change tracking is enabled, and if it is, query V$BLOCK_CHANGE_TRACKING.FILENAME to display the filename.
If you need to move the change tracking file, the ALTER DATABASE RENAME FILE command updates the control file to refer to the new location. The process outlined in this section describes how to change the location of the change tracking file while preserving its contents.
To relocate the block change tracking file:
SELECT filename FROM V$BLOCK_CHANGE_TRACKING;
SHUTDOWN IMMEDIATE
ALTER DATABASE RENAME FILE 'ora_home/dbs/change_trk.f' TO '/new_disk/change_ trk.f';
ALTER DATABASE OPEN;
If you cannot shut down the database, then you must disable change tracking and re-enable it at the new location, as in the following example:
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'new_location';
If you choose this method, you will lose the contents of the change tracking file. Until the next time you complete a level 0 incremental backup, RMAN will have to scan the entire file.
For all of the following scenarios, assume that the RMAN environment and flash recovery area are configured as shown in "Configure Flash Recovery Area for Disk-Based Backups: Example".
Backup scripts depend on the database load and the amount of disk space allocated. You can categorize the scripts based on how the database is used and the minimum amount of disk limit required to achieve the recovery window on disk.
If few database blocks change, then the incremental backup size will be significantly less than the size of the database, and the best practice is to take incremental backups, to make efficient use of disk space and other resources.
If most or all database blocks change frequently, then the size of incremental backup will be roughly as large as the size of the database, and the best practice is to periodically make a complete image copy of the database.
In the following scenarios, you do not need to back up archived logs because Oracle archives the logs to the flash recovery area. They will remain in the flash recovery area for as long as they are required by the retention policy. All database backups are also all directed to the flash recovery area.
This section contains the following topics:
If most data blocks do not change each day, incremental backups will be small and you can plan your strategy around daily incremental backups.
The minimum recommended flash recovery area size on disk is dependent on the how frequent the backups are taken and retention policy used.
If your configured retention policy is REDUNDANCY X and you plan to take a backup every Y days, then the formula for the recommended flash recovery area disk quota is:
Disk Quota = Size of X copies of database + Size of one copy of incremental backups + Size of (Y+1) days of archived logs
If you configure your retention policy to a recovery window of X days and execute your backup script once in Y days then you can calculate your required disk quota by one of two formulas. If X>=Y then the formula for the recommended flash recovery area disk quota is:
Disk Quota = Size of one copy of database + Size of (floor(X/Y) + 1) copies of incremental backups + Size of (X * ceil(X/Y) +1) days of archived logs
where ceil(X/Y) is the smallest integer greater than or equal to X/Y and floor(X/Y) is the largest integer less than or equal to X/Y.
If X <Y then the recommended formula is:
Disk Quota = Size of one copy of database + Size of 2 copies of incremental backups + Size of (Y +1) days of archived logs
Size your flash recovery area according to the applicable formula.
For this example, assume that the retention policy is REDUNDANCY 1:
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
Also assume that backups will be performed daily.
The daily backup script would look like this:
RMAN> RECOVER COPY OF DATABASE WITH TAG "whole_db_cpy"; # Make an incremental backup of the database to the flash recovery area. RMAN> BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "whole_db_copy" DATABASE;
Assume that there are no backups tagged "whole_db_copy" as of the first day of this backup scheme. The results of running this script daily are as follows:
RECOVER statement would have no effect, and the BACKUP... FOR RECOVER OF COPY would create the initial level 0 database copy.RECOVER statement still has no effect, as there is no level 1 incremental backup to be applied to the level 0 incremental database copy. The BACKUP command creates the first incremental level 1 backup.Assuming that this backup strategy is put into effect on February 1, Table 4-1 shows how the flash recovery area contents change over time as a result of the strategy. (Note that the flash recovery area may contain other files based on other backup activities; this table only represents files related to this strategy.)
To alter the example slightly: if you can size the flash recovery area to hold n days worth of archived logs and incremental backups (where n > 1), then you can alter the RECOVER line to RECOVER COPY UNTIL TIME 'SYSDATE-n'. For example, if the flash recovery area is large enough to hold three days of incremental backups, then you can change the script as follows:
RECOVER COPY OF DATABASE TAG "whole_db_copy" UNTIL TIME 'SYSDATE-3'; # Make an incremental backup of the database to the flash recovery area. BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "whole_db_copy" DATABASE;
Every day that you run the script, RMAN rolls forward the whole database copy to an SCN three days before the current time. Hence, the disk quota rules will preserve archived logs and incremental backups created after SYSDATE-3 (because they are needed to recover the database to an SCN within the last three days.
The following table lists the set of files expected to be in the flash recovery area each day after the daily script for this strategy is run.
In this scenario, typical of a CRM environment, many or most of the data blocks are updated over the course of a week.
If you use a retention policy of redundancy X, and a backup script executed once each Y days, the minimum disk quota required is determined by the following formula:
Disk Quota = Size of X copies of the database + size of Y days of archived redo logs
If you use a retention policy of a recovery window of X days, and the backup script is executed once each Y days, then if X>=Y, then disk quota is determined by the following formula:
Disk Quota = Size of 1 copy of the database + size of ((X * ceil(X/Y)) +1) days of archived redo logs
where ceil(X/Y) is the smallest integer greater than or equal to X/Y.
If X<Y, the disk quota is the same as when X=Y, that is,
Disk Quota = Size of 1 copy of the database + size of (Y +1) days of archived redo logs
For this example, assume that the retention policy is REDUNDANCY 1, and you are executing the backup script once each week. The minimum disk quota required for this scenario is as follows:
Disk Quota = Size of 1 copy of the database + size of 8 days of archived logs
This scenario requires no initial setup script. The weekly backup script is shown here:
# Execute once a week # Make a full backup of the database to the flash recovery area. BACKUP DATABASE TAG "weekly_full_bkup";
As shown in Table 4-2, the disk quota needs only to keep one level 0 copy of the database and one week's worth of archived logs.
Use this strategy when roughly half the data blocks change weekly, or when the number of data blocks that change varies widely from week to week. The scripts in this strategy are "all purpose" scripts that use incrementally updated backups, starting with an image copy of the database, taking incremental level 1 backups at regular intervals, and rolling forward the existing level 0 copy.
The formula for determining space required for the flash recovery area depends upon the retention policy. For a retention policy of REDUNDANCY X and a backup script that runs once every Y days, the disk space required is:
Disk Quota = Size of X copies of the database + Size of 1 incremental backup + Size of Y+1 days of archived redo logs
For a recovery window of X days and a backup script executed once each Y days, if X>=Y then the space required is:
Disk Quota = Size of 1 copy of the database + Size of floor(X/Y)+1 incremental backups + Size of (X * ceil(X/Y)) + 1 days of archived logs
where ceil(X/Y) is the smallest integer greater than or equal to X/Y and floor(X/Y) is the largest integer less than or equal to X/Y.
If X< Y then the space required is the same as when X=Y:
Disk Quota = Size of 1 copy of the database + Size of 2 incremental backups + Size of Y+1 days of archived logs
For the example that follows, assume that the retention policy is REDUNDANCY 1 and the backup script is run once each week.
The minimum disk quota for such a scenario is
Disk Quota = Size of 1 copy of the database + Size of 1 incremental backup + Size of 8 days of archived logs
The first week, the BACKUP... FOR RECOVER OF COPY command makes a level 0 incremental backup of the database to the flash recovery area. This backup will be the basis for the weekly strategy. Each subsequent week, this copy is rolled forward to the last incremental backup checkpoint time. In this way, you create an on-disk recovery window of one week.
After the initial setup, the weekly backup script (which, for example, you could run every Sunday night) should look like the following:
# Execute once a week # Roll forward the whole copy of the database to last incremental backup SCN RECOVER COPY OF DATABASE TAG "whole_db_cpy"; # Make an incremental backup of the database to the flash recovery area. BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "whole_db_copy" DATABASE;
Table 4-3 illustrates how the contents of the flash recovery area change with each run of the backup script, always keeping enough archived logs and backups on hand to maintain the seven day recovery window.
This scenario describes how to use RMAN to make backups to the flash recovery area and then later move them to tape.
The scripts in this section use the flash recovery area as the log archiving destination and the destination for all disk backups. Therefore, whenever there is no space to create archived logs or backups in the flash recovery area, Oracle automatically deletes archived logs and backups that are obsolete or that have been moved to tape.
By moving backup files and archived redo logs to tape, more space becomes available in the flash recovery area for new files. The formulas for the flash recovery area disk quota are suggested minimums, and depend upon the availability of space on tape to satisfy the retention policy. You can, however, increase your on-disk recovery window and reduce the need to restore archived redo logs and backups from tape during a database restore-and-recovery scenario, by allocating a larger flash recovery area disk quota than these formulas specify.
Invoke RMAN to configure the retention policy, backup optimization, and the control file autobackup. For example:
CONNECT TARGET SYS/orace@trgt; # Recovery window of 15 days ensures that the database is recoverable within 7 # days using backups on disk and tape CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS; CONFIGURE BACKUP OPTIMIZATION ON; # Because you do not use a recovery catalog, enable the autobackup feature CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE DEVICE TYPE sbt PARMS='...' PARALLELISM 1; # PARMS are vendor-specific
As in the disk-only scenarios, the backup scripts in this section are categorized based on database workload.
In this scenario, relatively few data blocks change frequently, so daily level 1 incremental backups will typically be small. The goal is to keep one level 0 incremental backup on disk, incrementally updated each day using a level 1 incremental backup, and then move all other files onto tape. This keeps flash recovery area usage to a minimum.
The only required setup is to create a flash recovery area with the required disk quota, and set the flash recovery area as a redo log archiving destination.
The formula for determining your disk quota depends upon the backup retenion policy. It is the same, however, whether your retention policy is based on redundancy or recovery window. Use the following formula:
Disk Quota = Size of 1 copy of the database + size of 1 day's level 1 incremental backup + size of (Y+1) days of archived logs
where Y is the number of days that elapse between executionof BACKUP RECOVERY AREA in your backup scripts.
For this example, there is one backup script, executed every day, which creates a new incremental level 1 backup with that day's changes, rolls forward the level 0 backup using the level 1 backup from the previous day, and backs up all flash recovery area files to tape. Since the script backs up the flash recovery area to tape daily, the flash recovery area must be large enough to hold a copy of the database, the daily level 1 incremental backup, and two days' worth of archived redo logs.
The on-disk recovery window is one day. To recover to a point farther back than one day, RMAN must restore backups from tape.
After the initial setup, a typical daily RMAN backup script would look like the following:
# Execute each day of the week # Roll forward the copy to most recent incremental backup SCN, which will # be yesterday's incremental level 1 backup RECOVER COPY OF DATABASE WITH TAG "daily_backup"; # Take incremental backups to flash recovery area (using default disk channel) BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "daily_backup" DATABASE; # Back up flash recovery area to tape BACKUP RECOVERY AREA; # delete obsolete backups on tape DELETE OBSOLETE DEVICE TYPE sbt;
Table 4-4 describes how the contents of the flash recovery area and tape change as this script is run each day. The script rolls forward the level 0 database copy tagged as daily_backup to the SCN of the preceding day's incremental level 1 backup, then creates a new level 1 incremental backup with the previous day's changes. For example, when you run the script on Thursday, RMAN rolls forward the level 0 backup to the SCN of the incremental backup on Wednesday.
In this scenario, many or most of the data blocks are updated over the course of a week, as in a CRM environment. A strategy using daily incremental backups would not be recommended because the size of the incremental backups could be quite large and is hard to predict.
A better strategy in this case is to back up the database to tape weekly and the archived logs to tape every day, and to use a recovery window-based retention policy.
The elements of the strategy are as follows:
BACKUP RECOVERY AREA command, and any obsolete backups on tape are deleted.If you use a recovery window-based retention policy, all backups required to perform point-in-time recovery within the window are retained as long as they are needed. This provides the necessary protection for your data, even with limited use of disk space.
Create your flash recovery area with the required disk quota and set up the flash recovery area as a redo log archiving destination. The formula for determining your disk quota depends upon the frequency of backups of the flash recovery area to tape, as follows:
Disk Quota = Size of 1 copies of the database + size of (Y+1) days of archived logs
where Y is the number of days that elapse between executionof BACKUP RECOVERY AREA in your backup scripts.
For this example, assume that you take a full database backup once each week, and back up the flash recovery area to tape on all seven days of the week.
There are two scripts in this strategy. Use the first script at the beginning of each week (say, on Sunday) to create a full database backup, and the other script on the remaining days of the week (Monday through Saturday) to back up the flash recovery area contents (the archived redo logs for the day) to tape.
Note that both of the scripts in this strategy include the BACKUP RECOVERY AREA command, so that command is executed every day. For this example, Y=1, so the disk quota is the size of one copy of the database plus two days of archived redo logs.
This RMAN backup script is executed once each week, on Sunday:
# Execute only once a week # Take copy of database to flash recovery area BACKUP AS COPY DATABASE; # Take backup of flash recovery area to tape BACKUP RECOVERY AREA; # Delete obsolete backups on tape DELETE OBSOLETE DEVICE TYPE sbt; EXIT;
The RMAN script to be executed each day (Monday through Saturday) would look like the following:
# Execute 6 days/wk # Take backup of flash recovery area to tape BACKUP RECOVERY AREA; # delete obsolete backups on tape DELETE OBSOLETE DEVICE TPE sbt;
Because the entire flash recovery area is backed up to tape every day, the database may delete backups and archived redo log files from the flash recovery area whenever space is needed for new files. Between backups it may be difficult to predict exactly which files will still be in the flash recovery area, because files are deleted whenever space is needed.
The following strategy is based on full database backups taken at regular intervals. It is useful when about half of the data blocks change during the interval between full database backups, or when the number of changed data blocks varies widely between full database backups.
The strategy is based on an incrementally updated backups-based full backup of the database, rolled forward once each week. This requires a level 0 disk copy incremental backup of the database, and a level 1 incremental created each Sunday with the previous seven days of datafile changes. After the roll-forward, the contents of the flash recovery area are backed up to tape, so the incremental level 0 copy of the database and the level 1 weekly incremental backup are available both on disk and tape.
Each day, archived redo log files accumulate in the flash recovery area. Each time the daily script runs, those redo log files are backed up to tape. After that, they may be deleted from disk if space is needed in the flash recovery area.
The minimum flash recovery area disk quota for this scenario is calculated with the following formula:
Disk Quota = Size of 1 copy of the database + Size of 1 level 1 incremental backup with Y days of changes + Size of (Y+1) days of archived redo logs
where Y is the number of days between backing up the flash recovery area to tape.
For this example, Y=7, so the disk quota must be at least the size of one copy of the database, one seven-day level 1 incremental backup, and eight days' worth of archived redo logs.
The script that implement the Sunday backup for this strategy weekly parts of the backup is as follows:
# Execute once a week # Roll forward the whole copy of the database to last incremental backup SCN RECOVER COPY OF DATABASE WITH TAG "whole_db_cpy"; # Make an incremental backup of the database to the flash recovery area. BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG "whole_db_copy" DATABASE; # Back up flash recovery area to tape BACKUP RECOVERY AREA; # delete obsolete backups on tape DELETE OBSOLETE DEVICE TYPE sbt;
The daily script for this strategy is shown here:
# Execute 6 days/wk # Back up flash recovery area to tape BACKUP RECOVERY AREA; # delete obsolete backups on tape DELETE OBSOLETE DEVICE TYPE sbt;
Table 4-5 illustrates how the scripts maintain the recovery window. Assume for the purposes of this example that the week begins on Sunday.
If the disk quota is not sufficient to keep a copy of database, then the flash recovery area should be used only as an archived log destination. The disk quota rules will automatically delete these logs from the flash recovery area when they are no longer needed (because they are obsolete or because they have been backed up to tape). Back up the archived logs to tape daily, to ensure that they can be deleted from the flash recovery area when space is needed there for other files.
For this strategy, the flash recovery area should be sized large enough to hold at least two days' worth of archived redo logs, plus one day's worth of incremental backup.
This strategy is based on level 0 and level 1 incremental backups (though it does not use incrementally updated backups). This strategy uses two scripts: one to be executed once a week (for example, on Sunday), and the other to be executed every day except for the day that the first script is executed (Monday through Saturday).
The script that runs once each week creates a level 0 incremental backup on tape, containing the full contents of the database.
The script that runs each day except the first day creates level 1 incremental backups containing the changes to the database each day.
Here is the script to run once at the beginning of each week
# Execute only once a week # backup database to tape BACKUP DEVICE TYPE sbt INCREMENTAL LEVEL 0 DATABASE; # delete obsolete backups on tape DELETE OBSOLETE DEVICE TYPE sbt; # backup recovery file destination to tape BACKUP RECOVERY AREA;
This script executes each day of the week except for the first day, for example, Monday through Saturday:
# backup recovery file destination to tape BACKUP RECOVERY AREA; # Take incremental backups to flash recovery area BACKUP DEVICE TYPE DISK INCREMENTAL LEVEL 1 DATABASE;
Table 4-6 illustrates how the scripts maintain the RMAN retention policy recovery window and how the disk quota is maintained. The recovery files that exist after the execution of the script each day also exist on tape, so Oracle can delete files from the flash recovery area as needed.
You can use the VALIDATE keyword of the BACKUP command to check datafiles for physical and logical corruption and confirm that all database files exist and are in the correct locations.
RMAN does not actually produce backup sets, but scans the files to determine whether they can be backed up and are not corrupted. The BACKUP VALIDATE command is similar to the RESTORE VALIDATE command. If the backup validation discovers corrupt blocks, then RMAN updates the V$DATABASE_BLOCK_CORRUPTION view with rows describing the corruptions. After a corrupt block is repaired, the row identifying this block is deleted from the view.
For example, you can validate that all database files and archived logs can be backed up by running a command as follows:
BACKUP VALIDATE DATABASE ARCHIVELOG ALL;
RMAN displays the same output that it would if it were really backing up the files. If RMAN cannot validate the backup of one or more of the files, then it issues an error message. For example, RMAN may show output similar to the following:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 08/29/2002 14:33:47 ORA-19625: error identifying file /oracle/oradata/trgt/arch/archive1_6.dbf ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3
You cannot use the MAXCORRUPT or PROXY parameters with the VALIDATE option.
See Also:
|
You can obtain information from the RMAN repository in several different ways. The following table describes the basic options.
The main sources of information about RMAN from within the RMAN interface are the REPORT and LIST commands. Use these commands to query the RMAN repository and determine what you have backed up as well as what you need to back up. If you are in SQL*Plus, then you can query V$BACKUP_FILES. Note that the database must be open to perform this query.
See Also:
|
The LIST command queries the recovery catalog or control file and lists the backups, archived logs, and database incarnations. You can specify these files when running the CHANGE, CROSSCHECK, and DELETE commands.
This section contains these topics:
You can control how the output is displayed by using the BY BACKUP and BY FILE options of the LIST command and choosing between the SUMMARY and VERBOSE options.
The primary purpose of the LIST command is to determine which backups are available. Note that only backups that completed successfully are stored in the repository. For example, you can list:
Use LIST to determine what you need to back up. In particular, ensure that:
STATUS columns of the output tables list all backups as AVAILABLENote that the V$BACKUP_FILES also contains list information for backups.
By default, RMAN lists backups by backup, which means that it serially lists each backup or proxy copy and then identifies the files included in the backup. You can also list backups by file.
By default, RMAN lists in verbose mode. You can also list backups in a summary mode if the verbose mode generates too much output.
To list backups by backup, connect to the target database and recovery catalog (if you use one), and then execute the LIST BACKUP command. Specify the desired objects with the listObjList clause. For example, you can enter:
LIST BACKUP; # lists backup sets, image copies, and proxy copies LIST BACKUPSET; # lists only backup sets and proxy copies LIST COPY; # lists only disk copies
Optionally, specify EXPIRED to identify backups not found during a crosscheck:
LIST EXPIRED BACKUP;
Examine the output (refer to Oracle Database Recovery Manager Reference for an explanation of the various column headings in the LIST output). Sample output of LIST BACKUP follows:
List of Backup Sets =================== BS Key Size Device Type Elapsed Time Completion Time ------- ---------- ----------- ------------ --------------- 7 136M DISK 00:00:20 04-NOV-03 BP Key: 7 Status: AVAILABLE Compressed: NO Tag: TAG20031104T200759 Piece Name: /oracle/work/RDBMS/backupset/2003_11_04/o1_mf_annnn_TAG20031104T200759_ztjxx3k8_.bkp List of Archived Logs in backup set 7 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 1 173832 21-OCT-03 174750 21-OCT-03 1 2 174750 21-OCT-03 174755 21-OCT-03 1 3 174755 21-OCT-03 174758 21-OCT-03 1 37 533321 01-NOV-03 575472 03-NOV-03 1 38 575472 03-NOV-03 617944 04-NOV-03 1 39 617944 04-NOV-03 631495 04-NOV-03 BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 8 Full 2M DISK 00:00:01 04-NOV-03 BP Key: 8 Status: AVAILABLE Compressed: NO Tag: TAG20031104T200829 Piece Name: /ade/lashdown_rdbms/oracle/dbs/c-774627068-20031104-01 Controlfile Included: Ckp SCN: 631510 Ckp time: 04-NOV-03 SPFILE Included: Modification time: 21-OCT-03
Sample output of LIST COPY follows:
List of Archived Log Copies Key Thrd Seq S Low Time Name ------- ---- ------- - --------- ---- 37 1 37 A 01-NOV-03 /oracle/work/RDBMS/archivelog/2003_11_03/o1_mf_1_37_ztd4hl5d_.arc 38 1 38 A 03-NOV-03 /oracle/work/RDBMS/archivelog/2003_11_04/o1_mf_1_38_zthvg168_.arc 39 1 39 A 04-NOV-03 /oracle/work/RDBMS/archivelog/2003_11_04/o1_mf_1_39_ztjxwxwy_.arc
Specify the desired objects with the listObjList or recordSpec clause (refer to Oracle Database Recovery Manager Reference). If you do not specify an object, then RMAN displays copies of all database files and archived logs. By default, RMAN lists in verbose mode, which means that it provides extensive, multiline information.
To list backups by file, connect the RMAN client to the target database and recovery catalog (if you use one), and then execute LIST with the BY FILE option, specifying the desired objects to list and options.For example, you can enter:
LIST BACKUP BY FILE; # shows backup sets, proxy copies, and image copies LIST COPY BY FILE; # shows only disk copies
For another example, you could specify the EXPIRED option to identify backups not found during a crosscheck:
LIST EXPIRED BACKUP BY FILE;
Examine the output (refer to Oracle Database Recovery Manager Reference for an explanation of the various column headings in the LIST output). Sample output follows:
List of Datafile Backups ======================== File Key TY LV S Ckp SCN Ckp Time #Pieces #Copies Compressed Tag ---- ------- - -- - ---------- --------- ------- ------- ---------- --- 1 5 B F A 631092 04-NOV-03 1 1 YES TAG20031104T195949 2 B F A 175337 21-OCT-03 1 1 NO TAG20031021T094513 2 5 B F A 631092 04-NOV-03 1 1 YES TAG20031104T195949 2 B F A 175337 21-OCT-03 1 1 NO TAG20031021T094513 ... some rows omitted List of Archived Log Backups ============================ Thrd Seq Low SCN Low Time BS Key S #Pieces #Copies Compressed Tag ---- ------- ---------- --------- ------- - ------- ------- ---------- --- 1 1 173832 21-OCT-03 7 A 1 1 NO TAG20031104T200759 1 A 1 1 NO TAG20031021T094505 1 2 174750 21-OCT-03 7 A 1 1 NO TAG20031104T200759 1 A 1 1 NO TAG20031021T094505 ... some rows omitted 1 38 575472 03-NOV-03 7 A 1 1 NO TAG20031104T200759 1 39 617944 04-NOV-03 7 A 1 1 NO TAG20031104T200759 List of Controlfile Backups =========================== CF Ckp SCN Ckp Time BS Key S #Pieces #Copies Compressed Tag ---------- --------- ------- - ------- ------- ---------- --- 631510 04-NOV-03 8 A 1 1 NO TAG20031104T200829 631205 04-NOV-03 6 A 1 1 NO TAG20031104T200432 175380 21-OCT-03 4 A 1 1 NO TAG20031021T094639 List of SPFILE Backups ====================== Modification Time BS Key S #Pieces #Copies Compressed Tag ----------------- ------- - ------- ------- ---------- --- 21-OCT-03 8 A 1 1 NO TAG20031104T200829 21-OCT-03 6 A 1 1 NO TAG20031104T200432
By default the LIST output is detailed, but you can also specify that RMAN display the output in summarized form. Specify the desired objects with the listObjectList or recordSpec clause. If you do not specify an object, then LIST BACKUP displays all backups.
After connecting to the target database and recovery catalog (if you use one), execute LIST BACKUP, specifying the desired objects and options. For example:
LIST BACKUP SUMMARY; # lists backup sets, proxy copies, and disk copies
You can also specify the EXPIRED keyword to identify those backups that were not found during a crosscheck:
LIST EXPIRED BACKUP SUMMARY;
Sample output follows:
List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag ------- -- -- - ----------- --------------- ------- ------- ---------- --- 1 B A A SBT_TAPE 21-OCT-03 1 1 NO TAG20031021T094505 2 B F A SBT_TAPE 21-OCT-03 1 1 NO TAG20031021T094513 3 B A A SBT_TAPE 21-OCT-03 1 1 NO TAG20031021T094624 4 B F A SBT_TAPE 21-OCT-03 1 1 NO TAG20031021T094639 5 B F A DISK 04-NOV-03 1 1 YES TAG20031104T195949 6 B F A DISK 04-NOV-03 1 1 NO TAG20031104T200432 7 B A A DISK 04-NOV-03 1 1 NO TAG20031104T200759 8 B F A DISK 04-NOV-03 1 1 NO TAG20031104T200829
Refer to Oracle Database Recovery Manager Reference for an explanation of the various column headings in the LIST output.
You can specify several different conditions to narrow your LIST output.
After connecting to the target database and recovery catalog (if you use one), execute LIST COPY or LIST BACKUP with the listObjList or recordSpec condition. For example, enter any of the following commands:
# lists backups of all files in database LIST BACKUP OF DATABASE; # lists copy of specified datafile LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf'; # lists specified backup set LIST BACKUPSET 213; # lists datafile copy LIST DATAFILECOPY '/tmp/tools01.dbf';
You can also restrict the search by specifying the maintQualifier or RECOVERABLE clause. For example, enter:
# specify a backup set by tag LIST BACKUPSET TAG 'weekly_full_db_backup'; # specify a backup or copy by device type LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf' DEVICE TYPE sbt; # specify a backup by directory or path LIST BACKUP LIKE '/tmp/%'; # specify a backup or copy by a range of completion dates LIST COPY OF DATAFILE 2 COMPLETED BETWEEN '10-DEC-2002' AND '17-DEC-2002'; # specify logs backed up at least twice to tape LIST ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;
The output depends upon the options you pass to the LIST command. For example, the following lists copies of datafile 1:
RMAN> list backup of datafile 1; List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 2 Full 230M SBT_TAPE 00:00:49 21-OCT-03 BP Key: 2 Status: AVAILABLE Compressed: NO Tag: TAG20031021T094513 Handle: 02f4eatc_1_1 Media: /smrdir List of Datafiles in backup set 2 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 175337 21-OCT-03 /oracle/dbs/tbs_01.f BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 5 Full 233M DISK 00:04:30 04-NOV-03 BP Key: 5 Status: AVAILABLE Compressed: NO Tag: TAG20031104T195949 Piece Name: /oracle/work/RDBMS/backupset/2003_11_04/o1_mf_nnndf_ TAG20031104T195949_ztjxfvgz_.bkp List of Datafiles in backup set 5 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 631092 04-NOV-03 /ade/lashdown_rdbms/oracle/dbs/tbs_01.f
See Also:
|
Each time an OPEN RESETLOGS operation is performed on a database, this operation creates a new incarnation of the database. Database incarnations and their effect upon database recovery with RMAN are explained in more detail in Oracle Database Backup and Recovery Advanced User's Guide.
When performing incremental backups, RMAN can use a backup from a previous incarnation or the current incarnation as a basis for subsequent incremental backups. When performing restore and recovery, RMAN can use backups from a previous incarnation in restore and recovery operations just as it would use backups from the current incarnation, as long as all archived logs are available.
Use the LIST INCARNATION command to see the incarnations of your database.
To list database incarnations:
After connecting to the target database and the recovery catalog if applicable, run LIST INCARNATION:
RMAN> LIST INCARNATION;
If you are using a recovery catalog, and if you register multiple target databases in the same catalog, then you can distinguish them by using the OF DATABASE option:
RMAN> LIST INCARNATION OF DATABASE prod3;
Refer to Oracle Database Recovery Manager Reference for an explanation of the various column headings in the LIST output). Sample output follows:
RMAN> LIST INCARNATION OF DATABASE; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time ------- ------- -------- ---------------- ------ ---------- ---------- 1 1 RDBMS 774627068 PARENT 1 21-OCT-03 2 2 RDBMS 774627068 CURRENT 173832 21-OCT-03
The preceding output indicates that a RESETLOGS was performed on database trgt at SCN 164378, resulting in a new incarnation. The incarnation is distinguished by incarnation key (represented in the Inc Key column).
This section contains the following topics:
To gain more detailed information from the RMAN repository, generate a report. The REPORT command can help answer questions such as the following:
| See Also:
Chapter 6, "Recovery Manager Maintenance Tasks" to learn how to maintain the RMAN repository. |
The information that you obtain from reports can be important for your backup and recovery strategy. In particular, run the REPORT NEED BACKUP and REPORT UNRECOVERABLE commands to ensure that the backups are available to perform recovery, and recovery can be performed within a reasonable length of time.
You can report on files that require a backup by specifying the NEED BACKUP keyword. The REDUNDANCY parameter specifies the minimum number of backups that must exist for a datafile to be considered not in need of a backup. If you do not specify the parameter, REDUNDANCY defaults to 1. The DAYS parameter indicates that recovery must begin by using logs more than integer days old. The INCREMENTAL parameter indicates that more than integer incremental backups are required for complete recovery.
|
Note: If you disable the retention policy, then |
To report on files that need a backup:
CROSSCHECK commands as needed to verify the status and availability of backups known to RMAN. If files have been deleted, the RMAN repository will be out of date. This sequence of commands would crosscheck disk image copies, backupsets, and tape and proxy backups:
# allocate maintenance channel for crosscheck if no channels configured ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; CROSSCHECK BACKUP; # crosschecks backup sets and proxy copies
CROSSCHECK COPY; # crosschecks only disk copies of # archived redo logs, datafiles and control file
REPORT NEED BACKUP without any other options to determine which files need backups (sample output follows):
REPORT NEED BACKUP; RMAN retention policy will be applied to the command RMAN retention policy is set to redundancy 1 Report of files with less than 1 redundant backups File #bkps Name ---- ----- ----------------------------------------------------- 2 0 /oracle/oradata/trgt/undotbs01.dbf
REPORT NEED BACKUP DAYS. Any files older than the DAYS parameter value need a new backup because their backups require the specified number of DAYS worth of archived logs for recovery. For example, run:
REPORT NEED BACKUP DAYS = 7 DATABASE; # needs min 7 days of logs to recover REPORT NEED BACKUP DAYS = 30 TABLESPACE SYSTEM; REPORT NEED BACKUP DAYS = 14 DATAFILE 'ora_home/oradata/trgt/tools01.dbf';
INCREMENTAL parameter. If complete recovery of a datafile requires more than the specified number of incremental backups, then RMAN considers it in need of a new backup. For example, enter:
REPORT NEED BACKUP INCREMENTAL = 1 DATABASE; REPORT NEED BACKUP INCREMENTAL = 3 TABLESPACE SYSTEM; REPORT NEED BACKUP INCREMENTAL = 5 DATAFILE 'ora_ home/oradata/trgt/users01.dbf';
| See Also:
Oracle Database Recovery Manager Reference for an explanation of the various column headings in the |
You can report files that are obsolete, that is, superfluous, by specifying the OBSOLETE keyword. If you do not specify any other options, then REPORT OBSOLETE displays the backups that are marked obsolete by the current retention policy. By default, the retention policy is configured to REDUNDANCY of 1.
The REPORT OBSOLETE command supports the RECOVERY WINDOW and REDUNDANCY options at the command level, which have the same meanings as the options with the same names on the CONFIGURE command.
|
Note: As an alternative to running |
To report obsolete backups:
CROSSCHECK commands as needed to update the status of backups. Following is a possible crosscheck session:
# allocate maintenance channel for crosscheck if no channels configured ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt; # checks only on tape CROSSCHECK BACKUP; # crosschecks backup sets and proxy copies on tape RELEASE CHANNEL;
OBSOLETE option to identify which backups are obsolete because they are no longer needed for recovery. For example, enter:
# lists backups that not needed to recover the database to within last week REPORT OBSOLETE RECOVERY WINDOW OF 7 DAYS; # lists backups that are superfluous because more than 2 copies are on tape REPORT OBSOLETE REDUNDANCY = 2 DEVICE TYPE sbt;
ORPHAN option to list unusable backups belonging to an incarnation that is not a direct predecessor of the current incarnation. For example, enter:
REPORT OBSOLETE ORPHAN;
DELETE OBSOLETE. For example, you can enter:
# delete obsolete backups displayed when you issue REPORT OBSOLETE DELETE OBSOLETE; # delete obsolete backups according to a specified recovery window DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS; # delete obsolete backups according to a specified redundancy DELETE OBSOLETE REDUNDANCY = 2;
RMAN prompts for confirmation before actually deleting the files. To suppress the prompt, specify the NOPROMPT option. Specify FORCE to delete the files and remove their repository records regardless of whether the files exist.
See Also:
|
Issue REPORT SCHEMA to list the database files. If you use a recovery catalog, then you also generate historical reports of the database schema at a past time. You do not need a recovery catalog, however, to report the current schema.
To report the database schema at a specified point in time:
REPORT SCHEMA:
REPORT SCHEMA;
If you use a recovery catalog, then you can use the atClause to specify a past time, SCN, or log sequence number:
REPORT SCHEMA AT TIME 'SYSDATE-14'; # schema as it was two weeks ago REPORT SCHEMA AT SCN 1000; # schema as it was at scn 1000 REPORT SCHEMA AT SEQUENCE 100 THREAD 1; # schema as it was at sequence 100
REPORT SCHEMA AT SCN 1000; Report of database schema File K-bytes Tablespace RB segs Datafile Name ---- ------- -------------------- ------- ------------------- 1 307200 SYSTEM YES /oracle/oradata/trgt/system01.dbf 2 20480 UNDOTBS YES /oracle/oradata/trgt/undotbs01.dbf 5 10240 EXAMPLE NO /oracle/oradata/trgt/example01.dbf 6 10240 INDX NO /oracle/oradata/trgt/indx01.dbf 7 10240 TOOLS NO /oracle/oradata/trgt/tools01.dbf 8 10240 USERS NO /oracle/oradata/trgt/users01.dbf
|
 Copyright © 2003 Oracle Corporation All Rights Reserved. |
|