今天上午碰到一個報錯：

ORA-02049:timeout:distributed transaction waiting for lock

但是并未對業務造成實際影響，過了一段時間后好了。因為那段時間，用戶連續做了100筆的核銷業務。

【經查】

ORA-02049錯誤說明如下:

ORA-02049:timeout:distributed transaction waiting for lock

cause:exceeded INIT.ORA distributed_lock_timeout seconds waiting for lock.

action:treat as a deadlock.

【解決】

1、先查是否又死鎖出現：

SELECT l.session_id sid, s.serial#, l.locked_mode,l.oracle_username,

l.os_user_name,s.machine, s.terminal, o.object_name, s.logon_time

FROM v$locked_object l, all_objects o, v$session s

WHERE l.object_id = o.object_id

AND l.session_id = s.sid

ORDER BY sid, s.serial#;

有的話可以根據業務實際情況考慮殺掉，恢復正常業務

alter system kill session 'sid,serial#';

2、再查一個參數distributed_lock_timeout，可以考慮是否需要調優

最好不要去調這個參數，除非業務被影響到，并且通過應用程序無法避免這個問題

2.17 ORACLE distributed_lock_timeout

2.17.1 參數出處ORACLE初始參數文件：init.ora -> distributed_lock_timeout。

2.17.2 時間單位

秒。

2.17.3 取值范圍

大于0。

2.17.4 默認取值

60 。

2.17.5 用途解釋

分布式事務鎖等待超時(distributed transaction waiting for lock)，指第二個事務處理需要的數據庫資源，正被第一個分布式事務占用而鎖定，那么，第二個事務將等待第一個分布式事務釋放此資源，等待distributed_lock_timeout時間后，如果第一分布式事務仍然沒有釋放此資源，第二個事務觸發此超時。

2.17.6 超時后果

如果資源被第一個事務正常使用鎖定，ORACLE回滾第二個事務，并返回錯誤："ORA-02049: time-out: distributed transaction waiting for lock "。

如果第一個事務處理完成，資源釋放后，再嘗試第二個事務，就會成功。如果第二個事務不能等待資源自動釋放，那么可以采用處理數據庫死鎖(deadlock)的措施，人工介入，清除第一個事務，但一般不建議采用這種方式，因為第一個事務一般會正常結束的。

如果資源被第一個事務因為處于不確定分布事務狀態(in-doubt distributed transaction)而鎖定，ORACLE回滾第二個事務，并返回錯誤："ORA-01591: lock held by in-doubt distributed transaction identifier "。

這種錯誤遇到的可能性較小，一般只有在分布事務的關鍵提交階段出現網絡、系統故障，才可能出現此故障，而且，當網絡、系統故障恢復后，ORACLE一般可以自己解決此問題，不需要人工介入。如果一定要人工介入，可以查閱ORACLE專門的手冊。

2.17.7 設置考慮

出現這樣的超時，是因為特定數據庫資源的使用碰撞，要分析應用系統的業務特點，確定碰撞可能發生的條件，在此條件下，資源可能被先來者鎖定多長時間(T1)，后來者又能夠等多長時間(T2)，再來設置此參數(T)的大小。如果在大多數情況下，T1 < T2, 那么就設置T1 < T < T2；反之，大多數情況下，T1 > T2，那么，就設置T < T2。

因此，不分析業務特點，一味的增大和減小是不恰當的。

【這篇文章前面的部分也可以看一下的】

總結

以上是生活随笔為你收集整理的oracle locked time,ORACLE distributed_lock_timeout参数的全部內容，希望文章能夠幫你解決所遇到的問題。

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