Backup Retention Policies

导读：

　　You can use the CONFIGURERETENTIONPOLICYcommand 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 CONFIGUREcommand. You can then use the REPORTOBSOLETEcommand to view obsolete files and DELETEOBSOLETEto 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 DELETEOBSOLETEcommand 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 REPORTOBSOLETEor DELETEOBSOLETEdetermines, 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, obsoletemeans "not needed," whereas expiredmeans "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.

　　 Note:

　　RMAN cannot implement an automatic retention policy if backups are deleted by non-RMAN methods, for example, through the media manager's tape retention policy. The media manager should never expire a tape until all RMAN backups on that tape have been removed from the media manager's catalog.

　　There are two mutually exclusive options for implementing a retention policy: redundancyand recovery window. If no retention policy is configured by the user, then the REPORT OBSOLETEandDELETE OBSOLETEcommands use a default retention policy of REDUNDANCY 1.

　　To configure a retention policy based on a recovery window, use the following command:

　　CONFIGURERETENTIONPOLICYTORECOVERYWINDOW

　　To configure a retention policy based on redundancy, use the following command:

　　CONFIGURERETENTIONPOLICYTOREDUNDANCY

　　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:

　　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:

　　CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

　　This command ensures that for each datafile one backup that is older than the point of recoverability must be retained. For example, if the recovery window is 7, then there must always exist one backup of each datafile that satisfies the following condition:

　　SYSDATE - BACKUP CHECKPOINT TIME >= 7

　　All backups older than the most recent backup that satisfied this condition are obsolete.

　　Assume the following retention policy illustrated in Figure 2-6. The retention policy has the following aspects:

　　The recovery window is 7 days.

　　Database backups are scheduled every two weeks on these days:

　　January 1

　　January 15

　　January 29

　　February 12

　　The database runs in ARCHIVELOGmode, and archived logs are saved on disk only as long as needed for the retention policy.

　　 Figure 2-6 Recovery Window, Part 1

　　Description of "Figure 2-6 Recovery Window, Part 1"

　　As illustrated in Figure 2-6, 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. The logs before 500 and the January 1 backup are obsolete because they are not needed for recovery to a point within the window.

　　Assume the same scenario a week later, as depicted in Figure 2-7.

　　 Figure 2-7 Recovery Window, Part 2

　　Description of "Figure 2-7 Recovery Window, Part 2"

　　In this scenario, the current time is January 30 and the point of recoverability is January 23. Note how the January 14 backup is notobsolete even though a more recent backup (January 28) exists in the recovery window. This situation occurs because restoring the January 28 backup does not enable you to recover to the earliest time in the window, January 23. To ensure recoverability to any point within the window, you must save the January 14 backup as well as all archived redo logs from log sequence 500 to 1150.

　　 Backup Redundancy

　　A redundancy-based retention policy specifies how many backups of each datafile must be retained. For example, you can specify:

　　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 CONFIGURERETENTIONPOLICYTOREDUNDANCYncommand to implement a retention policy that maintains a constant number of backups of each datafile. RECOVERYWINDOWand REDUNDANCY-based retention policies are mutually exclusive.

　　The default retention policy is REDUNDANCY=1, to maintain compatibility with the behavior of REPORTOBSOLETEin earlier RMAN releases. You can also run the following command to disable the retention policy altogether:

　　CONFIGURE RETENTION POLICY TO NONE;

　　If the retention policy is configured to NONE, then REPORTOBSOLETEand DELETEOBSOLETEdo not consider any backups to be obsolete.

　　 Batch Deletes of Obsolete Backups

　　Run the REPORTOBSOLETEcommand 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 REPORTOBSOLETEwithout any other options and the retention policy is set to NONE.

　　A companion command, DELETEOBSOLETE, deletes all files which are obsolete according to the retention policy. You should run DELETEOBSOLETEperiodically to minimize space wasted by storing obsolete backups. For example, you can run DELETEOBSOLETEin a weekly script.

　　You can also specify the REDUNDANCYor RECOVERYWINDOWoptions on the REPORTor DELETEcommands, to overrride the configured retention policy.

　　The REPORTOBSOLETEand DELETEOBSOLETEcommands 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.

　　 See Also:to generate reports and delete backupsfor DELETEsyntaxfor REPORTsyntax

　　 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 DELETEOBSOLETEcommand is used.

　　You can exempt a backup from the retention policy by using the KEEPoption with the BACKUPcommand when you create the backup, or the KEEPoption of the CHANGEcommand 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... KEEPand CHANGE... NOKEEPcommands. The NOKEEPoption (default) indicates that the backup is not immune from the configured retention policy.

　　You can specify the LOGSoption to save archived logs for a possible incomplete recovery of the long-term backup. When LOGSis specified, all logs more recent than the backup are kept as long as the backup is kept. In other words, KEEP UNTIL TIME...LOGSmeans 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 LOGSoption, or that backup will become unusable when the logs required to recover it are deleted as obsolete.

　　You can specify an end date using the UNTILclause, 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 UNTILdate has passed. Note that it is an error to specify KEEP FOREVERwith the LOGSoption, 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

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

CHANGE BACKUPSET 2 NOKEEP;

# Creates a backup that is indefinitely exempt from the retention policy

BACKUP TABLESPACE users KEEP FOREVER NOLOGS;

　　 See Also:for CHANGEsyntax

　　 Relationship Between Retention Policy and Flash Recovery Area Rules

　　The RMAN status OBSOLETEis always determined in reference to a retention policy. For example, if a database backup is OBSOLETEin 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 OBSOLETEstatus 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 OBSOLETEstatus 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.

本文转自

http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmconc1007.htm

Backup Retention Policies相关推荐

InfluxDB学习之InfluxDB数据保留策略（Retention Policies）
InfluxDB每秒可以处理成千上万条数据,要将这些数据全部保存下来会占用大量的存储空间,有时我们可能并不需要将所有历史数据进行存储,因此,InfluxDB推出了数据保留策略(Retention Po ...
053试题 181/182/183/558/600/608/631/636/657/661/664/668/670/696 - RMAN backup
题目: 181.Your database has a backup that was taken yesterday (Tuesday) between 13:00 and 15:00 hours. ...
windows版influxDB安装与配置
一.下载链接https://portal.influxdata.com/downloads,选windows版二.解压到安装盘,目录如下三.修改conf文件,代码如下,直接复制粘贴(1.4.2版本 ...
Influxdb安装、启动influxdb控制台、常用命令、Influx命令使用、Influx-sql使用举例、Influxdb的数据格式、Influxdb客户端工具
目录: Influxdb安装 1 1.1. Influxdb下载 2 1.2. 解压tar包 2 1.3. 修改配置文件 2 1.4. 配置文件参数说明 3 1.5. 实际配置(主要是修改路径和端口) ...
influxDB框架数据存储 TSM 数据操作等详解
文章目录 influxdb influxdata主目录结构源码主目录结构 cmd目录其他目录数据操作 CLI--influx命令行操作执行influx 创建数据库查看数据库使用数据库数据 ...
sql 备份文件大小_预测SQL备份大小
sql 备份文件大小 This article will cover the process of analyzing and predicting/forecasting the size of ...
azure 入门_Azure SQL数据库入门
azure 入门 In this article, we will uncover the basics of the Azure SQL Database. 在本文中,我们将揭示Azure SQL数 ...
azure备份存储层分类_如何配置Azure SQL数据库长期保留（LTR）备份
azure备份存储层分类 In this article, we will review default backup settings, long-term retention (LTR) back ...
时序数据库 InfluxDB
目录一.介绍二.安装三.inflxudb保留字四.基本语法 1.客户端操作 1. 数据库操作 2. 数据表和数据操作 3. series 操作 4.Shard 5. 用户操作 2.API操作 ...

Backup Retention Policies

Backup Retention Policies相关推荐

最新文章

热门文章