db2多分区数据库 SQLCODE=-964, SQLSTATE=57011，数据库的事务日志已满

db2多分区数据库在处理大批量数据删除的时候会频繁出现如下错误：SQLCODE=-964, SQLSTATE=57011，数据库的事务日志已满，有时候在执行存储过程的时候还会出现 SQLCODE : -727 SQLSTATE: 56098，在隐式重新绑定或预编译期间出错。

（1）尝试通过增大日志相关的三个参数进行解决：

db2 update db cfg for using LOGPRIMARY 50

db2 update db cfg for using LOGSECOND 20

db2 update db cfg for using LOGFILSIZ 102400

执行完命令，并重启数据库之后监控事务日志目录，发现居然没有生效。郁闷。。。。。。

后来胡乱试的时候发现把以上三个参数先调小，居然生效了，然后再调大居然可以了。

（2）可惜好景不长，没过几天事务日志满的情况又出现了，然后重复之前的操作居然不行了，再次郁闷。。。。。。

（3）后来查资料发现引起事务日志满的情况不一定就是空间不够，还有可能是因为某些事务没提交引起的，具体链接：http://www.cnblogs.com/BradMiller/p/3198126.html

https://blog.csdn.net/tqwer/article/details/7346106

http://www.orasql.com/blog/archives/2014/12/10/db2_SQL0964C.htm

（4）分别查询三台分区数据库服务器上的db2diag.log，发现一直报如下错误

2018-12-15-17.22.22.973365+480 I2485073927E934       LEVEL: Severe
PID     : 12920                TID : 140163896305408 PROC : db2sysc 22
INSTANCE: db2inst1             NODE : 022            DB   : ORDERDB
APPHDL  : 0-299                APPID: 10.65.131.80.38234.181215092201
AUTHID  : NBADV                HOSTNAME: crmdb12
EDUID   : 708                  EDUNAME: db2agntp (ORDERDB) 22
FUNCTION: DB2 UDB, catalog services, sqlrl_dgtt_rcv, probe:30
MESSAGE : ZRC=0x85100009=-2062548983=SQLP_NOSPACE
          "Log File has reached its saturation point"
          DIA8309C Log file was full.
CALLED  : DB2 UDB, data management, sqldTableCreateTemp
RETCODE : ZRC=0x85100009=-2062548983=SQLP_NOSPACE
          "Log File has reached its saturation point"
          DIA8309C Log file was full.
DATA #1 : String, 7 bytes
ftoken 
DATA #2 : unsigned integer, 2 bytes
12
DATA #3 : String, 7 bytes
ttoken 
DATA #4 : unsigned integer, 2 bytes
6

2018-12-15-17.22.22.978081+480 E2485074862E630       LEVEL: Error
PID     : 12920                TID : 140163896305408 PROC : db2sysc 22
INSTANCE: db2inst1             NODE : 022            DB   : ORDERDB
APPHDL  : 0-299                APPID: 10.65.131.80.38234.181215092201
AUTHID  : NBADV                HOSTNAME: crmdb12
EDUID   : 708                  EDUNAME: db2agntp (ORDERDB) 22
FUNCTION: DB2 UDB, data protection services, sqlpgResSpace, probe:2850
MESSAGE : ADM1823E  The active log is full and is held by application handle 
          "".  Terminate this application by COMMIT, ROLLBACK or FORCE 
          APPLICATION.

2018-12-15-17.22.22.978480+480 E2485075493E552       LEVEL: Warning
PID     : 12920                TID : 140163896305408 PROC : db2sysc 22
INSTANCE: db2inst1             NODE : 022            DB   : ORDERDB
APPHDL  : 0-299                APPID: 10.65.131.80.38234.181215092201
AUTHID  : NBADV                HOSTNAME: crmdb12
EDUID   : 708                  EDUNAME: db2agntp (ORDERDB) 22
FUNCTION: DB2 UDB, data protection services, sqlpgResSpace, probe:2865
MESSAGE : ADM1829E  The active log is full and is held by an indoubt 
          transaction.

2018-12-15-17.22.22.978807+480 E2485076046E599       LEVEL: Error
PID     : 12920                TID : 140163896305408 PROC : db2sysc 22
INSTANCE: db2inst1             NODE : 022            DB   : ORDERDB
APPHDL  : 0-299                APPID: 10.65.131.80.38234.181215092201
AUTHID  : NBADV                HOSTNAME: crmdb12
EDUID   : 708                  EDUNAME: db2agntp (ORDERDB) 22
FUNCTION: DB2 UDB, data protection services, sqlpgResSpace, probe:6666
MESSAGE : ZRC=0x85100009=-2062548983=SQLP_NOSPACE
          "Log File has reached its saturation point"
          DIA8309C Log file was full.

2018-12-15-17.22.22.979064+480 I2485076646E916       LEVEL: Error
PID     : 12920                TID : 140163896305408 PROC : db2sysc 22
INSTANCE: db2inst1             NODE : 022            DB   : ORDERDB
APPHDL  : 0-299                APPID: 10.65.131.80.38234.181215092201
AUTHID  : NBADV                HOSTNAME: crmdb12
EDUID   : 708                  EDUNAME: db2agntp (ORDERDB) 22
FUNCTION: DB2 UDB, data protection services, SQLP_TENTRY::sqlpReserveLogSpace, probe:2020
MESSAGE : ZRC=0x85100009=-2062548983=SQLP_NOSPACE
          "Log File has reached its saturation point"
          DIA8309C Log file was full.
DATA #1 : String, 56 bytes
TID / myTidhdl / sharedLogSpace / totalReservedLogSpace:
DATA #2 : SQLP_TID8, PD_TYPE_SQLP_TID8, 8 bytes
0000000004C5D48F
DATA #3 : Transaction ID handle, PD_TYPE_SQLP_TIDHDL, 4 bytes
267 (User)
DATA #4 : unsigned integer, 8 bytes
0
DATA #5 : unsigned integer, 8 bytes
0

2018-12-15-17.22.22.979465+480 I2485077563E597       LEVEL: Error
PID     : 12920                TID : 140163896305408 PROC : db2sysc 22
INSTANCE: db2inst1             NODE : 022            DB   : ORDERDB
APPHDL  : 0-299                APPID: 10.65.131.80.38234.181215092201
AUTHID  : NBADV                HOSTNAME: crmdb12
EDUID   : 708                  EDUNAME: db2agntp (ORDERDB) 22
FUNCTION: DB2 UDB, data protection services, sqlpWriteLR, probe:6680
MESSAGE : ZRC=0x85100009=-2062548983=SQLP_NOSPACE
          "Log File has reached its saturation point"
          DIA8309C Log file was full.

（5）上边的报错查看发现没有提交的进程号居然是“”，执行db2 force application all 之后问题仍然存在，继续搜索，发现如下方案：http://www.talkwithtrend.com/Article/185911

（6）执行 db2_all "db2 restart database orderdb"，问题解决了

总结：

DB2数据库在出现异常，非正常关闭情况下（如DB2数据库实例异常终止，主机异常宕机后导致数据库不一致状态等），数据库启动后自己会做CRASH RECOVERY崩溃恢复，使用logfile日志文件记录的日志将数据库恢复到一致性状态。
一般情况下，执行崩溃恢复后，数据库基本都能恢复一致性，异常事务会被处理，可通过命令“db2 list indoubt transactions”查看数据库有无不确定事务。在查询有不确定事务存在时的处理：

1）重启db2实例，激活数据库时系统会自动检测到异常，自己执行CRASH RECOVERY，完成数据库一致性的检查恢复。

２）可通过多次执行db2 restart database来启动CRASH RECOVERY操作，在ＤＰＦ分区库中，需通过执行db2_all "db2 restart database database-alias" 在所有分区执行。

3）通过以上两种方式执行CRASH RECOVERY崩溃恢复无法完成不确定事务（indoubt transactions）自动处理情况下，可通过上面方法手工处理。

 

Command parameters WITH PROMPTING Indicates that indoubt transactions are to be processed. If this parameter is specified, an interactive dialog mode is initiated, permitting the user to commit, roll back, or forget indoubt transactions. If this parameter is not specified, indoubt transactions are written to the standard output device, and the interactive dialog mode is not initiated.Interactive dialog mode permits the user to:

• List all indoubt transactions (enter l)
• List indoubt transaction number x (enter l, followed by a valid transaction number)
• Quit (enter q)
• Commit transaction number x (enter c, followed by a valid transaction number)
• Roll back transaction number x (enter r, followed by a valid transaction number)
• Forget transaction number x (enter f, followed by a valid transaction number).

A blank space must separate the command letter from its argument.

Before a transaction is committed, rolled back, or forgotten, the transaction data is displayed, and the user is asked to confirm the action.

The LIST INDOUBT TRANSACTIONS command returns type information to show the role of the database in each indoubt transaction:

 

官方文档参考：
=============================

手工解决不确定事务
符合 XA 的事务管理器（事务处理监视器）使用类似于 DB2® 事务管理器使用的两阶段落实过程。两个环境之间的主要区别是，TP 监视器提供日志记录和控制该事务的功能，而不是 DB2 事务管理器和事务管理器数据库来提供此功能。

当使用符合 XA 的事务管理器时，可能发生类似于 DB2 事务管理器发生的错误。类似于 DB2 事务管理器，符合 XA 的事务管理器将试图使不确定事务再同步。

若您不能等待事务管理器自动解决不确定事务，则您可以手工解决它们。此手工过程有时称为“作启发式决策”。

LIST INDOUBT TRANSACTIONS 命令（使用 WITH PROMPTING 选项）或相关的一组 API（db2XaListIndTrans、sqlxphcm、sqlxhfrg 和 sqlxphrl） 允许您查询、落实和回滚不确定事务。另外，它还允许通过除去日志记录并释放日志空间来“忘记”已经以试探方式落实或回滚的事务。

限制 
极为谨慎地使用这些命令（或相关的 API）来手工解决不确定事务，并且只有在万不得已的情况下才使用这些命令。最好的策略是等待事务管理器驱动再同步过程。若您在其中一个参与数据库中以手工方式落实或回滚一个事务，并对另一个参与的数据库执行相反的操作，可能会遇到数据完整性问题。校正数据完整性问题要求您了解该应用程序的逻辑，标识已更改或回滚的数据，然后执行数据库的时间点恢复，或以手工方式撤销或重新执行更改。

若您不能等待事务管理器启动再同步过程，且您必须释放不确定事务占用的资源，则必须执行试探性操作。若事务管理器无法在延长期内执行再同步，且该不确定事务占用着急需的资源，则可能发生这种情况。不确定事务占用着事务管理器或资源管理器成为不可用之前与此事务相关的资源。对于数据库管理器，这些资源包括对该事务占用的表和索引、日志空间和存储器的锁定。每个不确定事务还会递减（减一）数据库可以处理的并发事务的最大数目。而且，除非解析了所有不确定事务，否则不能进行脱机备份。

在下列情况下，需要试探性忘记功能：

当以试探方式落实或回滚事务导致日志满情况时（此情况在 LIST INDOUBT TRANSACTIONS 命令的输出中指示） 
当要执行脱机备份时
试探性忘记功能释放由不确定事务占用的日志空间。隐含情况为，若一个事务管理器最终对此不确定事务执行了再同步操作，则可能会作出错误的决定来落实或回滚其他资源管理器，因为在此资源管理器中没有该事务的日志记录。通常，“丢失”日志记录意味着资源管理器已回滚该事务。

过程 
要手工解决不确定事务：

与您要完成其所有事务的数据库连接。 
显示不确定事务： 
对于 DB2 数据库服务器，使用 LIST INDOUBT TRANSACTIONS WITH PROMPTING 命令。xid 表示全局事务标识，它与事务管理器和参与事务的其他资源管理器使用的 xid 完全相同。 
对于主机或 iSeries™ 数据库服务器，可以使用下列其中一种方法： 
可以直接从主机或 iSeries 服务器获取不确定信息。 
要直接从 DB2 z/OS® 和 OS/390® 版获取不确定信息，调用 DISPLAY THREAD TYPE(INDOUBT) 命令。使用 RECOVER 命令来作出启发式决策。要直接从 DB2 iSeries 版获取不确定信息，调用 wrkcmtdfn 命令。

可以从用来访问主机或 iSeries 数据库服务器的 DB2 Connect™ 服务器获取不确定信息。 
要从 DB2 Connect 服务器获取不确定信息，首先通过连接由数据库管理器配置参数 spm_name 的值所表示的 DB2 实例来与 DB2 同步点管理器连接。然后发出 LIST DRDA INDOUBT TRANSACTIONS WITH PROMPTING 命令来显示不确定事务并作出启发式决策。另外，可以从客户机应用程序中调用 sqlcspqy API 来列示 DRDA® 不确定事务。

对于已列示或显示的每个不确定事务，使用显示的关于应用程序和操作环境的信息来确定其他参与的资源管理器。 
确定要对每个不确定事务执行的操作： 
如果该事务管理器是可用的，且资源管理器中的不确定事务是由于在第二个落实阶段期间或更早的再同步过程期间资源管理器不可用导致的，则您应该执行下列操作： 
检查该事务管理器的日志，以确定对其他资源管理器执行过什么操作。 
对该数据库执行相同的操作；即使用 LIST INDOUBT TRANSACTIONS WITH PROMPTING 命令试探性落实或试探性回滚该事务。
如果事务管理器不可用，则应使用其他参与资源管理器中该事务的状态，以确定您应该执行什么操作： 
如果其他资源管理器中至少有一个已经落实该事务，则应在所有资源管理器中试探性落实该事务。 
如果其他资源管理器中至少有一个已经回滚该事务，则应试探性回滚该事务。 
如果该事务在参与的所有资源管理器中都处于“已准备”（不确定）状态，则应试探性回滚该事务。 
如果其他资源管理器中有一个或多个不可用，则应试探性回滚该事务。
要从运行于 UNIX® 或 Windows® 操作系统上的 DB2 中获取不确定事务信息，请连接至数据库并发出 LIST INDOUBT TRANSACTIONS WITH PROMPTING 命令，或者从客户机应用程序中调用 db2XaListIndTrans API。

 http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.cmd.doc%2Fdoc%2Fr0001963.html&resultof%3D%2522%2564%2562%2532%2522%2520%2522%256c%2569%2573%2574%2522%2520%2522%2569%256e%2564%256f%2575%2562%2574%2522%2520%2522%2574%2572%2561%256e%2573%2561%2563%2574%2569%256f%256e%2573%2522%2520%2522%2570%2572%256f%256d%2570%2574%2569%256e%2567%2522%2520

 

http://pic.dhe.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=%2Fcom.ibm.db2.luw.admin.2pc.doc%2Fdoc%2Ft0004636.html