再次理解DB2的归档机制并提出新的疑惑

最近在工作中遇到了几次大事务回滚导致日志空间不足的问题，同时，有论坛的群友提出了一些关于日志的问题。这些问题，使自己发现自己对DB2的归档日志管理理解的还不够深刻，于是去翻了翻info center，并对DB2的归档日志的机制进行再一次的理解。

 

首先，问题如下：

1、DB2的活动日志一写满就归档，如果这个活动日志包含着活动事务，它也归档么？

2、事务太长，hold住日志号了，还能归档？

3、为什么rollback的过程中，也会导致日志号被hold住，日志使用率升高？

 

翻查了info center，了解了一下9.7的归档。确实说的是活动日志一写满就归档；

“When archiving, a log file is passed to the log manager when it is full, even if the log file is still active and is needed for normal processing. ”

但是同时有这样一句话：

The log file passed to the log manager is retained in the log path directory until it is no longer needed for normal processing. At this point, the disk space is reused.

When a log file has been archived and it contains no open transactions, the DB2 database manager does not delete the file but renames it as the next log file when such a file is needed.

按照我的理解：

1、活动日志一写满就归档（保存到归档日志路径下，此步骤是异步的），但并不是从活动日志路径move到归档日志路径，而是copy。DB2为了减小IO开销，采用复用日志的方式。所以，我们能观察到在归档日志路径下和活动日志路径下存在同名的日志文件。（而这些同时存在于活动日志目录和归档日志路径下的日志，也被某些资料称之为联机的归档日志）

2、当活动日志已经被copy到归档日志路径下（has been archived），且不包含打开的事务时，这个活动日志就可以被DB2复用。理解的关键在于，日志的归档其实和事务没有关系，真正和事务有关系的是数据库日志的复用。

 

换句话说，活动日志写满就归档，这与事务无关。但是被写满的活动日志能否被复用（因为DB2不会创建新的日志文件，只是复用，把符合复用条件的日志进行重命名，然后使用），则取决于这个日志中“it contains no open transactions”。

 

DB2为什么能够知道一个日志中是否包含着open transactions，我相信DB2一定有一个地方来记录着它，但是目前我还没找到。

 

DB2这样设计的好处，从Info center结合我自己的理解，如下：

1、能够迅速将日志（数据库里最重要的东西）从易失介质（活动日志所在存储，虽然它必然是高速稳定的介质，但是高使用率同样导致了高风险性）保存到稳固介质（其他磁盘，磁带，毕竟只是保存用，最多提供一个retrieve，损坏风险较活动日志所在介质要小）；

2、节约了重新创建、格式化文件的成本，提高了效率；

 

这样，所有的问题就都迎刃而解了。

 

问题1：

活动日志一写满，即使包含着活动事务，它也归档；

问题2：

所谓hold住日志号了，实质上就是指DB2无法重用某个日志（此日志在归档日志目录中已经有copy，但是，还包含着open transactions），因此，hold住日志号了，和能不能归档，没有关系，只是日志使用率会维持在一个很高的水平，因为从被hold住的文件开始，DB2将无法复用活动日志目录中的日志。

问题3：

很简单，roll back的时候，这个事务也是open的（在roll back而已），因此必然会hold住日志号，日志使用率自然会高（但，同时，也会发现，一旦事务回滚完毕，日志使用率瞬间下降，这是因为很多日志早就归档完了，DB2只是对活动日志路径下的日志重新改个名就直接用了，当然很快。）

 

最后，提出自己还不理解需要继续调查的问题：

 

DB2为什么能够知道一个日志中是否包含着open transactions，我相信DB2一定有一个地方来记录着它，但是目前我还没找到。希望能够找到结论。