識別和解決Oracle ITL死鎖

我有一個Oracle數據庫包，經常導致我認爲是ITL（Interested Transaction List）的死鎖。跟蹤文件的相關部分如下。識別和解決Oracle ITL死鎖

Deadlock graph: 
         ---------Blocker(s)-------- ---------Waiter(s)--------- 
Resource Name   process session holds waits process session holds waits 
TM-0000cb52-00000000  22  131   S  23  143   SS 
TM-0000ceec-00000000  23  143 SX    32  138 SX SSX 
TM-0000cb52-00000000  30  138 SX    22  131   S 
session 131: DID 0001-0016-00000D1C session 143: DID 0001-0017-000055D5 
session 143: DID 0001-0017-000055D5 session 138: DID 0001-001E-000067A0 
session 138: DID 0001-001E-000067A0 session 131: DID 0001-0016-00000D1C 
Rows waited on: 
Session 143: no row 
Session 138: no row 
Session 131: no row

該表沒有位圖索引，所以這不是原因。據我所知，缺乏「等待行」加上服務員等待列中的「S」可能表明這是ITL的僵局。此外，該表經常寫入（大約8次插入或更新，每分鐘240次），所以ITL的死鎖似乎是一種很強的可能性。

我增加了表的INITRANS參數，它的索引爲100，並將表上的PCT_FREE從10增加到20（然後重建索引），但死鎖仍在發生。僵局似乎在更新過程中最常發生，但這可能只是一個巧合，因爲我只追蹤了它幾次。

我的問題是雙重的：
1）這實際上是ITL的僵局嗎？
2）如果這是ITL僵局，還有什麼可以避免呢？

事實證明，這根本不是ITL的死鎖問題，而是未索引的外鍵問題。我發現這要歸功於dpbradley的回答，這讓我意識到這不是ITL問題，並促使我找出導致「無行」的死鎖的其他原因。

來源

2010-05-24 Allan

你可能要考慮發佈這在serverfault。我最初的反應是這就是它所屬的地方，但這個問題也有一個編程風格。無論如何，你可能會在那裏找到另一雙不在這裏的眼睛。 – DCookie 2010-05-24 18:11:29

ITL壓力的最佳指示是從性能的觀點：

select event, total_waits, time_waited, average_wait 
from v$system_event 
where event like 'enq: TX%' 
order by 2 desc;

示出了TX等待爭用，和

select OBJECT_NAME, SUBOBJECT_NAME, TABLESPACE_NAME, 
     OBJECT_TYPE, STATISTIC_NAME, VALUE 
    from v$segment_statistics 
    where statistic_name = 'ITL waits' 
    and value > 0 
    order by value desc;

示出了所涉及的表和索引。

（像所有v$的意見，結果是在當實例啓動的時間點。）

如果這說明你確實有ITL等待，那麼INITRANS和PCTFREE參數是主旋鈕（但INITRANS = 100對我來說聽起來相當高，而且這些確實佔用了空間）。

如果ITL等待不成問題，那麼需要檢查應用程序代碼。

來源

2010-05-25 13:58:48 dpbradley

第一個查詢顯示23000+「enq：TX - 爭用」等待，但第二個查詢僅顯示1個ITL等待（對於沒有看到死鎖的表的索引）。如果我理解正確，這似乎表明這實際上不是ITL的僵局？ – Allan 2010-05-25 14:43:00

是的，我從你的編輯中看到，你已經發現了潛在的問題。未索引的FK可以肯定是一個鎖定問題 - 有大量的腳本浮動，會報告架構中未索引的外鍵。 – dpbradley 2010-05-25 16:30:56

最好的選擇是根據需要增加它（從默認值10開始並增加10）。如果您看到ITL等待中的減少，那麼您已設置好了。通常，這些相關參數在Oracle和SQL Server中均通過反覆試驗進行調整。除非資源非常繁忙，否則實時調整這些參數並不是什麼大問題。您可以使用下面的查詢每個增量後，看到的，如果ITL等待要麼消失或大大降低：

SELECT t.OWNER, t.OBJECT_NAME, t.OBJECT_TYPE, t.STATISTIC_NAME, t.VALUE 
    FROM v$segment_statistics t 
    WHERE t.STATISTIC_NAME = 'ITL waits' AND t.VALUE > 0 
    ORDER BY t.value desc;

我們已經進行了由於ITL幾個調音爲Oracle死鎖情況使用此方法將等待。注：確保索引被重建，如果initrans被修改爲索引。還要確保統計數據不會失效。

爲了快速檢查SQL Tuning Advisor可以用來查看查詢/索引和統計的完整狀態。

來源

2013-05-28 23:51:37

識別和解決Oracle ITL死鎖

回答

相關問題