I believe this is a bug. The first solution I saw was support telling people to convert their systems to using regular rollback segments but I believe that you can issue ' alter session set "_smu_debug_mode" = 4; ' to get around the problem. I do not have the bug number so before you alter your session you may want to check metalink on the hidden parameter. HTH -- Mark D Powell --
-- --Original Message-- -- From: oracle-l-bounce@(protected) [mailto:oracle-l-bounce@(protected)]On Behalf Of Tony.Adolph@(protected) Sent: Tuesday, February 08, 2005 11:55 AM To: oracle-l@(protected) Cc: Maxim.Demenko@(protected) Subject: lock held by in-doubt distributed transaction
Hi folks, One of our developers has just reported this error after a simple select:
select COUNT(*) FROM tracking.tracked_lacosa_request * ERROR at line 1: ORA-01591 (See ORA-01591.ora-code.com): lock held by in-doubt distributed transaction 4.18.4935
So I looked for the in doubt transaction as follows:
select * from dba_2pc_neighbors;
and
select * from dba_2pc_pending;
but both returned no rows.
I tried the same query and also get the same error. I bounced the database (immediate) and still get the error and all the time with the same transaction id 4.18.4935. I got the developers to bounce their jboss but no joy.
I tried dbms_transaction.purge_lost_db_entry:
SQL> exec dbms_transaction.purge_lost_db_entry('4.18.4935'); BEGIN dbms_transaction.purge_lost_db_entry('4.18.4935'); END;
