[ DB2 ] SQL0911N indoubt transaction(未确认的事务)的恢复方法

最新推荐文章于 2021-10-01 22:44:00 发布
最新推荐文章于 2021-10-01 22:44:00 发布
阅读量1.2k 收藏 3
点赞数
分类专栏： DB2 文章标签： db2数据库
原文链接：https://www.ibm.com/support/pages/db2-未確定トランザクション-indoubt-transaction-の回復方法
版权
当DB2数据库遇到日志满或死锁/超时问题时，可能会出现未确认的事务。这些事务可以通过运行`LIST INDOUBT TRANSACTIONS`命令来检测，并使用交互式模式提交、回滚或销毁。在确认操作前，系统会提示事务详细信息。确保在处理事务时连接到正确的数据库分区，并根据事务状态选择合适的操作。
摘要由CSDN通过智能技术生成

Question & Answer

Question
发生了一个事务日志满，但在db2diag.log中应用程序句柄未知。 我应该怎么做？

MESSAGE : ADM1823E The active log is full and is held by application handle “”. 　　　　　　　
Terminate this application by COMMIT, ROLLBACK or FORCE APPLICATION.

Cause
未确认的事务的存在可能会因为当前不存在的应用程序而导致锁超时或日志满。

SQL0911N デッドロックまたはタイムアウトのため、現在のトランザクションがロールバックされました。理由コード"68"。SQLSTATE=40001

SQL0964C データベースのトランザクション・ログがいっぱいです。 SQLSTATE=57011

未确认的事务是指一直处于未确认状态的全局事务。当两阶段提交协议的第一阶段（即prepare阶段）成功完成后，事务管理器（TM）或至少一个资源管理器（RM）变得不可用时，就会发生这种情况。

在RM日志再次可用之前，RM将无法识别是否提交或回滚一个事务分支，TM可以整合日志从RM中获取未确认的状态信息。

Answer
通过对当前连接的数据库运行LIST INDOUBT TRANSACTIONS命令，可以找到有关待处理事务的信息。

$ db2 list indoubt transactions

  1. originator: DB2 Enterprise Server Edition
    appl_id: *N0.e97q3ac.110930013422
    sequence_no: 0001 status: i
    timestamp: 2011-09-30 10:34:57 auth_id: E97Q3AC
    log_full: n type: RM
    xid: 00001D3400000008 0000000000000000 0000AF0D
  2. originator: DB2 Enterprise Server Edition
    appl_id: *N0.e97q3ac.110930021847
    sequence_no: 0001 status: i
    timestamp: 2011-09-30 11:18:46 auth_id: E97Q3AC
    log_full: n type: RM
    xid: 00001D3400000008 0000000000000000 0000B05A
  3. originator: DB2 Enterprise Server Edition
    appl_id: *N0.e97q3ac.110930014048
    sequence_no: 0001 status: i
    timestamp: 2011-09-30 10:41:36 auth_id: E97Q3AC
    log_full: n type: RM
    xid: 00001D3400000008 0000000000000000 0000AFA1
  4. originator: DB2 Enterprise Server Edition
    appl_id: *N0.e97q3ac.110930014752
    sequence_no: 0001 status: i
    timestamp: 2011-09-30 10:48:30 auth_id: E97Q3AC
    log_full: n type: RM
    xid: 00001D3400000008 0000000000000000 0000B03E
  5. originator: DB2 Enterprise Server Edition
    appl_id: *N0.e97q3ac.110930080254
    sequence_no: 0001 status: i
    timestamp: 2011-09-30 17:02:54 auth_id: E97Q3AC
    log_full: n type: RM
    xid: 00001D3400000008 0000000000000000 0000C60B0B

要处理未确认的事务，请执行带有 WITH PROMPTING 选项的 LIST INDOUBT TRANSACTIONS 命令。
这将启动一个交互式对话模式，允许你提交、回滚或销毁待处理的事务。

$ db2 list indoubt transactions with prompting

  1. originator: DB2 Enterprise Server Edition
    appl_id: *N0.e97q3ac.110930013422
    sequence_no: 0001 status: i
    timestamp: 2011-09-30 10:34:57 auth_id: E97Q3AC
    log_full: n type: RM
    xid: 00001D3400000008 0000000000000000 0000AF0D
  2. originator: DB2 Enterprise Server Edition
    appl_id: *N0.e97q3ac.110930021847
    sequence_no: 0001 status: i
    timestamp: 2011-09-30 11:18:46 auth_id: E97Q3AC
    log_full: n type: RM
    xid: 00001D3400000008 0000000000000000 0000B05A
  3. originator: DB2 Enterprise Server Edition
    appl_id: *N0.e97q3ac.110930014048
    sequence_no: 0001 status: i
    timestamp: 2011-09-30 10:41:36 auth_id: E97Q3AC
    log_full: n type: RM
    xid: 00001D3400000008 0000000000000000 0000AFA1
  4. originator: DB2 Enterprise Server Edition
    appl_id: *N0.e97q3ac.110930014752
    sequence_no: 0001 status: i
    timestamp: 2011-09-30 10:48:30 auth_id: E97Q3AC
    log_full: n type: RM
    xid: 00001D3400000008 0000000000000000 0000B03E
  5. originator: DB2 Enterprise Server Edition
    appl_id: *N0.e97q3ac.110930080254
    sequence_no: 0001 status: i
    timestamp: 2011-09-30 17:02:54 auth_id: E97Q3AC
    log_full: n type: RM
    xid: 00001D3400000008 0000000000000000 0000C60B

c/r/f/l/q:

在交互式对话模式下，您可以进行以下操作

  • 显示所有待处理的事务列表（输入l）。
  • 列出待处理的事务号x（在有效事务号后输入l）。
  • 终止(输入q)
  • 提交事务号x(在有效事务号后输入c)
  • 回滚事务号x（在有效的事务号后输入r）。
  • 销毁事务号x(在字母f后面输入有效的事务号)

命令字符和参数必须用空格隔开。
在这种情况下，它是 “c/r/f/l/q:”，但它可能是 “c/r/l/q:”，这取决于待处理事务的状态。

要处理未确认的事务，要分两步确认。
1）最终完成事务（根据事务的状态，可以是r/c），释放资源。
回滚未确认的事务------R号
回滚未确认的事务------C号

在上面的例子输出中，状态：i（未设置），所以你可以提交或回滚。
'c 1’以启发式方式提交事务1。

c/r/f/l/q: c 1

  1. originator: DB2 Enterprise Server Edition
    appl_id: *N0.e97q3ac.110930013422
    sequence_no: 0001 status: i
    timestamp: 2011-09-30 10:34:57 auth_id: E97Q3AC
    log_full: n type: RM
    xid: 00001D3400000008 0000000000000000 0000AF0D

この未確定トランザクションをヒューリスティックに COMMIT しますか? (y/n) y

在提交、回滚或销毁事务之前，当显示事务数据并提示你确认操作时，输入y。
这就是你如何提交或回滚一个事务。

2) 在以下情况下，你应该放弃(f)而不是提交或回滚。
从待处理的事务列表中丢弃(FORGET)已提交或回滚的事务------f号

  • 如果由于使用启发式方法提交或回滚的事务而出现日志满的情况（如LIST INDOUBT TRANSACTIONS命令的输出所示）。
  • 如果执行脱机备份

运用方面的考虑

  • 对于分区数据库，你必须连接到每个分区，然后执行list indoubt事务命令。
    例
    export DB2NODE=3
    db2 terminate
    db2 connect to
    db2 list indoubt transactions

  • 如果在崩溃恢复过程中检测到未确认事务的存在，db2diag.log中会记录一个类似于以下的条目。
    2011-11-30-16.25.25.062152+540 I857382A463 LEVEL: Warning
    PID : 835832 TID : 3086 PROC : db2sysc 2
    INSTANCE: e97q3ac NODE : 002 DB : TEST
    APPHDL : 1-51 APPID: *N1.e97q3ac.111130072521
    AUTHID : E97Q3AC
    EDUID : 3086 EDUNAME: db2agntp (TEST) 2
    FUNCTION: DB2 UDB, recovery manager, sqlpresr, probe:3280
    MESSAGE : In-doubt transaction(s) exists at the end of crash recovery.

  • 在提交、回滚或销毁事务之前，将显示事务数据，并提示您确认该操作。

  • 您只能提交状态为未定义(i)、缺少提交确认(m)或缺少联合提交确认(d)的事务。

  • 只有状态未定义(i)、缺少联合回滚确认(b)或终止(e)的事务才能回滚。

  • 只有状态为提交( c )、回滚( r )、缺少联合提交确认(d)或缺少联合回滚确认(b)的事务才能被中止。

  • 一个挂起的事务失败，并出现 “SQL0998N トランザクションまたはヒューリスティック処理中に、エラーが発生しました。 理由コード =36。”，执行RESTART DATABASE命令，然后再次执行LIST INDOUBT TRANSACTIONS命令，确认没有待处理的事务。
    $ db2 list indoubt transactions with prompting
    SQL1251W No data returned for heuristic query. SQLSTATE=00000
    db2diag.log中会记录以下信息。
    2011-11-30-16.58.09.561284+540 E860889A491 LEVEL: Warning
    PID : 835832 TID : 3086 PROC : db2sysc 2
    INSTANCE: e97q3ac NODE : 002 DB : TEST
    APPHDL : 2-89 APPID: *N2.e97q3ac.111130075809
    AUTHID : E97Q3AC
    EDUID : 3086 EDUNAME: db2agent (TEST) 2
    FUNCTION: DB2 UDB, recovery manager, sqlpssdw, probe:5000
    MESSAGE : Indoubt transaction processing completed.
    DATA #1 : ZRC, PD_TYPE_ZRC, 4 bytes
    0x00000000

曹小碗Lawler
关注
专栏目录
＜IBM DB2＞《DB2实际工作经验》（持续更新......）
Else 的博客
03-30 269
例如DB2SYSTEM=hostname等环境变量，这些参数只能从root下去修改。
linux db2sysc 内存,db2sysc进程占用linux内存持续增长，请各位指点。
weixin_39640024的博客
05-07 624
该服务器近期做过的变更情况：变更前，使用 sar -r 1 3 看内存使用率服务器内存使用率一直是70%该服务器原为独立物理服务器，经过虚拟化迁移到EXS上成为虚拟服务器。迁移后发现swap无法启动。原因是原物理服务器硬盘控制器为cciss。/etc/fstab 下swap的加载行为：LABEL=SWAP-cciss/codop swap sw...
DB2 DPF In-doubt transaction事务
hbhe0316的专栏
10-01 563
DB2异常宕库后indoubt transactions的处理一、故障现象某次db2数据库异常宕库，数据库启动恢复后，数据库日志提示数据库第三、四个分区节点执行Crash recovery崩溃恢复完成，但是在崩溃恢复结束后还存在不确定事务In-doubt transaction(s)： https://www.cndba.cn/hbhe0316/article/4815 ...
In-Doubt Transactions
linuxheik的专栏
08-31 797
In-Doubt Transactions The two-phase commit mechanism ensures that all nodes either commit or perform a rollback together. What happens if any of the three phases fails because of a system or netw
db2批量处理doubt transactions
09-28 259
都是实例用户执行： <sample>换成自己得数据库名字 for i in $(seq 60); do echo "NO...
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N 由于死锁或超时，已回滚当前事务。原因码“2”...
kuwoleft
08-05 626
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver][DB2/NT] SQL0911N 由于死锁或超时，已回滚当前事务。原因码“2”。SQLSTATE=40001 IBM 对该问题提供的处理办法 此问题可能是应用程序引起的 DB2 死锁，尤其是访问 DB2 数据源时，遇到类似以下内容的错误： ERROR CODE: -911 COM....
[ DB2 ] SQL0911N deadlock(死锁)的解决方法
知らない景色が見えるまで、足を動かすつづけよう。
03-02 704
Troubleshooting Problem SQL0911N デッドロックまたはタイムアウトのため、現在のトランザクションが ロールバックされました。 理由コード"68" SQLSTATE=40001 Cause 原因代码 "68 "表示由于锁超时，交易回滚。 Resolving The Problem 使用以下命令重新启动DB2 $ db2 force applications all $ db2stop $ db2start ...
DB2 SQL锁超时(SQL0911N,)
hbhe0316的专栏
10-01 1979
1.使用命令查看DB2 是否为自动提交db2 list command optionshttps://www.cndba.cn/hbhe0316/article/4800 2.将自动提交修改为OFF，下面的方法是临时关闭，需要每个终端都需要执行生效。db2 “update command options using c off” 永久关闭db2set DB2OPTIONS=...
DB2 SQL 错误（SQLCODE：-964，SQLSTATE：57011）处理方法
weixin_30793643的博客
05-02 1707
故障现象描述： 执行 SQL 语句时，出现类似如下错误消息。 指令 SQL：insert into t_stat_file_temp SQLSTATE：57011，供应商错误代码：-964 DB2 SQL 错误：SQLCODE：-964，SQLSTATE：57011， SQLERRMC：空 故障原因说明： 数据库堆中没有足够的存储空间可用于处理该语句，此错误消息是事务日志中耗尽空间的...
oracle分布式事务总结
学习、思考、分享
10-14 5725
oracle分布式事务总结（转） 基本概念 Local Coordinator：在分布事务中，必须参考其它节点上的数据才能完成自己这部分操作的站点。 Global Coordinator：分布事务的发起者，负责协调这个分布事务。 Commit Point Site：在分布事务中，首先执行COMMIT或ROLLBACK操作的站点。一般情况下，应该把存储关键数据的站点作为Commit Point Site。因为Commit Point Site和其它站点不一样，从来不会进入prepared状态，所以不会
处理未决事务(转)
cuiji1279的博客
08-13 344
处理未决事务(转)[@more@] 　　为什么引入事务概念 　　事务就是当前主流的数据库系统普遍采用的并发控制机制。 　　什么是事务 　　事务具有以下4个最重要的特征，按照每个特性的英文单词的首子母组合成为ACID属性。...
DB2异常停止导致表无法被load清空
william823的专栏
07-12 638
最近公司BPM无脑出现各种问题，内存溢出，线程挂起，先是调整JVM内存大小，内存溢出问题解决，但是有线程挂起，调整WebContainer线程大小后，以后线程挂起，根据挂起堆栈，执行数据连接，根据BPM过往经验，可能是索引表数据太大导致查询返回慢，线程挂起，影响业务处理。 查询相关索引表“DB2INST2.BPM_INSTANCE_INDEX，DB2INST2.BPM_TASK_INDEX，DB2INST2.BPM_TASK_INDEX_JOB“数据，发现已接近之前清理表的预警值，开发当晚确...
DB2 SQL0911N
weixin_30904593的博客
02-08 579
因为死锁或超时，所以当前事务已回滚。原因码为原因码。 说明 当前工作单元参与了未解决的对象争用，因此必须回滚。 原因码如下所示： 2 由于死锁而导致事务已回滚。 68 由于锁定超时而导致事务已回滚。 72 由于存在与事务中所涉及的 DB2 Data Links Manager 错误，所以事务已回滚。 73 由于 CONCURRENTDBCOORDACTIVITIES 阈...
SQL0911N 由于死锁或超时，已回滚当前事务。原因码“68”。SQLSTATE=40001
热门推荐
yutianxin123的专栏
03-30 2万+
使用网上查找的方法半天都没解决问题。 在db2的控制中心也运行了force application all terminate  db2stop db2start 但是也没有成功。在控制中心数据库实例上也右键数据库实例，选择应用程序。也强制终止了自己的应用，但还是没成功。无奈，什么设置locktime,优化sql都没什么用。不绕弯子了，最终的解决方法是： CONNECT TO GDPA
DB2 死锁
sqiutz的专栏
03-26 633
解决“SQL0911N 因为死锁或超时 ”的心得体会，与大家共享最近应用程序中老是报：[IBM][CLI Driver][DB2/6000] SQL0911N   因为死锁或超时，当前事务已被回滚。原因码为 "68"。   SQLSTATE=40001或者是[IBM][CLI Driver][DB2/6000] SQL0911N   因为死锁或超时，当前事务已被回滚。原因码为 "2"。   SQL...
DB2日志被hold导致日志空间满模拟(转载)
peace
10-09 915
  在窗口1，设置非自动提交 db2set db2options=+c  在窗口1，执行一条insert，但是不提交 $ db2 +c "insert into t1 values('leo1','leo2')" DB20000I The SQL command completed successfully. $ db2 "select * from t1" ...
DB2崩溃恢复：事务日志详解与恢复策略
事务日志（Transaction Log）是DB2为了保障数据安全和可恢复性而设计的关键组件。当数据库进行事务操作时，所有更改会被写入日志文件，即使系统出现崩溃，也能通过日志中的信息恢复到崩溃前的状态。日志记录的主要...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值