DG 归档管理
搭建过dg的同窗确定很是清楚归档日志和备份的重要性，这些归档日志从主库传输到备库，在备库被apply。linux
思考一个问题：主库的归档日志是怎么管理呢，备库的归档又该怎么管理呢？数据库
在11g里面，随着ASM、RAC、Data Guard（包括Active Data Guard）的成熟，使用RAC+ASM+Data Guard愈来愈成为一种可靠的、维护简单、稳定的高可用性和容灾保护方案。这篇文章谈谈如何管理Oracle 11g Data Guard环境中的归档日志。app
归档日志是重要的，否则就没必要提到这篇文章，备份恢复须要它，而Data Guard也须要它。在早期版本的Data Guard环境中，经常面临着归档日志管理问题。在Data Guard环境里面，对归档日志管理须要达到如下几个方面的要求或者说是需求：测试
- 不可以随意删除掉归档日志，归档日志丢失会致使Data Guard须要从新搭建。
- 不能随意使用RMAN删除归档日志，不然一样会致使Data Guard须要从新搭建。
- 在使用RMAN备份后，若是归档没有被传送或应用到备库上，那么RMAN不该该删除归档日志，不然Data Guard须要的归档就必须从备份里面还原出来，增长了维护工做量。
- 对RMAN的备份脚本没有特别的要求，不然脚本意外改动，可能会致使Data Guard须要的归档日志被删除。
- 归档应尽可能保存在磁盘上，以免Data Guard长时间维护时归档被删除。
- 备库的归档日志不须要花精力去维护，自动删除已经应用过的归档日志。
幸运的是，在11g环境里面，上述的几点很容易就知足，那就是只须要作到如下几点。spa
- 使用快速恢复区(fast recovery area)，在10g版本的文档中称为闪回恢复区（flash recovery area），老实说，一直不太明白为何取名叫闪回恢复区，难道是由于10g有了数据库闪回功能？在RAC中，毫无疑问快速恢复区最好是置放在ASM上。
- 为快速恢复区指定合适的空间。首先咱们须要预估一个合理的归档保留时间长。好比因为备份系统问题或Data Guard备库问题、维护等，须要归档保留的时间长度。假设是24小时，再评估一下在归档量最大的24小时以内，会有多少许的归档？通常来讲是在批量数据处理的时候归档量最大，假设这24小时以内归档最大为200G。注意对于RAC来讲是全部节点在这24小时的归档量之和。最后为快速恢复区指定须要的空间量，比经过参数db_recovery_file_dest_size指定快速恢复区的大小。这里一样假设快速恢复区们存放归档日志。
- 在备库上指定快速恢复区以及为快速恢复区指定合适的大小，在备库上指定快速恢复区的大小主要考虑的是：切换成为主库后归档日志容量；若是主库归档容量压力大，备库可否存储更多的归档日志以即可以经过备库来备份归档日志。
- 对主库和备份使用RMAN配置归档删除策略：CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
- 在主备库 须要指定归档路径为快速恢复区，这样才好让rman来管理闪回区，log_archive_dest_size_1='location=USE_DB_RECOVERY_FILE_DEST'
完成了上述几个步骤，那么归档管理的要求基本上就达到了。经过这样的设置，实现的效果以下：日志
- 归档日志若是没有应用到备库，那么在RMAN中使用backup .... delete inputs all和delete archivelog all不会将归档日志删除。但可是请注意若是是使用delete force命令则会删除掉归档，无论归档有没有被应用到备库。
- 若是归档日志已经应用到了备库，那么在RMAN中使用backup .... delete inputs all和delete archivelog all能够删除归档日志，在正常状况下，因为归档日志可能很快应用到Data Guard，因此在RMAN备份以后能够正常删除归档日志。RMAN也不须要使用特别的备份脚本，也没必要担忧人为不当心使用。delete archivelog all命令删除了归档。
- 备库的归档日志存储到快速恢复区中，备库的快速恢复区空间紧张时，会自动删除已经应用过的较早的归档日志以释放空间，这样即可以实现备库的归档日志彻底自动管理。
- 若是因为备份异常或Data Guard异常，在快速恢复区空间紧张时，Oracle在切换日志时，会自动删除掉已经应用过的归档日志，以释放空间。可是若是归档日志没有应用到Data Guard，那么归档日志不会被删除。这种状况下，快速恢复区的归档可能会增长到空间耗尽，最后就会出现数据库不能归档，数据库挂起的问题。
注意上面最后一点，当快速恢复区空间紧张时，Oracle开始删除归档日志，删除的条件还包括归档日志已经应用到备库，这种状况下若是归档日志尚未备份，也会被删除掉。这里的问题是，文档中描述的快速恢复区空间紧张，具体是指什么时间？也就是快速恢复区的空间消耗多少百分比的时候才算是空间紧张？在MOS文章《Files being deleted in the flash recovery area, messages in the alert log Deleted Oracle managed file <filename> (Doc ID 1369341.1)》里面有提到，空间使用率达到80%之后就开始删除文件（归档日志）。code
Oracle在往快速恢复区存储文件时，其步骤大概是这样的：Oracle估计须要的空间大小（切换日志时就是归档日志大小），而后将这个大小与当前的占用空间大小相加，看是否超过了80%，若是超过了，那么就回收空间（回收的空间应大于等于新建文件须要的空间大小，也就是回收的空间以够用为原则）。若是不能回收空间（好比归档日志没有被应用到备库），那就只能继续占用新的空间，直到空间耗尽。事件
这里的问题是，假设快速恢复区设定了200G空间，那么在使用到80%，也就是160G的时候就开始回收空间。那么咱们在估算空间时，就应该上浮20%。好比咱们要求保留24小时归档，这24小时以内归档量最大是200G，那么咱们应该为快速恢复区设置240G左右的容量。文档
那么，这个80%的比率可以更改吗以便延迟Oracle删除归档日志的时间吗？答案是确定的。没有相应的数据库参数来设定，可是能够经过事件来设置，事件号是19823：get
- oerr ora 19823
- 19823, 00000, "soft limit recovery area space pressure percentage"
- // *Document: NO
- // *Cause: Set on all instances to alter recovery area space pressure
- // trigger percentage.
- // *Action: level 1 to 100 indicates the percentage when the space
- // pressure has to be triggered.
下在是一个测试：
测试环境：主库是Oracle 11.2.0.3 for Linux两节点RAC，备库是Oracle 11.2.0.3 for linux单实例库。测试是在主库的节点1上进行的，其在线日志大小为512MB，快速恢复区指定的大小为16GB。
当前主库的FRA（快速恢复区）的使用率已经接近于80%：
select * from V$RECOVERY_AREA_USAGE; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES -------------------- ------------------ ------------------------- --------------- CONTROL FILE 0 0 0 REDO LOG 15.33 0 13 ARCHIVED LOG 64.04 63.81 45 BACKUP PIECE .24 0 1 IMAGE COPY 0 0 0 FLASHBACK LOG 0 0 0 FOREIGN ARCHIVED LOG 0 0 0
发现FRA（快速恢复区）的空间使用率基本上在80%左右。alert日志也有相应的删除较早的归档日志的信息：
- Thu Jan 02 12:28:50 2014
- Thread 1 advanced to log sequence 981 (LGWR switch)
- Current log# 12 seq# 981 mem# 0: +DATA1/ractest/onlinelog/group_12.299.835542549
- Current log# 12 seq# 981 mem# 1: +DG_FLA/ractest/onlinelog/group_12.298.835542551
- Thu Jan 02 12:28:50 2014
- LNS: Standby redo logfile selected for thread 1 sequence 981 for destination LOG_ARCHIVE_DEST_2
- Thu Jan 02 12:28:50 2014
- Deleted Oracle managed file +DG_FLA/ractest/archivelog/2014_01_02/thread_2_seq_309.424.835783855
- Deleted Oracle managed file +DG_FLA/ractest/archivelog/2014_01_02/thread_1_seq_947.426.835783855
- Deleted Oracle managed file +DG_FLA/ractest/archivelog/2014_01_02/thread_1_seq_948.437.835784237
- Archived Log entry 2645 added for thread 1 sequence 980 ID 0xc8804744 dest 1:
上面的日志也能够看到其过程是：切换日志；删除不须要的最老的归档日志；生成新的归档日志。
如今咱们利用事件19823将这个比率调到95%看看会是什么样子：
SQL> alter system set event='19823 trace name context forever,level 95' scope=spfile sid='*';
而后重启主库。再运行上面的测试代码，发现Oracle再也不删除归档日志，而是到接近95%的空间使用率时再开始删除归档日志：
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES -------------------- ------------------ ------------------------- --------------- CONTROL FILE 0 0 0 REDO LOG 15.33 0 13 ARCHIVED LOG 68.99 65.72 49 BACKUP PIECE .24 0 1 IMAGE COPY 0 0 0 FLASHBACK LOG 0 0 0 FOREIGN ARCHIVED LOG 0 0 0 ............. FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES -------------------- ------------------ ------------------------- --------------- CONTROL FILE 0 0 0 REDO LOG 15.33 0 13 ARCHIVED LOG 78.62 59.9 55 BACKUP PIECE .24 0 1 IMAGE COPY 0 0 0 FLASHBACK LOG 0 0 0 FOREIGN ARCHIVED LOG 0 0 0
从上面的最后一次对v$recovery_area_usage的查询数据能够看到，此时空间利用率达到了94.19%，离95%已经很接近（在线日志的大小是512MB，占快速恢复区的3.1%，若是在快速恢复区里面多一个文件就会超过95%）。
接下来咱们将这个比率调整到50%，看看是什么结果：
SQL> alter system set event='19823 trace name context forever,level 50' scope=spfile sid='*';
而后重启主库。再运行上面的测试代码，发现Oracle在删除归档日志，可是每次均删除的日志只须要容纳要新增的文件便可，不会一会儿删除到使利用率到50%如下：
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES -------------------- ------------------ ------------------------- --------------- CONTROL FILE 0 0 0 REDO LOG 15.33 0 13 ARCHIVED LOG 72.47 48.57 54 BACKUP PIECE .24 0 1 IMAGE COPY 0 0 0 FLASHBACK LOG 0 0 0 FOREIGN ARCHIVED LOG 0 0 0
而后一直使用alter system switch logfile命令，每执行一次，Oracle会删除一个归档日志，到最后快速恢复区的空间利用率到接近于50%。
- Thu Jan 02 12:56:29 2014
- Thread 1 advanced to log sequence 1004 (LGWR switch)
- Current log# 12 seq# 1004 mem# 0: +DATA1/ractest/onlinelog/group_12.299.835542549
- Current log# 12 seq# 1004 mem# 1: +DG_FLA/ractest/onlinelog/group_12.298.835542551
- Thu Jan 02 12:56:30 2014
- Deleted Oracle managed file +DG_FLA/ractest/archivelog/2014_01_02/thread_1_seq_963.317.835788195
- Thu Jan 02 12:56:30 2014
- LNS: Standby redo logfile selected for thread 1 sequence 1004 for destination LOG_ARCHIVE_DEST_2
- Archived Log entry 2703 added for thread 1 sequence 1003 ID 0xc8804744 dest 1:
- FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
- -------------------- ------------------ ------------------------- ---------------
- CONTROL FILE 0 0 0
- REDO LOG 15.33 0 13
- ARCHIVED LOG 33.29 28.86 65
- BACKUP PIECE .24 0 1
- IMAGE COPY 0 0 0
- FLASHBACK LOG 0 0 0
- FOREIGN ARCHIVED LOG 0 0 0
所以，咱们能够了解event 19823的用途。对于空间容量比较小的主机，可是但愿归档可以尽可能保留在快速恢复区，以便留有足够的备份时间窗口，那么能够考虑把这个百分比调整到更大，好比90%，95%等。
- 1. 24Linux - 文件管理（归档管理：tar）
- 2. oracle归档文件管理
- 3. Windows DG环境中ORACLE 自动清理归档
- 4. DG平常维护管理
- 5. 如何管理归档文件和归档目录
- 6. ORACLE物理DG平常管理
- 7. Linux-进程，归档管理等
- 8. oracle之归档日志空间管理
- 9. oralce搭建DG恢复归档时遇到一个"大坑"
- 10. DG上RMAN归档删除策略及with warnings
- 更多相关文章...
- • Swarm 集群管理 - Docker教程
- • Maven 依赖管理 - Maven教程
- • 算法总结-归并排序
- • Docker 清理命令
-
每一个你不满意的现在，都有一个你没有努力的曾经。