管理恢复历史文件（原）

坚持了一段时间手动删除备份文件后终于决定研究下自动管理恢复历史文件的功能了。
背景：数据库V9.7，归档日志（设置了LOGARCHMETH1=DISK：xxx），每天执行数据库全备，备份磁盘大小是600G，只能容纳5次全备镜像，索引需要定期删除。另外归档目录中的归档日志日积月累也许要定期清除，否则影响在线日志哦，还有就是数据库恢复历史文件中包含大量垃圾数据（也就是只有条目没有相应的备份恢复对象存在--被我删了）。

诉求：根据现有条件存储备份镜像和归档日志，自动删除旧备份和归档腾出空间，另外自动清理恢复历史文件中的无效条目（该无效条目指的是其对应的对象被删除）。

手段：使用prune history命令；或配置数据库参数，实现自动恢复历史文件清理。

首先查询恢复历史文件中的内容：select * from sysibmadm.db_history，（如果你非要用list history也没人拦着。）
果然不少啊，现在试一下prune history先。找到一个START_TIME(如20121004161302），发现该条目对应的操作是日志归档（从OPERATION=’X‘看出），对应的归档日志是S0000030.LOG。
看看归档目录下的内容，果然从S0000000.LOG 开始有很多归档日志文件，S0000030.LOG赫然在列。
运行db2 prune history '20121004161302' and delete（在clp中运行哈，它不是sql而是command），预想的效果是删除所有START_TIME小于等于‘20121004161302‘的条目，而且删除归档日志目录中的S0000000.LOG到S0000030.LOG日志文件。
执行完后运行select * from sysibmadm.db_history where start_time<='20121004161302',返回为空，证明条目已删除。再看归档日志目录，果然S0000000.LOG到S0000030.LOG日志文件也被删除。
注：infocenter中prune命令的解释中说“ If you are archiving logs via a user exit program, the logs cannot be deleted using this option.“意思是当使用delete选项删除物理文件的时候只删除联机日志目录中符合条件的日志，但是测试证明使用LOGARCHMETH1后指定的归档目录也在删除范围内哦！
再注一下：又测了一下，如果第一次使用prune命令不带delete，那么只有对应条目被删除，日志仍在。在此运行带delete的prune想删除物理日志，没戏！只能手工删除了吧！？

下面开始证明一下prune只能删除恢复条目和日志文件，而不能删除备份镜像文件：
查看备份目录，找到一个在‘20121115033002’时点备份的备份镜像文件，查询该数据库备份条目：
select * from sysibmadm.db_history where start_time=‘20121115033002’ and operation='B' and operationtype='N'  --说明'B'表示备份,'N'表示数据库在线备份。
在查查‘20121115033002’时点之前的恢复历史文件中的条目：
select * from sysibmadm.db_history where start_time<='20121115033002'，恩，真不少啊。
接下来使用db2 prune history '20121115033002' and delete，预想结果是删除了很多归档日志，20121115033002及之前的条目被删除，问题是‘20121115033002’时点的备份文件是否被删除？？？
结果和预想的一致，条目和归档日志文件都被删除了，但是‘20121115033002’备份映像没有被删除！

研读了一下infocenter，发现如果设置数据库参数AUTO_DEL_REC_OBJ=ON，那么db2 prune history xxx and delete命令除了删除恢复日志条目外，还会删除此条目对应的物理日志文件，备份映像和装入副本映像。于是测试一下：

db2 update db cfg using AUTO_DEL_REC_OBJ ON
运行db2 prune history '20121115033002' and delete，预想删除刚才没有删掉的备份映像，结果没有删除。猜想是因为对应的条目不存在了，于是重新找一个备份映像‘20121116033003’
select * from sysibmadm.db_history where start_time<=‘20121116033003’，结果中显示有S00000237.LOG～S00000239.LOG。
运行db2 prune history ‘20121116033003’ and delete，预想的结果是删除条目，以及3个日志文件，以及‘20121116033003’ 对应的备份映像。
结果与预想的一致！

到此，我们已经可以手动清理恢复历史文件中的记录了，在清理条目的同时也同步清理备份文件和归档日志文件。避免了手动删除备份映像和归档日志后造成的恢复历史文件中的条目对应的对象不存在的现象。

不过以上的方法是基于手动操作，下面继续说一下如何自动清理恢复历史文件条目以及对应的物理文件。
自动的方法是依靠数据库参数来实现的：NUM_DB_BACKUPS,REC_HIS_RETENTN,AUTO_DEL_REC_OBJ。

触发条件是每次完成数据库备份操作成功完成，数据库管理器将执行恢复历史记录文件的修剪任务：
如果恢复历史记录文件中的数据库备份条目大于 num_db_backup 配置参数的值，那么数据库管理器将从恢复历史记录文件中修剪早于 rec_his_retentn 配置参数的值且状态不是 DB2HISTORY_STATUS_DO_NOT_DEL 的条目。

注：和手动执行prune一样，如果AUTO_DEL_REC_OBJ=OFF，那么数据库管理器将只删除恢复历史文件中的条目而不删除任何物理文件，如果AUTO_DEL_REC_OBJ=ON，那么除了删除恢复日志条目外，还会删除此条目对应的物理日志文件，备份映像和装入副本映像。
测试如下：
我设定保留3天的备份映像。
db2 update db cfg using NUM_DB_BACKUPS=3
db2 update db cfg using REC_HIS_RETENTN=3  --注：需要断开所有连接后生效

执行数据库在线全备：db2 backup db xxx online include logs

正巧我的环境很异常，由于有几天没删除备份文件了，所以备份目录中有几个早期的备份映像，最近几天的备份没有生成，原因是备份目录满了，所以在数据库管理器自动清除备份条目及物理文件后，在备份目录中剩下两个早期的备份映像‘20121207033003’和‘20121208033003’，今天是20121214，所以刚才的备份操作产生了一个备份映像为'20121214165608'。而且归档目录中也包含几个较早的归档日志，如S00000281～S00000286.LOG文件。
另外查询了一下备份条目：select * from sysibmadm.db_history where start_time<current timestamp - 3 day，发现最早的条目是'20121206044042'，对应的是S0000281.LOG的归档操作。

分析如下：在备份完成后，数据库管理器应该从恢复历史记录文件中修剪早于 rec_his_retentn，也就是3天前的条目应该全备删除才对，但是现在看来，3天前的备份映像和一些条目仍然存在。经查，3天前的条目中包含的是S00000281～S00000286.LOG的归档操作，另外还有S00000283.LOG之后的‘DROP TABLE’条目，进一步查询发现‘20121207033003‘的在线数据库备份跨越的日志是S00000281～S00000284.LOG,而‘20121208033003’跨越的是S00000285.LOG日志。
总结：数据库管理器在清除恢复历史记录的时候，不只是比较rec_his_retentn参数，而是要结合NUM_DB_BACKUPS，保证存在NUM_DB_BACKUPS（这里是3）个备份映像以及其备份组文件（如日志等）存在，即使他们的条目日期早于rec_his_retentn参数。


搞定收工！

本文只是演示了针对恢复历史记录文件的一些操作，相关概念请参考infocenter。

Have a nice weekend!