dg修改归档目录 oracle_DG环境下ORACLE自动回收归档空间

当DBA在维护一套物理备库时，应该明白归档文件的重要性，如果某一个归档文件丢失，就需要重新搭建Data Guard。

备用数据库与主库在事务上是一致的，DG利用重做日志来保证这种一致性。当主库发生事务，便会生成重做日志文件到主库本地，之后将重做日志文件传送到备库上，从而保证主从一致。

不管是物理备库还是逻辑备库，都是通过接收来自主库的日志文件来实现同步，只不过逻辑备库是通过将日志文件转化为SQL后应用来实现同步。

这就需要DBA严密关注主库上归档文件的动向。

在生产环境上，通过RMAN将归档文件备份到磁盘/磁带，备份成功之后，删除主库上的归档文件。可以在备份的脚本中使用下图中标记的命令删除已经备份成功的归档文件。

为了减少对DG维护的投入时间，应该尽量让归档文件留在主库磁盘上，所以DBA应该在备份脚本中设置归档保留时间，下图标注命令表示备份3天前的归档文件。

如果备库需要的归档文件在主库中找不到，那么就要从备份里还原备库缺失的归档文件到备库，无疑增加了维护工作量。

说到归档保留时间，对应的需要预算归档空间的大小，如果归档空间容量(disk size)不足以存放实际产生的归档，数据库会因为无法写入归档发生挂起，对于一套实时在线交易系统，这是绝对不允许的。

预测并合理安排备库快速恢复区很重要，首先要确保恢复区能存放备库需要的归档，还要保证在执行主备切换后，备库作为主库能承载所产生的归档。

如何预算备库快速恢复区的大小呢？

假设需要保留一天的归档日志，你就要估算一天之内数据库会产生多少归档，最好是在最繁忙的24小时内计算，一般的月初月末、批量数据处理的时候归档量最大(根据实际环境)。假设这24小时之内归档最大为200G(对于RAC来说是所有节点在24小时内产生的归档量之和)，那么需要准备200+200×20%=240G的空间，并设置参数db_recovery_file_dest_size指定快速恢复区的大小。

明明只有200G的归档容量需求，为什么要准备额外20%的空间？

因为当备库的快速恢复区空间使用率达到80%，ORACLE会自动删除较早的且已经应用到备库的归档，哪怕没有备份这些归档文件，如果所有的归档都没有被应用到备库，那么就不删除，直到数据库因无法写入归档而挂起。

为什么是80%？

MOS文档 ID 1369341.1中有如下的描述

ORACLE往快速恢复区里存放归档文件前，会估算需要的空间大小，然后将这个大小与快速恢复区已使用的空间相加，这两者之和如果超过80%，ORACLE就回收空间(回收的空间大于等于待存文件需要的空间大小)。如果归档没有被应用，此时就不满足回收条件，只能继续使用新的空间，直到快速恢复区被耗尽。

当然这个值是可以人为改变的，如果需要将归档保留足够长的时间，可以通过设置19823事件实现。比如将80%的阀值提高到90%，执行如下命令并重启数据库实例。

alter system  set event='19823 trace name context forever,level 90' scope=spfile  sid='*';

注：经过测试，非DG环境下，归档目录使用率达到80%时，ORACLE不会回收空间。