APPLIES TO:
Oracle Database - Enterprise Edition - Version 9.0.1.4 to 11.2.0.3 [Release 9.0.1 to 11.2]
Oracle Database - Enterprise Edition - Version 12.1.0.1 to 12.1.0.1 [Release 12.1]
Oracle Database - Enterprise Edition - Version 11.2.0.4 to 19.8.0.0.0 [Release 11.2 to 19]
Oracle Database Cloud Schema Service - Version N/A and later
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and later
Information in this document applies to any platform.
PURPOSE
The purpose of this bulletin is to discuss in details about the rman backup retention policy .
SCOPE
ALL DBA
DETAILS
What is a backup retention policy
A retention policy describes which backups will be kept and for how long.You can use the CONFIGURE RETENTION POLICY command to create a persistent and automatic backup retention policy. When a backup retention policy is in effect, RMAN considers backups of datafiles and control files as obsolete, that is, no longer needed for recovery, according to criteria that you specify in the CONFIGURE command. You can then use the REPORT OBSOLETE command to view obsolete files and DELETE OBSOLETE to delete them.
As you produce backups over time, older backups become obsolete as they are no longer needed to satisfy the retention policy. RMAN can identify the obsolete files for you, but it does not automatically delete them. You must use the DELETE OBSOLETE command to delete files that are no longer needed to satisfy the retention policy.
If you have a flash recovery area configured, however, then the database automatically deletes unnecessary files from the flash recovery area based on its internal disk quota rules.磁盘紧张时才会删除
The disk quota rules are distinct from the backup retention policy rules, but the database will never delete files in violation of the retention policy to satisfy the disk quota.
The term obsolete does not mean the same as expired. A backup is obsolete when REPORT OBSOLETE or DELETE OBSOLETE determines, based on the user-defined retention policy, that it is not needed for recovery. A backup is considered expired only when RMAN performs a crosscheck and cannot find the file. In short, obsolete means "not needed," whereas expired means "not found."
From the perspective of a retention policy, a datafile backup is a full or level 0 backup of an individual datafile or control file. It does not matter whether the backup is a datafile image copy, a proxy copy, or part of a backup set. For datafile copies and proxy copies, if RMAN determines that the copy or proxy copy is not needed, then the copy or proxy copy can be deleted. For datafile backups in backup sets, RMAN cannot delete the backup set until all of the individual datafile backups within the backup set are obsolete. 删除的原子性
Besides affecting full or level 0 datafile and control file backups, the retention policy affects archived redo logs and level 1 incremental backups. First, RMAN decides which datafile and control file backups are obsolete. Then, RMAN considers as obsolete all archived logs and incremental level 1 backups that are not needed to recover the oldest datafile or control file backup that must be retained.
Types of backup retention policies:
There are two mutually exclusive options for implementing a retention policy: redundancy and recovery window. If no retention policy is configured by the user, then the REPORT OBSOLETE andDELETE OBSOLETE commands use a default retention policy of REDUNDANCY 1.
To configure a retention policy based on a recovery window, use the following command:
RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF x DAYS;
To configure a retention policy based on redundancy, use the following command:
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY x;
You can also disable the retention policy completely, meaning that RMAN does not consider any backup to be obsolete. To do so, use the following command:
RMAN> CONFIGURE RETENTION POLICY TO NONE;
Recovery Window
A recovery window is a period of time that begins with the current time and extends backward in time to the point of recoverability. The point of recoverability is the earliest time for a hypothetical point-in-time recovery, that is, the earliest point to which you can recover following a media failure. For example, if you implement a recovery window of one week, then this window of time must extend back exactly seven days from the present so that you can restore a backup and recover it to this point. You implement this retention policy as follows:
Assume the following retention policy illustrated in EXAMPLE.
# The recovery window is 7 days.
# Database backups are scheduled every two weeks on these days:
# January 1
# January 14
# January 28
# The database runs in ARCHIVELOG mode, and archived logs are saved on disk only as long as needed for the retention policy.
+ January 1 --------> Log seq 100 ---------> BACKUP
+ January 7 --------> Log seq 250
+ January 14 --------> Log seq 500 ---------> BACKUP
+ January 21 --------> Log seq 750
+ January 28 --------> Log seq 900 ---------> BACKUP
Lets assume the current time is January 23
Since the current time is Jan 23 according to restention policy of 7 days , the point of recoverability will be Jan 16
As illustrated in example the current time is January 23 and the point of recoverability is January 16. Hence, the January 14 backup is needed for recovery, and so are the archived logs from log sequence 500 through 850（850哪来的，直接说500后吧）. The logs before 500 and the January 1 backup are obsolete because they are not needed for recovery to a point within the window.
Recovery window is not the number if days upto which the backups are valid . It is period of time that begins with the current time and extends backward in time to the point of recoverability.
不是说7天就是7，要结合0或者full backup
NOTE
=====
You should keep the recovery window time period less than or equal to the value of the control file parameter CONTROL_FILE_RECORD_KEEP_TIME to prevent the record of older backups from being overwritten in the control file.
Backup Redundancy
A redundancy-based retention policy specifies how many backups of each datafile must be retained. For example, you can specify:
RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 2;
Although the recovery window is the best practice for specifying a retention policy, it can complicate disk space usage planning because the number of backups that must be kept by the recovery window is not constant and depends on the backup schedule.磁盘不好估计
Use the CONFIGURE RETENTION POLICY TO REDUNDANCY n command to implement a retention policy that maintains a constant number of backups of each datafile. RECOVERY WINDOW and REDUNDANCY-based retention policies are mutually exclusive.
The default retention policy is REDUNDANCY = 1, to maintain compatibility with the behavior of REPORT OBSOLETE in earlier RMAN releases. You can also run the following command to disable the retention policy altogether:
RMAN> CONFIGURE RETENTION POLICY TO NONE;
If the retention policy is configured to NONE, then REPORT OBSOLETE and DELETE OBSOLETE do not consider any backups to be obsolete
Batch Deletes of Obsolete Backups
Run the REPORT OBSOLETE command to determine which backups are currently obsolete according to the retention policy.
If you configure the retention policy to NONE, then RMAN does not consider any backups as obsolete. Consequently, RMAN issues an error when you run REPORT OBSOLETE without any other options and the retention policy is set to NONE.
A companion command, DELETE OBSOLETE, deletes all files which are obsolete according to the retention policy. You should run DELETE OBSOLETE periodically to minimize space wasted by storing obsolete backups. For example, you can run DELETE OBSOLETE in a weekly script.
You can also specify the REDUNDANCY or RECOVERY WINDOW options on the REPORT or DELETE commands, to overrride the configured retention policy.
The REPORT OBSOLETE and DELETE OBSOLETE commands work in two steps:
For each datafile for which there are full backup, datafile copy, or level 0 incremental backups, RMAN identifies the oldest full or level 0 backup or copy that is not obsolete under the retention policy being tested. Any full backup, level 0 incremental backup, or datafile copy of a datafile older than the one identified in this step is considered obsolete.
Any archived logs and level 1 incremental backups that are older than the oldest non-obsolete full backup are then obsolete because there is no full or level 0 backup to which they can be applied.
1级和archivelog由最旧的0级备份决定需不需要
Exempting Backups from the Retention Policy
You may want to store a long-term backup, potentially offsite, for much longer than the time dictated by the retention policy. For example, you may make a database backup on the first day of every year to satisfy some regulatory requirement, independent of backups taken for your ongoing backup and recovery strategy.
Such long-term backups should be recorded in the RMAN repository, but they must be exempted from the retention policy because RMAN would quickly consider them obsolete, and they would be removed the next time the DELETE OBSOLETE command is used.
You can exempt a backup from the retention policy by using the KEEP option with the BACKUP command when you create the backup, or the KEEP option of the CHANGE command to exempt an existing backup. Note that backups exempted from the retention policy are still fully valid backups, which can be used in restore and recovery operations like any other if RMAN judges them to be the best choice available.
You can change the exempt status of a backup using the CHANGE... KEEP and CHANGE... NOKEEP commands. The NOKEEP option (default) indicates that the backup is not immune from the configured retention policy.
You can specify the LOGS option to save archived logs for a possible incomplete recovery of the long-term backup. When LOGS is specified, all logs more recent than the backup are kept as long as the backup is kept. In other words, KEEP UNTIL TIME... LOGS means that RMAN will keep all logs required to recover the backup as long as the backup is kept. If you specify NOLOGS, then RMAN does not keep the logs required to recover the backup. Note that if you use KEEP UNTIL TIME... with an inconsistent backup, you must use the LOGS option, or that backup will become unusable when the logs required to recover it are deleted as obsolete.
这是从keep的backup开始apply log，少一个log都不行
You can specify an end date using the UNTIL clause, or either specify that the backup should be kept FOREVER. If you specify UNTIL, then RMAN will not mark the backup as obsolete until after the UNTIL date has passed. Note that it is an error to specify KEEP FOREVER with the LOGS option, as this would require keeping all redo logs forever.
The following commands are examples of long-term backups:
# Creates a backup and exempts it from retention policy until last day of 2007
RMAN> BACKUP DATABASE KEEP UNTIL TIME "TO_DATE('31-DEC-2007', 'dd-mon-yyyy')" NOLOGS;
# Specifies that backupset 2 is no longer exempt from the retention policy
RMAN> CHANGE BACKUPSET 2 NOKEEP;
# Creates a backup that is indefinitely exempt from the retention policy
RMAN> BACKUP TABLESPACE users KEEP FOREVER NOLOGS;
Note:
-----
From 11g onward behaviour is changing for KEEP ... -> 'LOGS' no longer needed
For more details and reference Please see
keepOption
.
Oracle® Database Backup and Recovery Reference
11g Release 2 (11.2)
E10643-07
.
keepOption
.
Relationship Between Retention Policy and Flash Recovery Area Rules
The RMAN status OBSOLETE is always determined in reference to a retention policy. For example, if a database backup is OBSOLETE in the RMAN repository, it is because it is either not needed for recovery to a point within the recovery window, or it is redundant.
If you configure a flash recovery area, then the database uses an internal algorithm to select files in the flash recovery area that are no longer needed to meet the configured retention policy. These backups have status OBSOLETE, and are eligible for deletion to satisfy the disk quota rules.
There is one important difference between the flash recovery area criteria for OBSOLETE status and the disk quota rules for deletion eligibility. Assume that archived logs 1000 through 2000, which are on disk, are needed for the currently enabled recovery window and so are not obsolete. If you back up these logs to tape, then the retention policy still considers the disk logs as required, that is, not obsolete. Nevertheless, the flash recovery area disk quota algorithm considers the logs on disk as eligible for deletion because they have already been backed up to tape.
The logs on disk do not have OBSOLETE status in the repository, but they are eligible for deletion by the flash recovery area. Note, though, that the retention policy is never violated when determining which files to delete from the flash recovery area to satisfy the disk quota rules.
两个算法不同，备份到磁带的可以被FRA策略删除。