DB2 的日志错误及解决

前言

    日志网上也有很多介绍的文章，最近遇到一个日志的问题，顺便对日志进行了了解及对问题进行了解决，日志错误如下：SQL0964C The transaction log for the database is full.第一感觉是日志满了，清空日志也许就可能解决，不过查询下空间发现空间充足，看来有必须学习了解下DB2日志了。

简介：

DB2   数据库 支持两种不同的日志模式：循环(Circular)和归档(Archival)。当新数据库创建时，系统默认的日志模式为循环。如果业务需求要求更高级的功能，需要将日志模式由循环改为归档，比如：当需要IBM的CDC功能时候。    

具体介绍：

循环日志  

　　网上介绍也有很多，这里我用大白话翻译一下：对数据库的一些操作(比如增删改查)会产生操作的日志要写到日志文件中，以便用于数据库恢复之用，循环日志的意思就是一个日志文件循环利用，也就是说新的日志写入会覆盖掉旧的日志(DB2会判断改日志不会用于恢复之用时，标记为可重用，就是新操作日志的可以覆盖这个文件了)，所以由于日志文件的内容被重写覆盖了，因此我们只能将数据库恢复到最后一次完整的数据库备份，而不能使用循环日志执行时间点(point-in-time)恢复。  

归档日志    

　　在归档日志模式中就与循环日志不同了，这些日志文件永远都不可重用。当存储于某个日志文件中的所有记录都不再需要用于恢复时，该日志文件将被标记为非活动，而不是可重用。这意味着它的内容永远都不会被覆盖。当第一个主要日志文件变满时， 系统 将分配一个新的日志文件，日志文件的个数由为主要日志文件个数+次要文件个数，个数是可以修改的，每个日志文件的大小也是可以修改。  

分析错误

　　 现在应该回过头来分析下错误的原因了，在得知了此错误是在大量进行一个事务操作的时候发生的，此时 DB2   会一直尝试将日志条目写入主要日志文件集，也就是数据库活动时间自动分配的日志文件。如果某个事务将所有主要日志文件消耗怠尽(所有主要日志文件都被标记为 unavailable)，则会分配一个次要日志文件。当这个文件变满时，数据库管理员将再次检查主要日志文件的状态是否为 unavailable。如果是，则再分配一个次要日志文件并继续在其中写入条目。该过程将不断重复，直到所有次要日志文件都分配并写满。如果没有主要日志文件可供写入 Redo 条目，并且已经分配最大数量的次要日志文件，则应用程序将收到以下错误消息：  

　   SQL0964C The transaction log for the database is full.

看来有必要修改下主要文件或次要文件的个数或文件的大小了。

先查询下当前数据库日志的配置

可以发起以下命令进行更改：  

db2 update db cfg for ae_dw using LOGFILSIZ 7900

db2 update db cfg for DATABASE using LOGPRIMARY 30

db2 update db cfg for DATABASE using LOGSECOND 20

更改后重启，再查   询配置

D b2 get db cfg for aedw | grep log

经测试，原来的错误也解决了

注意：如果出现此问题，则应该分析造成整个日志文件空间变满的原因是什么。它可能是由失控查询或用户错误造成的，因此增加日志文件的数量或大小只能在表面上解决问题。比如说，假设某个用户发起了一个 DELETE FROM tab1 语句，且 TAB1 是一个相当大的表。虽然这一语句看上去没什么问题，每行生成一条删除日记记录，但是如果未经过配置处理它可以轻易地将日志空间填满。  

最后总结下循环日志设置成归档日志模式的命令

db2 update db cfg using LOGARCHMETH1 DISK:/home/db2inst1/db_r/archivelog

db2 update db cfg using AUTO_REORG ON

db2stop force

db2start

db2 backup database DB_R to /tmp

db2 connect to db_r