DB2归档日志在runstat/reorg之后的任何操作中都会有非凡的增长

Question

我的环境: DB2 10.1.4Enterprise，6.0 FP6，AIX7.1每个归档日志的大小为40 My

昨天，我们通过在线备份对ISIM数据库进行了维护。备份大小约为7GB。然后，使用db2剪枝历史记录20151001对ISIM数据库进行剪枝和删除。

然后，我们使用DataStudio4.1.0运行set和reorg，ISIM数据库中的所有表(在此数据库上不设置自动维护，并且在6个月内从不运行set/reorg)。

在重新组织数据库之后，我们再次运行that，并注意到归档日志占用的空间增加了(在runstat期间生成了大约3GB的归档日志)。因此，我们认为db2进程中可能挂着一些东西，因此我们使用db2stop / db2start重新启动了db2

重新启动DB2之后，我们测试系统，一切看起来都很好，在晚上重启DB2之后，大约有10 DB2可用。然而，在早上，我们发现所有的空间都被归档日志占用了。

我们在早上把10 to分配到磁盘上，它很快就耗尽了，这是我们以前从未见过的。通常，当ISIM协调一个系统时，我们甚至没有注意到存档日志大小的变化，即使它每小时进行一次调节，但是在昨晚的维护之后，同样的调节占用了超过50 GB的空间，即使只是一次调节，它也减慢了ISIM的协调过程，所有这些空间都被归档日志占用，在协调过程中似乎每秒钟生成一个新文件。

现在，我们的HADR数据库无法赶上这个数量的归档日志文件，而且所有的归档日志文件都断开了，我们决定先修复主DB上的问题，但是使用db2pd检查任何活动的runstat，reorg没有给出任何结果。恢复数据库现在不是一个选项，因为它是一个生产数据库。我们认为今晚可能会做脱机runstat / reorg，但我们不确定它是否能解决问题。

有人有什么建议吗？

Answer 1

最后，在一天内找到了150 in后的实际情况，用于存档日志。在再次脱机运行that之后，我们似乎忽略了表RECONCILIATION_INFO上的“RECONCILIATION_INFO实用程序无法生成统计数据.错误-930”

起初，我们认为这可能不是一个重要的错误，但是当我们深入研究db2diag.log时，我们发现了错误964 (事务日志满)以及runstat期间，但是在db2diag.log的协调过程中没有发现任何错误。

因此，我们将LOGPRIMARY值增加到25 (ISIM默认值为13)，然后，runstat在归档日志中平稳地工作，增加几个GB。在那之后，reorg和runstat再次没有占用空间。

我们和往常一样做了一些测试，现在磁盘空间不再增加了。

我仍然想知道为什么runstat会导致这样的磁盘空间问题，即使我们只是手动运行它，一旦触发它，重启数据库也没有帮助。