ORA-02049

来源:互联网 发布:德乌洛费乌赛季数据 编辑:程序博客网 时间:2024/06/11 09:43

        最近应用程序经常报ORA-02049: timeout: distributed transaction waiting for lock的错误

       

 

         

SQL> select * from v$transaction;

 

ADDR                XIDUSN   XIDSLOT    XIDSQN    UBAFIL    

---------------- ---------- ---------- ---------- ----------

070000007B5AC368         1         6     42735         3   

 

 

存在事务,该事务的标识是(1642735)。此时存在被锁定的对象。

 

 

SQL> select * from v$locked_object;

 

   XIDUSN   XIDSLOT    XIDSQN OBJECT_ID SESSION_ID ORACLE_USERNAME OS_USER_NAME      LOCKED_MODE

---------- ---------- ---------- ---------- ---------- --------------------------------- -----------

        1         6     42735    114245       181SYSMAN      3

 

 

v$lock_object中,可以看到当前事务锁定object_id=114245的对象,会话编号为sid=181,锁模式为共享锁模式。注意:此时user显示的是sysman的系统内置用户。

 

此时对象是存在的,也能确定锁对象确实存在。

 

 

SQL> select * from dba_objects where object_id=114245;

 

OWNER                         OBJECT_NAME 

------------------------------ ------------

NBS_COMMON                    BAT_LOCK    

 

 

SQL> select * from bat_lock for update nowait;

select * from bat_lock for update nowait

 

ORA-00054:资源正忙,但指定以NOWAIT方式获取资源,或者超时失效

 

 

下面进行sid=181检查,发现该会话是不存在v$session中的。也找不到对应的共享锁信息。

 

 

SQL> select count(*) from v$session where sid=181;

 

 COUNT(*)

----------

        0

 

SQL> select * from v$lock where id1=114245;

 

ADDR            KADDR                  SID TYPE     

---------------- ---------------- ---------- ----

 

 

最为诡异的情况是v$locked_object中,oracle_username不断的幻象读。

 

 

SQL> select * from v$locked_object;

 

   XIDUSN   XIDSLOT    XIDSQN OBJECT_ID SESSION_ID ORACLE_USERNAME              

---------- ---------- ---------- ---------- ---------- ------------------------------

        8        12     48826    114245       181                               

 

SQL> select * from v$locked_object;

 

   XIDUSN   XIDSLOT    XIDSQN OBJECT_ID SESSION_ID ORACLE_USERNAME              

---------- ---------- ---------- ---------- ---------- ------------------------------

        8        12     48826    114245       181   NBS                           

 

 

 

没有v$session信息就无法进行session级别的kill操作。同时,使用OS级别的Server Process kill操作也没有作用。Oracle始终不能对事务资源进行回收。

 

查询oracle 文档ID 338880.1

global transaction timeout < session timeout < distributed_lock_timeout

调整数据库distributed_lock_timeout时间,调大之后依然无法解决,出现更严重的锁对象

 

尝试2,将distributed_lock_timeout 调整回默认的60时,修改global transaction timeout的时间,将其改小,重启应用,到了设置的时间锁释放了。

实验说明,超过distributed_lock_timeout 60秒分布式事务可能会失败,但是锁还是无法释放,释放的时间由global transaction timeout接管

参考文档 http://space.itpub.net/17203031/viewspace-709661

                

Recommended Timeout Configuration When Using an External Transaction Processing Monitor and XA with Oracle [ID 338880.1]

 

结论:

          事务失败是否释放资源并不是数据库的distributed_lock_timeout,而是global transaction timeout的时间

         

 

 

 

 

 

原创粉丝点击