rman 0级 1级备份结合的注意事项 obsolete 和 FRA自动清理

1. 当心0级备份从controlfile中删除，0级备份决定recover windows时间 ，一级不算

Incremental backup cycle:

Sundays:        Level 0
Monday-Sat:  cumulative level 1

Every Friday and Saturday, the time for the incremental level 1 backup suddenly increases and results in a much larger backuppiece being generated.  The usual backuppiece size is around 200 MB, but on Friday and Saturday it is around 800 MB despite the fact that there is no extra activity on thedatabase during these days. The archive log generation is the same as on previous days.

CAUSE
In general, an RMAN incremental backup is based on the checkpoint scn of the previous incremental backup or the previous level 0 backup if this is a cummulative backup.    If no level 0 backup is found, then any existing incrementals become useless as an incremental without a baseline level 0 cannot be applied.  In such a situation, the next incremental will be based on the file creation scn ie
ALL blocks changed since file creation will be backed up.   So where an incremental backup strategy is deployed,  the backup metadata for the complete cycle (starting from level 0 backup) must be maintained in the rman repository.

Level 0 backups will be  removed prematurely from the rman repository under the following circumstances:

a. explicit deletion of the level 0 backups , ignoring retention policy
b. copy of rman backups to tape then  deletion from disk followed by crossheck/delete expired
c. if a catalog is NOT used, level 0 backup metadata may age out of the controlfile (only likely if the level 0s are taken very infrequently)

(a) and (b) are common practices where backups are written to disk first  and space is at a premium - this is fine as long as the backup metada remains untouched in the RMAN repository.

To confirm if the backup metadata is missing: 

a. RMAN>list backup of database;
    
    Look for the absence of level 0 backups for the present backup cycle

b. Query v$backup_datafile:

    SQL> set lines 400
    SQL> alter session set nls_date_format='dd-mon-rr hh24:mi:ss';
    SQL> select recid, file#, to_char(creation_change#)crscn,
                incremental_level lvl, to_char(incremental_change#) incrscn, 
                to_char(checkpoint_change#) ckpscn, checkpoint_time ckptime,
                completion_time endtime, USED_CHANGE_TRACKING bct, 
                blocks_read  read, block_size bsz, blocks wrtn 
         from v$backup_datafile
         where file# > 0
           and  completion_time > '<date>';

     Look for datafile backups where incremental_change#=creation_change
         
          Sample output (edited):

recid   File# crscn  Lvl   incr_change#    ckp change#
------  ----- ------ ----- -------------   -----------------
61888    1       5    0                0   6066791848649
61975    1       5    1    6066791848649   6067000893725
62073    1       5    1    6066791848649   6067362932086
62179    1       5    1    6066791848649   6067740524868
62280    1       5    1    6066791848649   6068546799488
62393    1       5    1                5   6069467166501
   For the backup with recid 62393, the backup was based on scn 5, which is the file creation scn.

SOLUTION

Do not use an explicit DELETE command to remove any backups belonging to current backup cycle.
When copying backups from disk to tape and then deleting them from disk, do not run crossheck/delete expired commands as this will remove the corresponding backup metadata.

To maintain the backup metadata correctly:

set a retention policy to match your incremental backup cycle and use delete force obsolete 

RMAN> configure retention policy to recovery window of 7 days;
RMAN> delete force obsolete;

 .  using 'DELETE OBSOLETE' ensures only backups outside your retention policy will be deleted , the backup metadata for the current incremental cycle will be preserved
 . using 'FORCE' tells rman to ignore any io errors (when the OS reports that the backuppiece does not
    exist)

If you are not using a catalog ensure that CONTROL_FILE_RECORD_KEEP_TIME is set to your recovery window +1.
    
     

可以使用CONFIGURE RETENTION POLICY命令来创建一个持续的和自动备份保留策略。

当备份保留策略生效时，RMAN根据CONFIGURE命令指定的标准将数据文件或控制文件的备份视为过期的备份，也就是说，恢复时不再需要的备份。可以使用REPORT OBSOLETE命令来查看过期的文件和DELETE OBSOLETE命令来删除它们。

当随着时间的过去产生备份，旧的备份会变成过期的，因为它们不再需要来满足保留策略。RMAN可以识别过期的文件，但它不会自动删除它们。必须使用DELETE OBSOLETE命令来删除不再需要来满足保留策略的文件。

如果配置了快速恢复区域，那么当需要为新文件准备更多的恢复区域空间时，数据库自动删除过期或已经备份到磁带的文件。磁盘配额规则与保留策略规则不同，但数据库不会违反保留策略删除文件来满足磁盘配额。

REPORT OBSOLETE或DELETE OBSOLETE基于用户定义的保留策略，即它不需要用来恢复来决定备份是过期的。只有当RMAN执行交叉检查和不能找到文件时，备份被视为失效的（expired）备份。简而言之，过期（obsolete）意味着文件不需要，而失效（expired）意味着它不能被找到。

备份保留策略只应用到完全或级别0的数据文件和控制文件备份。对于数据文件拷贝和代理拷贝，如果RMAN决定拷贝或代理拷贝不需要，那么拷贝或代理拷贝可以被删除。对于数据文件的备份集，RMAN不能删除备份集直到备份集中的所有数据文件备份都已过期为止。

保留策略不负责删除或使归档redo日志和级别1的增量备份过期。而是，当没有需要它们的完全备份存在时，这些文件变成过期的。除了影响完全或级别0的数据文件和控制文件备份外，备份保留策略也影响归档redo日志和级别1的增量备份。首先，RMAN决定哪些数据文件和控制文件备份是过期的。然后，RMAN将所有不需要用来恢复必须保留的最旧的数据文件或控制文件备份的归档日志和级别1的增量备份视为过期的。

注：如果备份被非RMAN的技术删除，RMAN不能执行自动保留策略，例如，通过介质管理器的磁带保留策略。介质管理器必须永不失效一个磁带直到磁带上的所有RMAN备份已经从介质管理器的目录（catalog）中删除。

执行保留策略时有两个相互排斥的选项：冗余度和恢复窗口。

1．关于恢复窗口
恢复窗口是以当前时间开始在时间上向后延伸到可恢复点的时间段。可恢复点是假设的时间点恢复（TIPR）的最早的时间，即是在介质故障之后可以恢复的最早时间点。

例如，如果执行恢复窗口为1周，那么RMAN保留完全备份和要求的增量备份和归档日志，这样数据库可以恢复到过去的7天内。执行如下的保留策略：
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

这个命令确保对于每个数据文件，比可恢复时间点更旧的一个备份会被保留。例如，如果恢复窗口是7，那么每个数据文件必须总是存在一个备份满足以下条件：
SYSDATE - BACKUP CHECKPOINT TIME >= 7

所有比最近的满足这个条件的备份更旧的备份都是过期的。

假设保留策略如下图所示：

保留策略有以下方面：
1） 恢复窗口是7天。
2） 数据库备份每两周安排一次，在这些日期：1月1日，1月15日，1月29日，2月12日。
3） 数据库运行在ARCHIVELOG模式，如果保留策略需要，归档日志只保存在磁盘上。

如Figure 8-4所示，当前时间是1月23日，可恢复时间点是1月16日。因此，1月15日的备份需要用来恢复，从log序列500到850的归档日志也是如此。在500之前的日志和1月1日的备份是过期的，因为它们不需要用来恢复到窗口期内的时间点。

-----就算15-22之间有增量1级备份，15的0级也是需要的，RECOVERY WINDOW OF 7 DAYS 只看0级备份的时间！！

假设相同的场景持续一周后，如下图所示：

在这个场景中，当前的时间是1月30日，可恢复时间点是1月23日。注意1月15日的备份如何没有过期即使一个更近的备份（1月29日）存在于恢复窗口期内。这个情况发生是因为还原1月29日的备份不能让你恢复到窗口内最早的时间，1月23日。为了确保窗口期内的任何时间点的可恢复性，必须保留1月15日的备份和从序列500到1150的所有归档日志。

-----0级备份需要保留最长时间是RECOVERY WINDOW+0级备份间隔时间，即使每周0级备份可能是14天的保留时间。

2．关于备份冗余度
在某些情况中，使用恢复窗口会复杂化磁盘空间规划，因为必须保留的备份的数量不是恒定的，取决于备份的时间表。相反，基于冗余度的保留策略指定每个数据文件必须保留多少个备份。

例如，可以配置冗余度为2，如下：
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

缺省的保留策略配置为REDUNDANCY 1。

3．关于批量删除过期的备份
可以运行REPORT OBSOLETE命令根据保留策略来确定哪些备份当前是过期的。

一个成对的命令，DELETE OBSOLETE删除所有根据保留策略是过期的文件。可以定期运行DELETE OBSOLETE命令来最小化存储过期备份的空间浪费。例如，可以在每周的脚本中运行DELETE OBOSOLETE。

也可以通过在REPORT或DELETE命令中指定REDUNDANCY或RECOVERY WINDOW选项来覆盖配置的保留策略。使用DELETE OBSOLETE可配置比恢复窗口更短的恢复窗口选项来减少可恢复的窗口。例如，如果配置的窗口是14天，但你执行DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS，那么你不再有能力恢复到7天和14天之前之间的时间点。

4．关于备份保留策略和快速恢复区域删除规则
如果配置了快速恢复区域，那么数据库使用内部的算法来选择快速恢复区域中不再需要的文件来满足配置的保留策略。

当决定哪些文件从快速恢复区域中删除来满足磁盘配额规划时，保留策略决不会被违反。这些状态是OBSOLETE的备份才符合删除的条件来满足磁盘配额规则。

RMAN的状态OBSOLETE总是根据保留策略来决定的。例如，如果数据库备份在RMAN仓库中被视为OBSOLETE，那么它是因为不需要用来恢复到恢复窗口期内的时间点或者它是冗余的。

在快速恢复区域的OBSOLETE状态的规则和磁盘配额符合删除条件的规则之间有着重要的不同。假设归档日志在磁盘上，被当前的恢复窗口所需要，因此不是过期的。如果备份这些日志到磁带，那么保留策略将这些磁盘日志视为需要的，即是没有过期的。然而，快速恢复区域磁盘配额算法将磁盘上的日志视为符合删除的条件，因为它们已经备份到了磁带。磁盘上的日志在RMAN仓库中的状态不是OBSOLETE，但它们符合快速恢复区域的删除条件。
 

------上文说了不会删除，这边又说如果备份到磁带了也是可以删除的，但同时也是-------在RMAN仓库中的状态不是OBSOLETE，但它们符合快速恢复区域的删除条件！！！！

这种文件比较困惑，就是没有rman命令可以删 ，oracle内部可以删；当然rm可以删，删完crosscheck

  list backup of archivelog all;

如果配置了快速恢复区域，那么当需要为新文件准备更多的恢复区域空间时，数据库自动删除过期或已经备份到磁带的文件。磁盘配额规则与保留策略规则不同，但数据库不会违反保留策略删除文件来满足磁盘配额。

 CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO SBT;

CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO disk;