修改時間?21-NOV-2011?????類型?BULLETIN?????狀態?PUBLISHED

?

Applies to:

Oracle Server - Enterprise Edition - Version: 8.1.5.0 to 11.1.0.6 - Release: 8.1.5 to 11.1
Information in this document applies to any platform.

Purpose

The purpose of this bulletin is to assist support analysts in understanding and?
resolving the stranded dba_2pc_entries.

Scope and Application

The intended audience are support analysts having good experience on distributed
databases.

How To Resolve Stranded DBA_2PC_PENDING Entries

set transaction use rollback segment SYSTEM;
delete from sys.pending_trans$ where local_tran_id = ;
delete from sys.pending_sessions$ where local_tran_id = ;
delete from sys.pending_sub_sessions$ where local_tran_id = ;
commit;

Example:
--------
The following query reports a dist. txn. in prepared state
select local_tran_id, state from dba_2pc_pending;
LOCAL_TRAN_ID STATE
---------------------- ----------------
1.92.66874 prepared

Given that a transaction id is composed of triple,
'1.92.66874' is located in rollback segment# 1. To find out the list of
active transactions in that rollback segment, use:

SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */
KTUXESTA Status,
KTUXECFL Flags
FROM x$ktuxe
WHERE ktuxesta!='INACTIVE'
AND ktuxeusn= 1; <== this is the rollback segment#

no rows selected

It is not possible to rollback force or commit force this transaction.



rollback force '1.92.66874';

ORA-02058: no prepared transaction found with ID 1.92.66874

Hence, we have to manually cleanup that transaction:



set transaction use rollback segment SYSTEM;

delete from sys.pending_trans$
where local_tran_id = '1.92.66874';

delete from sys.pending_sessions$ where local_tran_id = '1.92.66874';

delete from sys.pending_sub_sessions$ where local_tran_id = '1.92.66874';

commit;


2.2 Distributed transaction without corresponding dba_2pc entries

In this case dba_2pc views are empty but users are receiving distributed txn
related errors, e.g. ORA-2054, ORA-1591. Normally such a case should not appear
and if it is reproducible a bug should be filed. Here is the list of several
alternative solutions that can be used in this case:

a. Perform. incomplete recovery
b. Truncate the objects referenced by that transaction and import them
c. Use _corrupted_rollback_segments parameter to drop that rollback segment
d. Insert dummy entries into dba_2pc views and either commit or rollback
force the distributed transaction

The first three solutions are discussed in Backup and Recovery manuals and in
the notes referred above. In the 4th solution a dummy entry is inserted into
the dictionary so that the transaction can be manually committed or rolled back.
Note that RECO will not be able to process this txn and distributed txn recovery
should be disabled before using this method. Furthermore, please take a BACKUP
of your database before using this method.

The stranded entries is the cause of ORA-01591 so we need to
clear the stranded entries by purging them using

execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('transanction_id');


The following example describes how to diagnose and resolve this case. Suppose
that users are receiving



ORA-1591: lock held by in-doubt distributed transaction 1.92.66874

and the following query returns no rows:



select local_tran_id, state from dba_2pc_pending
where local_tran_id='1.92.66874';

no rows selected

Furthermore querying the rollback segment shows that 1.92.66874 remains in
prepared state



SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */
KTUXESTA Status,
KTUXECFL Flags
FROM x$ktuxe
WHERE ktuxesta!='INACTIVE'
AND ktuxeusn= 1; /* <== Replace this value with your txn undo seg#
Which is displayed in the first part of
the transaction ID */

KTUXEUSN KTUXESLT KTUXESQN STATUS FLAGS
---------- ---------- ---------- ---------------- ------------------------
1 92 66874 PREPARED SCO|COL|REV|DEAD


Trying to manually commit or rollback this transaction



commit force '1.92.66874';

ORA-02058: no prepared transaction found with ID 1.92.66874

raises ORA-02058 since dba_2pc views are empty. In order to use commit force or
rollback force a dummy record should be inserted into pending_trans$ as follows:



alter system disable distributed recovery;

insert into pending_trans$ (
LOCAL_TRAN_ID,
GLOBAL_TRAN_FMT,
GLOBAL_ORACLE_ID,
STATE,
STATUS,
SESSION_VECTOR,
RECO_VECTOR,
TYPE#,
FAIL_TIME,
RECO_TIME)
values( '1.92.66874', /* <== Replace this with your local tran id */
306206, /* */
'XXXXXXX.12345.1.2.3', /* These values can be used without any */
'prepared','P', /* modification. Most of the values are */
hextoraw( '00000001' ), /* constant. */
hextoraw( '00000000' ), /* */
0, sysdate, sysdate );

insert into pending_sessions$
values( '1.92.66874',/* <==Replace only this with your local tran id */
1, hextoraw('05004F003A1500000104'),
'C', 0, 30258592, '',
146
);

commit;

commit force '1.92.66874';

If commit force raises an error then note the errormessage and execute the
following:


delete from pending_trans$ where local_tran_id='1.92.66874';
delete from pending_sessions$ where local_tran_id='1.92.66874';
commit;
alter system enable distributed recovery;

Otherwise run purge the dummy entry from the dictionary, using

alter system enable distributed recovery;
connect / as sysdba
COMMIT;
Use following query to retrieve the value for such _smu_debug_mod parameter:

col Parameter for a20
col "Session Value" for a20
col "Instance Value" for a20

SELECT a.ksppinm "Parameter",b.ksppstvl "Session Value",c.ksppstvl "Instance Value"
FROM x$ksppi a, x$ksppcv b, x$ksppsv c
WHERE a.indx = b.indx AND a.indx = c.indx AND a.ksppinm = '_smu_debug_mode'
/


-- set it temporarily to 4:


alter system set "_smu_debug_mode" = 4; /* if automatic undo management
is being used */
-- in 9.2x alter session can be used instead.

commit; /* this is to prevent the ORA-01453 in purge_lost_db_entry call */

exec dbms_transaction.purge_lost_db_entry( '1.92.66874' );

SQL> commit;

SQL> alter system set "_smu_debug_mode" = ;

SQL> commit;


2.3 How to PURGE the DISTRIBUTED transaction in PREPARED state, when COMMIT
or ROLLBACK FORCE hangs ?, where we have entries for both Distributed
transaction and dba_2pc entries.


ORA-01591: lock held by in-doubt distributed transaction 44.88.85589

The row exist from dba_2pc_pending & Rollback segment



SQL> SELECT LOCAL_TRAN_ID,STATE FROM DBA_2PC_PENDING;

LOCAL_TRAN_ID STATE
----------------- -----------
44.88.85589 prepared


SQL> SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */
KTUXESTA Status,
KTUXECFL Flags
FROM x$ktuxe
WHERE ktuxesta!='INACTIVE'
AND ktuxeusn= 44; /* <== Replace this value with your txn undo seg#
Which is displayed in the first part of
the transaction ID */

KTUXEUSN KTUXESLT KTUXESQN STATUS FLAGS
---------- ---------- ---------- ---------------- ------------------------
44 88 85589 PREPARED SCO|COL|REV|DEAD


SQL> Commit force 44.88.85589;
SQL> rollback force 44.88.85589;

Executing COMMIT or ROLLBACK FORCE hangs

The wait event is ""free global transaction table entry"


Purging the transaction should fail with below error:



EXECUTE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('44.88.85589');
BEGIN DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('44.88.85589'); END;

*
ERROR at line 1:
ORA-06510: PL/SQL: unhandled user-defined exception
ORA-06512: at "SYS.DBMS_TRANSACTION", line 94
ORA-06512: at line 1


Solution:
--------

You have to implement both the solution :

2.1 Dba_2pc entries without a corresponding transaction
2.2 Distributed transaction without corresponding dba_2pc entries

1.

delete from sys.pending_trans$ where local_tran_id = '44.88.85589';
delete from sys.pending_sessions$ where local_tran_id = '44.88.85589';
delete from sys.pending_sub_sessions$ where local_tran_id ='44.88.85589';
commit;

2. Now insert the dummy record as explained in section:

2.2 Distributed transaction without corresponding dba_2pc entries
commit;

3. Commit force '44.88.85589'

4. Purge the transaction:

exec dbms_transaction.purge_lost_db_entry('44.88.85589');


Note:126069.1 Manually Resolving In-Doubt Transactions: Different Scenario's

Still have questions ?

To discuss this information further with Oracle experts and industry peers, we encourage you to review, join or start a discussion via My Oracle Support?Streams and Distributed Database Community

References

NOTE:100664.1?- Master Note for Troubleshooting Oracle Managed Distributed Transactions
NOTE:126069.1?- Manually Resolving In-Doubt Transactions: Different Scenarios

?相關內容 產品 Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition 關鍵字 DBA_2PC_NEIGHBORS; DBA_2PC_PENDING; DBMS_TRANSACTION; DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY; DISTRIBUTED; IN-DOUBT; PURGE; TRANSACTION 錯誤 ORA-2054; ORA-2058; ORA-1591; ORA-6512; ORA-1453; ORA-6510

返回頁首

來自 “ ITPUB博客 ” ，鏈接：http://blog.itpub.net/38267/viewspace-713103/，如需轉載，請注明出處，否則將追究法律責任。

轉載于:http://blog.itpub.net/38267/viewspace-713103/

總結

以上是生活随笔為你收集整理的How To Resolve Stranded DBA_2PC_PENDING Entries [ID 401302.1]的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。