《oracle参考资料》由会员分享，可在线阅读，更多相关《oracle参考资料（8页珍藏版）》请在金锄头文库上搜索。
1、http:/ 错误故障处理摘要：在访问某些表的特定行时报 ORA-01591 错误select * from BF_INCOME_EXPENSES_Twhere account_id = 36816153and user_id = 39964213and city_code = 185ORA-01591: 锁定已被有问题的分配事务处理 72.0.1608712 挂起SQL select count(*) from UNITELE.BI_MQSYNC_SOURCE_CONTROL_T1;ORA-01591: 锁定已被有问题的分配事务处理 72.0.1608712 挂起由于该表是业务关键表，部分前
2、台业务受到影响。关键词：ORA-01591 DBA_2PC_PENDING 分布式事务1.故障分析首先，在遇到 ORA 错误时，我们不可能知道每个 ORA 错误都是什么意思，所以通过 oracle 的联机文档查错误的 cause 和 action 可以让我们初步了解该错误。01591, 00000, lock held by in-doubt distributed transaction %s/ *Cause: Trying to access resource that is locked by a dead two-phase commit/ transaction that is in
3、 prepared state./ *Action: DBA should query the pending_trans$ and related tables, and attempt/ to repair network connection(s) to coordinator and commit point./ If timely repair is not possible, DBA should contact DBA at commit/ point if known or end user for correct outcome, or use heuristic/ defa
4、ult if given to issue a heuristic commit or abort command to/ finalize the local portion of the distributed transaction.Oracle 对 ORA-01591 错误的描述是lock held by in-doubt distributed transaction %s，由分布式事务持有锁造成的。通过错误的 cause 可以看到Trying to access resource that is locked by a dead two-phase commit transacti
5、on that is in prepared state该错误是由访问一个处于prepared 状态的二阶段事务所持有锁的资源造成的。下面简单介绍一下分布式事务。分布式事务，简单来说，是指一个事务在本地和远程执行，本地需要等待确认远程的事务结束后，进行下一步本地的操作。如通过 dblink update 远程数据库的一行记录，如果在执行过程中网络异常，或者其他事件导致本地数据库无法得知远程数据库的执行情况，此时就会发生 in doublt 的报错。此时需要dba 介入，且需要分多种情况进行处理。分布式事务的 Two-Phase Commit 机制，会经历 3 个阶段：1.PREPARE PHA
6、SE：1.1 决定哪个数据库为 commit point site。（注，参数文件中commit_point_strength 值高的那个数据库为 commit point site）1.2 全局协调者（Global Coordinator）要求所有的点（除 commit point site 外）做好 commit 或者 rollback 的准备。此时，对分布式事务的表加锁。1.3 所有分布式事务的节点将它的 scn 告知全局协调者。1.4 全局协调者取各个点的最大的 scn 作为分布式事务的 scn。至此，所有的点都完成了准备工作，我们开始进入 COMMIT PHASE 阶段，此时除 co
7、mmit point site 点外所有点的事务均为 in doubt 状态，直到 COMMIT PHASE 阶段结束。2.COMMIT PHASE：2.1 Global Coordinator 将最大 scn 传到 commit point site，要求其commit。2.2 commit point 尝试 commit 或者 rollback。分布式事务锁释放。2.3 commit point 通知 Global Coordinator 已经 commit。2.4 Global Coordinator 通知分布式事务的所有点进行 commit。3.FORGET PHASE：3.1 参与的
8、点通知 commit point site 他们已经完成 commit，commit point site 就能忘记（forget）这个事务。3.2 commit point site 在远程数据库上清除分布式事务信息。3.3 commit point site 通知 Global Coordinator 可以清除本地的分布式事务信息。3.4 Global Coordinator 清除分布式事务信息。有关分布式事务的详细信息请参阅 oracle 联机文档.当前的分布式事务处于 Two-Phase Commit 机制中的 prepared 阶段，这个阶段事务已经在表上加锁了，现在我们要访问这些表
9、，但事务没有结束，一直持有锁，导致访问资源失败报 ORA-01591。(在这里需要指出：分布式事务所持有的锁之所以堵塞读操作，是因为 oralce 不知道该显示哪个版本的数据) 如果结束这个事务，那相应的锁也会释放，这样就能解决这个问题。我们知道要结束一个事务有两种办法：commit 和 rollback。现在我们尝试结束这个事务：commit force 72.0.1608712;ORA-02058: no prepared transaction found with ID 72.0.1608712报错并没有发现 prepared 状态的事务，由于该事务是分布式事务，我们首先想到的是 db
10、a_2pc_pending 这个试图SQL select * from dba_2pc_pending;no rows selected该试图并没有查到信息，所以我们无法用 commit force 结束这个分布式事务，那么现在我们查看是否存在该事务，通过实际报错，我们可以清晰的看到事务号为 72.0.1608712，该事务在 72 号回滚段的 0 号事务槽上并且序列号是1608712，这时查询一个基表 x$ktuxe，看看 72 号回滚段上是否有该事务。SQL SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */2 KTUXEST
11、A Status,3 KTUXECFL Flags4 FROM x$ktuxe5 WHERE ktuxesta!=INACTIVE6 AND ktuxeusn= 72;KTUXEUSN KTUXESLT KTUXESQN STATUS FLAGS- - - - -72 0 1608712 PREPARED SCO|COL|REV|DEAD通过 x$ktuxe 这个基表，我们看到确实存在这个事务，而且是 prepared 状态。此时，我们基本清楚了这个问题的原因：当一个分布式事务死掉时，由于该事务没有正常结束，导致事务持有的锁一直没有释放，所以在访问这个事务涉及的资源时，申请不到锁资源，所以报
12、ORA-01591。由于是分布式事务，当在dba_2pc_pending 中查询不到事务信息时，我们是无法通过 commit 或者rollback 结束该事务。所以，我们目前的任务是模拟出这个分布式事务。由于 dba_2pc_pending 试图是依赖于 pending_trans$这个表，同时事务是与 session 关联在一起的，所以我们需要手工往 pending_trans$和 pending_sessions$两个表中插入数据。2.故障处理SQL alter system disable distributed recovery;系统已更改。SQL insert into pendin
13、g_trans$ (2 LOCAL_TRAN_ID,3 GLOBAL_TRAN_FMT,4 GLOBAL_ORACLE_ID,5 STATE,6 STATUS,7 SESSION_VECTOR,8 RECO_VECTOR,9 TYPE#,10 FAIL_TIME,11 RECO_TIME)12 values( 72.0.1608712, 13 306206, 14 XXXXXXX.12345.1.2.3, 15 prepared,P, 16 hextoraw( 00000001 ), 17 hextoraw( 00000000 ), 18 0, sysdate, sysdate );已创建 1
14、 行。SQL insert into pending_sessions$2 values( 72.0.1608712,3 1, hextoraw(05004F003A1500000104),4 C, 0, 30258592, ,5 1466 );已创建 1 行。SQL commit;提交完成。SQL alter system enable distributed recovery;系统已更改。此时，查询 dba_2pc_pending 发现已有该事务，并且状态是我们模拟出的prepared 状态SQL select * from dba_2pc_pending;LOCAL_TRAN_ID GL
15、OBAL_TRAN_ID STATE MIX A TRAN_COMMENTFAIL_TIME FORCE_TIME RETRY_TIME OS_USER OS_TERMINAL HOST DB_USERCOMMIT#-72.0.1608712 XXXXXXX.12345.1.2.3 prepared no12-11 月-08 12-11 月-08此时我们结束这个事务 SQL COMMIT FORCE 72.0.1608712;提交完成。再次查询 dba_2pc_pending,发现事务是 forced commit 状态，该事务已经结束。SQL select * from dba_2pc_pending;LOCAL_TRAN_ID GLOBAL_TRAN_ID STATE MIX A TRAN_COMMENTFAIL_TIME FORCE_TIME RETRY_TIME OS_USER OS_TERMINAL HOST DB_USER COMMIT#-72.0.1608712 XXXXXXX.12345.1.2.3 forced commit no12-11 月-08 12-11 月-08 12-11 月-08通过 x$kutxe 查询事务信息，发现事务释放了回滚段，事务已经结束。SQL SELECT KTUXEUSN, KT
