某天上午，
突然接到一客户电话，说DB2宕机了，请求支援。因为是非常重要的生产系统，赶到客户现场估计来不及了，考虑通过QQ能不能远程搞定，搞不定再说。（以下隐去了DB2数据库名字）
首先和客户DBA进行沟通，对问题有一个基本了解：
由于公司审计需要，8月份重新制定了安全审计策略，DB2开启了audit功能，并打开了如context和execute等需要很大空间的audit选项。由于是月底，大量的事务处理了导致audit文件空间满，然后导致数据库无法连接，报如下错误：
$ db2 connect to
SQL1224N The database manager is not able to accept new requests, has
terminated all requests in progress, or has terminated the specified request
because of an error or a forced interrupt. SQLSTATE=55032
DBA发现空间满后，通过echo > xxx.out 对audit文件进行了清空，然后停止了db2audit命令。观察db2diag.log文件，不停的报：
2011-08-30-13.41.17.598986+480 I14000047A2740 LEVEL: Error (OS)
PID : 327
2011-08-30-13.46.13.332977+480 I14000129A601 LEVEL: Error
PID : 3276822 TID : 42569 PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB :
APPHDL : 0-38852 APPID: GA912716.PEA8.01321931A8D1
EDUID : 42569 EDUNAME: db2agent (LIS) 0
FUNCTION: DB2 UDB, bsu security, sqlexAuditOpenAdjust, probe:149
RETCODE : ZRC=0x870F0009=-2029060087=SQLO_EOF “the data does not exist”
DIA8506C Unexpected end of file was reached.
DATA #1 : Hexdump, 4 bytes
0x07000006EC7F02F0 : 870F 0009 ….
2011-08-30-13.46.13.333281+480 I14000731A526 LEVEL: Error
PID : 3276822 TID : 42569 PROC : db2sysc 0
INSTANCE: db2inst1 NODE : 000 DB :
APPHDL : 0-38852 APPID: GA912716.PEA8.01321931A8D1
EDUID : 42569 EDUNAME: db2agent (LIS) 0
FUNCTION: DB2 UDB, bsu security, sqlexAuditWriteBufferToDisk, probe:13462
MESSAGE : ZRC=0x875C00CD=-2024013619=SQLEX_UNEXPECTED_SYSERR
“Unexpected System Error”
DATA #1 : Hex integer, 4 bytes
0×40000011
即使停止了db2audit，并重启实例，仍然有该问题。
这时，怀疑是DB2的bug。登陆ibm的support网站，果然搜到一条类似的apar，
https://www-304.ibm.com/support/docview.wss?uid=swg1IZ40408
该问题是针对9.5 fp3以前的版本，但错误症状几乎一样。大概意思是说当db2audit没有空间后，会创建一个空的audit文件，但无法写audit header到文件，结果db2认为这个文件被corrupt了，因此报错。该问题作为DB2的bug已经在fp4补丁中修复，一个workaround就是删除这个空日志文件。
根据这个解释，可以推断出当前问题的根源是由于DBA的echo > xxx.out，手工把audit header给破坏了，结果导致db2问题。知道了根源，解决起来就简单了：将db2audit.db.LIS.log.0文件删除，然后发现db2audit开始创建新的audit log，系统恢复正常。
$ ls -l
total 14848
-rw——- 1 db2inst1 db2grp1 35340 Aug 30 14:29 db2audit.db..log.0
-rw——- 1 db2inst1 db2grp1 2 Aug 30 13:46 db2audit.db..log.0.bak
-rw——- 1 db2inst1 db2grp1 7543102 Aug 30 13:44 db2audit.instance.log.0
从发现问题，到最后处理完毕，用时大概30分钟，客户对我们的及时响应和问题处理能力表示满意。
针对这个问题，总结如下：
1. db2audit会占据很大的空间，特别是当context和execute选项打开时，会记录SQL信息，因此，需要规划很大的空间。
2. 遵循一定的步骤，不要慌乱。本例中，当文件系统满时，如果先关闭db2audit，再去清理audit log，或许可以避免。
3. db2audit的使用还是要谨慎，曾经遇见过几个客户由于db2audit导致宕机的案例。
关于audit的配置实验，可以参看《DB2数据库管理最佳实践》。收起