| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-01 |
|
|
View PDF |
| Oracle® Database Backup and Recovery Advanced User's Guide 10g Release 2 (10.2) Part Number B14191-01 |
|
|
View PDF |
The RMAN repository for a database contains extensive records of backups of the database, as well as other useful information such as database schema and configuration settings. You can use RMAN commands LIST, REPORT, and SHOW to access this repository information.
In addition to these general reporting commands, you can also make use of the RESTORE... PREVIEW command to see which backup files are required to restore specific database objects from backup. See Oracle Database Backup and Recovery Basics for more details on RESTORE... PREVIEW.
The LIST command is used to query the RMAN repository and obtain data about:
Backup sets and image copies generated by the RMAN BACKUP command;
Specified objects contained in the BACKUP-generated files, that is, archived logs, datafiles, control files, and server parameter files;
Incarnations of a specified database, or of all databases known to a recovery catalog.
RMAN LIST output is sent either to standard output or to the message log (though not to both at the same time). You can also control how the output is organized as well as the level of detail in the output.
You can also list backups by querying V$BACKUP_FILES and the RC_BACKUP_FILES recovery catalog view. These views provide access to the same information as the LIST BACKUPSET command.
The LIST command displays the same files that the CROSSCHECK and DELETE commands operate on. Consequently, you can issue LIST to see what is in the repository, and then run CROSSCHECK to ensure that these files exist on disk or tape.
|
See Also:
|
RMAN reports are intended to provide analysis of your backup and recovery situation. An RMAN report can answer questions such as:
Which datafiles need a backup?
Which backups are obsolete because they are redundant or because they are not needed for recovery within a recovery window?
Are any datafiles now unrecoverable because they have been the target of unrecoverable operations?
What is the current physical schema of the database, or what was it at some previous time?
RMAN's reporting can be used to monitor and validate your ongoing backup strategy. The REPORT NEED BACKUP and REPORT UNRECOVERABLE commands let you ensure that the necessary backups are available for media recovery, and that you can perform media recovery within a reasonable amount of time.
|
Note: A datafile that does not have a backup is still considered recoverable by RMAN, as long as a complete set of archived redo logs is available, from the time the datafile was created to the present. During recovery, an empty datafile is created, and then all of the changes to the datafile from the archived redo logs are applied to reconstruct the full contents of the file. |
The REPORT OBSOLETE command displays backups of datafiles, control files, and archived redo logs that can be deleted because they are no longer needed. Backups are determined to be obsolete with respect to a retention policy, based either on redundancy or a required recovery window, as described in the following table:
| Retention Policy | Meaning |
|---|---|
REDUNDANCY integer |
At least integer more recent backups of this file already exist. |
RECOVERY WINDOW integer |
The backup is not needed for recovery to any point within the recovery window of integer days. For each datafile, one backup that is older than the recovery window must exist, because point-in-time recovery to the beginning of the recovery window requires must begin with restoring the database from such a backup.
In other words, one backup of each datafile must satisfy the condition |
In addition to obsolete datafile backups, RMAN reports obsolete archived logs and archived log backups. When backups of datafiles from a point in time are obsolete, then archived logs that can only be applied to those datafiles are also no longer needed and become obsolete according to the specified retention policy.
|
Note: Note that if a datafile has never been backed up, then all archived redo logs back to the creation time of the file are required, and none of them are considered obsolete. With a full set of logs, the file can be completely re-created during media recovery. An empty datafile is automatically created during recovery, and the same changes applied to the original datafile after it was created are re-applied to the newly created file. |
By default, the REPORT OBSOLETE commannd reports which files are obsolete under the currently configured retention policy. To generate reports of which files are obsolete according to different retention policies by using REDUNDANCY or RECOVERY WINDOW retention policy options with the REPORT OBSOLETE command. For example, if you run any of these commands:
REPORT OBSOLETE REDUNDANCY 2; REPORT OBSOLETE RECOVERY WINDOW OF 5 DAYS;
RMAN displays backups that are obsolete according to those retention policies, regardless of the actual configured retention policy.
If you disable the retention policy completely (that is, if you run CONFIGURE RETENTION POLICY TO NONE), then RMAN does not consider any backups to be obsolete. If you run REPORT OBSOLETE with no options and no retention policy is configured, then RMAN issues an error message.
You can also query V$BACKUP_FILES and RC_BACKUP_FILES, using the OBSOLETE column to identify backup sets, datafile copies, and archived logs that are obsolete according to the configured retention policy.
If you are managing backup storage yourself instead of using a flash recovery area, then you should run REPORT OBSOLETE regularly to identify backups no longer needed to meet your retention policy, and delete these backups with DELETE OBSOLETE. If you use a flash recovery area, then backups stored there that are obsolete according to the configured retention policy are deleted automatically as space is needed. You do not have to perform DELETE OBSOLETE to reclaim space used for such backups.
