 |
|
ORA-01591: lock held by in-doubt distributed transaction
string tips
Oracle Error Tips by Burleson Consulting (S. Karam)
|
The Oracle docs note this on the
ora-01591 error:
- ORA-01591: lock held by
in-doubt distributed transaction string
-
-
Cause: Trying to
access resource that is locked by a dead two-phase commit
transaction that is in 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 default if given to issue a heuristic commit
or abort command to finalize the local portion of the
distributed transaction.
Oracle user David Brail questioned ORA-01591 in
Oracle MOSC, which was being thrown in his RDBMS Version 8.1.6 of
Solaris 2.6. The problem was occuring after attempting to run "in-doubt"
distributed transactions in which, "nce we have a transaction "in-doubt", other
transactions -- for instance, transactions that are trying to insert new rows
into the same table that the "in-doubt" transaction was trying to update -- fail
with error ORA-01591, "lock held by in-doubt distributed transaction". I don't
understand this, as I thought that Oracle primarily used row-level locking. I
could understand that from time to time the in-doubt transaction could be trying
to expand the tablespace or the index or something, but the behavior is so
consistent that it seems like something else is going on."
Melissa Holman of Oracle Support offered this
advice in finding the root probelm of ORA-01591:
It is difficult to say what is happening here without more information. I
would suggest generating a trace file for the ORA-1591 so that we will have
more detailed diagnostic information. Also, querying v$lock should
provide more information.
To set the event for the ORA-1591 trace, add this to the init.ora:
event = "1591 trace
name errorstack level 10"
The next time this error occurs, you will find a trace file in the
user_dump_dest.
