DB2数据库事务日志已满问题解决方案

本系列文章主要介绍数据库管理员（DBA）在日常维护中遇上一些比较紧急的情况如何处理，本篇主要介绍DB2交易日志存储空间满问题如何处理。

1、数据库事务日志的最大大小

数据库事务日志的最大大小由数据库的三个配置参数决定，分别是“主日志文件的数目”（LOGPRIMARY）、“辅助日志文件的数目”（LOGSECOND）和“日志文件大小（4KB）”（LOGFILSIZ）。数据库事务日志的最大大小的计算公式如清单 01-32 所示：

清单 1. 数据库事务日志的最大大小的计算公式

数据库事务日志的最大大小 = （ LOGPRIMARY + LOGSECOND ）* LOGFILSIZ * 4KB

LOGSECOND 在这个公式中不能设为 “ -1 ” ，“ -1 ”代表你在请求一个无限的活动日志空间，数据库也不会报数据库事务日志已满错误，如果空间不足则会报日志磁盘已满错误，具体如本章第五节所述。下面我们具体看一下这三个参数：

1. 主日志文件的数目 LOGPRIMARY
   此数据库配置参数用来指定要预分配的主日志文件个数。主日志文件建立分配给恢复日志文件的固定存储器数量。在循环日志管理模式下，数据库事务将按顺序重复使用主日志，也就是当一个主日志已满时，顺序使用下一个主日志，如果主日志已满，则按需一次分配一个辅助日志，辅助日志在使用完后，将被释放。如果你发现数据库会经常分配辅助日志文件，则可能需要通过增大日志文件大小或增大主日志文件的数目来提高系统性能。
2. 辅助日志文件的数目 LOGSECOND
   此数据库配置参数用来指定按需分配的辅助日志文件个数。尽量不要把此参数的值设置成“ -1 ” ，“ -1 ”代表你在请求一个无限的活动日志空间，数据库也不会报数据库事务日志已满错误，如果空间不足则会报日志磁盘已满错误。
3. 日志文件大小 LOGFILSIZ
   此数据库配置参数用来指定日志文件的大小。

2、数据库事务日志已满错误

数据库事务日志已满错误是指当前事务无法写入到活动日志中（此时主日志文件和辅助日志文件已经全部用完或者没有足够当前事务写入的空间），需要注意的是，这个错误和日志磁盘空间已满是两个概念，如果想查看日志磁盘已满错误，请参照本章第五节。数据库事务日志已满不是由于磁盘空间满引起的，而是由于没有落实的事务总体过大，超过了数据库事务日志所能容纳的最大大小所造成的。

一般系统上线之初（如果是分阶段上线，则是每次上线之初），由于经常要导大量的数据，容易出现这个问题，当出现这个问题时，直接的办法是找到引起这个错误的当前事务，终止掉这个事务即可，后续在操作时找到当前执行的事务中比较大的事务，尽量落实或回滚该事务。

一般情况下，建议大家在系统上线之初进行导数时，尽量使用 LOAD 实用程序（如果是归档日志模式，建议使用带 NONRECOVERABLE 选项的 LOAD 实用程序，否则装入完成后数据库或装入的表所在的表空间会被置于备份暂挂状态，需要做一次全备才能解除备份暂挂状态），LOAD 实用程序在装入数据时不记日志。

如果使用 IMPORT 实用程序，建议使用 COMMITCOUNT 选项。无论是循环日志模式还是归档日志模式，使用 IMPORT 实用程序导入大量数据时，都有可能报数据库事务日志已满（也就是当前导入操作产生的事务过大，使得当前活动日志满了，包括所有的主日志和辅助日志都用完了），所以为了避免数据库日志已满错误，提高并发性，可以使用 COMMITCOUNT 选项，对要导入的数据分阶段提交。比如可以将 COMMITCOUNT 参数设置为“自动”，指示 import 实用程序 内部决定何时进行落实。此外，也可以将 COMMITCOUNT 选项设置为特定数字，指示 import 实用程序 在导入指定记录数后即进行落实。

尽量避免在上线之初直接使用“ INSERT INTO … SELECT .. FROM .. ”语句，导入一个很大的事务的方式进行导数，这样会使事务非常大。另外，还可以在系统上线之初把主日志文件的数目（LOGPRIMARY）、辅助日志文件的数目（LOGSECOND）和日志文件大小（4KB）（LOGFILSIZ）三个参数调大，等系统正式上线稳定后，再调回合适的值。

如果是在正式上线后的系统，经常出现这个问题，就需要查找原因，具体的原因可能有：

1. 数据库并发连接比较多
   这种情况下，就要考虑适当增加主日志文件的数目（LOGPRIMARY）和日志文件大小（4KB）（LOGFILSIZ）。
2. 有人通过第三方软件或其他工具直接连接到了生产库
   在这样的情况下，就要监控数据库，看其是否经常写一些大的语句对数据库进行增删改的操作，如果是的话，建议增加数据库的控制，尽量不要让不相关的人员连接生产库（如果其他人有需要，尽量开放备份库给他们使用，而不要开放生产库，生产库尽量只给业务系统正常使用），如果你使用的是 DB2 V9.5 版本，则可以使用工作负载管理 WLM 对数据库的资源进行调配。如果使用的是 DB2 V9.5 之前的版本，则可以在数据库服务器上通过配置操作系统的方式，限制一些 IP 的访问。

当出现这样的错误时，不要尝试使用 DB2STOP FORCE 命令来强制停掉数据库，建议大家使用 FORCE APPLICATION 命令停掉引起这个错误的应用程序或者停掉所有的应用程序。也不建议大家使用 KILL 命令来杀掉任何 DB2 相关的进程。

评论

2 楼 liumin1939 2011-01-17  

呵呵 看来哥们经验很丰富啊！这是我刚用db2时收藏的，像你说的这种情况我们实际项目中是碰到过的，也是用你说的那些方式处理的。

1 楼 智长老 2011-01-13  

很多情况下你是force不掉app的，如果这个app占用大量log，你就必须重启实例，有时候实例也停不了，就只能用db2_kill杀掉db2进程，但是在重启时会经历一个漫长的crash recovery过程（有时会数小时，根据未提交日志的大小）