ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 2006-12-01 DB异常

2006-12-01 DB异常

原创 Linux操作系统 作者:yxyup 时间:2007-01-07 00:00:00 0 删除 编辑
在12月1号,偶的DB也中奖了,今天也总结一下。Alert.log错误信息如下
ORA-01555 caused by SQL statement below (Query Duration=1164947392 sec, SCN: 0x0001.8d562fb5):
Fri Dec 1 04:29:53 2006
SELECT formatid, globalid, branchid FROM SYS.DBA_PENDING_TRANSACTIONS ORDER BY form
atid, globalid, branchid
Fri Dec 1 04:29:53 2006
DISTRIB TRAN 28.74757834000000000000000000000000000000000000000000000000000000005A1505004E3D6F45EB060000
is local tran 43.10.180291 (hex=2b.0a.2c043)
change pending prepared tran, scn=6666207188 (hex=1.8d563fd4)
to pending collecting tran, scn=6666207188 (hex=1.8d563fd4)
...............
从google中找到如下解释
Check dba_2pc_pending table, you will see there is 1 row returned
with same local_tran_id as above: 3.65.429 , the status is collecting.
Remove the pending transaction by:
execute dbma_transaction.purge_lost_db_entry('3.65.429 ');
It should fix the error.

For some reason, the distributed transaction did not finish properly,
it ended with "collecting" status. The reco process tried to recover
the transaction periodicly but failed, thus error logged into alert log
and trace file. The best way to clean it is using above command.
=========================================================
Before you begin, make note of the local transaction ID, , from
the error message reported.
1. Determine if you can attempt a commit or rollback of this
transaction. You can do the following select to help determine what
action to take:
SQL> select state, tran_comment, advice from dba_2pc_pending
where local_tran_id = '';
Review the TRAN_COMMENT column as this could give more information
as to the origin of the transaction or what type of transaction it was.
Review the ADVICE column as well. Many applications prescribe advice
about whether to force commit or force rollback the distributed
transaction upon failure.
2. Commit or rollback the transaction.
To commit:
SQL> commit force '';
To rollback:
SQL> rollback force '';
WARNING: Step 3 (purge_lost_db_entry) and Step 4 should ONLY be used
when the other database is lost or has been recreated.
Any other use may leave the other database in an unrecoverable or
inconsistent state.

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7364032/viewspace-17446/,如需转载,请注明出处,否则将追究法律责任。

上一篇: Tahiti
请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-06

  • 博文量
    163
  • 访问量
    1348358