DB2异常宕库后indoubt transactions的处理

DB2异常宕库后indoubt transactions的处理

一、故障现象
某次db2数据库异常宕库，数据库启动恢复后，数据库日志提示数据库第四个分区节点执行Crash recovery崩溃恢复完成，但是在崩溃恢复结束后还存在不确定事务In-doubt transaction(s)：

2011-11-17-15.40.11.500138+480 I6993521A300       LEVEL: Warning
PID     : 393910               TID  : 1           PROC : db2lfr (BSSDB) 4
INSTANCE: db2inst1             NODE : 004
FUNCTION: DB2 UDB, data protection services, sqlpgarl, probe:99
MESSAGE : INFO ONLY: Found an old page in the log file

2011-11-17-15.40.11.676503+480 I6993822A568       LEVEL: Warning
PID     : 201212               TID  : 1           PROC : db2agntp (BSSDB) 4
INSTANCE: db2inst1             NODE : 004         DB   : BSSDB
APPHDL  : 0-52                 APPID: *N0.db2inst1.111117072500
AUTHID  : DB2INST1
FUNCTION: DB2 UDB, recovery manager, sqlprecm, probe:2880
DATA #1 : <preformatted>
total 150118444 parQ 14996904 dup 0 dpsQ 990 selQBlocking 5745 tspBlocking 1542 dbBlocking 6103
noQEntry  755310 NoWaitOther 0 numMaxWaitCBInUse 0 WaitTimedOut 47 numWaitSmallBuf 183100 numWOCB 128

2011-11-17-15.40.11.694102+480 I6994391A455       LEVEL: Warning
PID     : 201212               TID  : 1           PROC : db2agntp (BSSDB) 4
INSTANCE: db2inst1             NODE : 004         DB   : BSSDB
APPHDL  : 0-52                 APPID: *N0.db2inst1.111117072500
AUTHID  : DB2INST1
FUNCTION: DB2 UDB, recovery manager, sqlprecm, probe:4000
MESSAGE : DIA2051W Forward phase of crash recovery has completed.  Next LSN is
          "00003C12717FE813".

2011-11-17-15.40.11.931017+480 I6994847A410       LEVEL: Warning
PID     : 201212               TID  : 1           PROC : db2agntp (BSSDB) 4
INSTANCE: db2inst1             NODE : 004         DB   : BSSDB
APPHDL  : 0-52                 APPID: *N0.db2inst1.111117072500
AUTHID  : DB2INST1
FUNCTION: DB2 UDB, recovery manager, sqlpresr, probe:3170
MESSAGE : Crash recovery completed. Next LSN is 00003C12717FE813

2011-11-17-15.40.11.934487+480 I6995258A416       LEVEL: Warning
PID     : 201212               TID  : 1           PROC : db2agntp (BSSDB) 4
INSTANCE: db2inst1             NODE : 004         DB   : BSSDB
APPHDL  : 0-52                 APPID: *N0.db2inst1.111117072500
AUTHID  : DB2INST1
FUNCTION: DB2 UDB, recovery manager, sqlpresr, probe:3280
MESSAGE : In-doubt transaction(s) exists at the end of crash recovery.

二、分析处理

指定分区节点，连接到db2库第四个分区上：
[DWE3:/db2home/db2inst1]export DB2NODE=4            
[DWE3:/db2home/db2inst1]db2 connect to bssdb
   Database Connection Information
Database server        = DB2/AIX64 9.1.9
SQL authorization ID   = DB2INST1
Local database alias   = BSSDB

执行db2 list indoubt transactions命令查询indoubt事务：
[DWE3:/db2home/db2inst1]db2 list indoubt transactions
1.   originator: DB2 Enterprise Server Edition
      appl_id: 130.30.15.150.50782.11111601343                               sequence_no: 0001 status: i
      timestamp: 2011-11-16 10:47:58 auth_id: ETL
      log_full: n type: RM
      xid: 00001D3400000008 0000000000000000 34684546

查询结果显示，分区节点四确实存在一个indoubt transactions，为130.30.15.150客户端主机连接过来的事务。

在多次执行重启数据库执行崩溃恢复，仍无发完成indoubt transactions的处理。通过手工执行命令提交清理不确定事务：

1） 使用with prompting选项列出indoubt transactions：
[DWE3:/db2home/db2inst1]db2 list indoubt transactions with prompting
1.   originator: DB2 Enterprise Server Edition
      appl_id: 130.30.15.150.50782.11111601343                               sequence_no: 0001 status: i
      timestamp: 2011-11-16 10:47:58 auth_id: ETL
      log_full: n type: RM
      xid: 00001D3400000008 0000000000000000 34684546
Enter in-doubt transaction command or 'q' to quit.
e.g. 'c 1' heuristically commits transaction 1.
c/r/f/l/q:

查询显示有一条indoubt transactions，编号1，并提示输入命令或q退出

2） 输入“c 1”，提交indoubt事务1
c/r/f/l/q: c 1
1.   originator: DB2 Enterprise Server Edition
      appl_id: 130.30.15.150.50782.11111601343                               sequence_no: 0001 status: i
      timestamp: 2011-11-16 10:47:58 auth_id: ETL
      log_full: n type: RM
      xid: 00001D3400000008 0000000000000000 34684546
Do you want to heuristically COMMIT this in-doubt transaction? (y/n) y

3） 输入“y”，确认COMMIT in-doubt transaction操作
执行确认操作后，提示如下信息：
SQL0998N  Error occurred during transaction or heuristic processing.  Reason
Code = "226". Subcode = "0".  SQLSTATE=58005

落实操作报错，通过查询SQL0998N代码可了解到，ReasonCode = "226"代表“已回滚了事务”。

C:Documents and Settingsfengsh>db2 ? SQL0998N
SQL0998N  在事务或试探性处理期间出错。原因码："<原因码>"。子代
      码："<子代码>"。

说明:
当处理分布式事务时，检测到错误。事务是：
*  在"分布式事务处理"环境（如 CICS 或其他事务管理器中的那些）下运行。
*  执行试探性操作。
*  更新联合数据库中的多个昵称，每个更新的昵称表示不同的数据源。在此情况
   下，在事务处理期间，其中一个数据源失败。在此情况下，返回的原因码为数
   据源上故障的原因，而不是联合数据库上故障的原因。

可能的原因码（对应的 X/Open XA 原因码显示在括号中）是：

*  01 －（XAER_ASYNC）尚未完成异步操作。
*  02 －（XAER_RMERR）在事务分支中发生资源管理器错误。
......................
......................
*  226 － 已回滚了事务。

 

4） 输入“q”，退出in-doubt transaction处理命令行，并再次查询不确定事务，已经没有返回indoubt transactions：
Enter in-doubt transaction command or 'q' to quit.
e.g. 'c 1' heuristically commits transaction 1.
c/r/f/l/q: q

[DWE3:/db2home/db2inst1]db2 list indoubt transactions              
SQL1251W  No data returned for heuristic query.  SQLSTATE=00000

三、总结
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.

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.

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

手工解决不确定事务
符合 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