<form id="tznrh"><form id="tznrh"><th id="tznrh"></th></form></form>

            死鎖檢測

            Oracle RAC的死鎖檢測在多層完成,并且是由超時機制驅動。Oracle RAC 的死鎖檢測在多層完成,并且是由超時機制驅動。Oracle RAC 的死鎖檢測在多層完成,并且是由超時機制驅動。Oracle RAC 的死鎖檢測在多層完成,并且是由超時機制驅動。

             - ksq解決本地死鎖問題。

             - kjd解決全局死鎖問題。

             - 消息流量控制器(TRFC)預防消息的死鎖問題。

            在生產環境中涉及的資源和鎖的數量非常多,因此查找是否存在死鎖可能非常耗時消耗系統資源。因此,當有進程發生長時間的等待時,系統會認為很大概率是存在鎖死問題,Oracle內核會使用“when needed”方法來檢查死鎖。

            下圖顯示了經典的死鎖場景。我們常說的有問題的資源可以是任何對象。在服務器中,可以是行,表,ITL事務槽或library cache和dictionary cache lock。這種死鎖的情況也可能發生在RAC集群中,即進程位于不同的節點上也會有死鎖情況的發生,因為他們要訪問修改共同的資源。




            在這種情況下,兩個進程在不同的節點上,資源以主和影子方式分布在不同節點。很明顯,在多節點環境中,死鎖檢測需要跟蹤集群中所有節點間鎖的轉換和阻塞者。由前面系列文章我們可以知道這個動作由LMD進程執行。

            只要進程共享資源,就可能存在發生死鎖的情況。當用戶A以獨占模式持有資源Y,用戶B以獨占模式持有資源Z,并且兩個用戶都在申請對方持有的資源并且都不愿意放棄對所持資源的獨占鎖,簡單的死鎖就發生了。每當請求轉換鎖并且鎖無法在短時間內完成授權時,鎖管理器都會執行死鎖檢測。




            Timeout-Based死鎖檢測

            如果發生鎖轉換,則每個可能會變成死鎖的鎖都會掛在死鎖計時隊列中。

            當轉換超時后,死鎖檢測開始。

            超時由_lm_dd_interval參數決定(11g 12c為10s)。

            LMD每次只進行一個鎖的檢測動作。

            生成死鎖跟蹤trc和排隊信息。

            dd_ts_server【ddTS】資源(DI,0,0)必須保持在EX模式下才能執行死鎖搜索。

            死鎖檢測搜索嘗試查找等待環。它通過阻塞進程和正在等待的鎖構建轉換鎖的圖。在RAC環境下,這個等待環可能跨越多個節點。如果找到循環,則解決方案是將錯誤返回到等待環中的其中一個進程。如果死鎖環只發生在本地節點,則死鎖環中的最后一個進程是獲取錯誤的進程。如果死鎖環跨越節點,則啟動搜索的進程會收到錯誤。啟動死鎖檢測的超時是current_time +(60 + number_of_nodes / 2)秒。




            當數據庫啟動后,每個實例的LMD0進程都會以NULL模式鎖定資源(DI,0,0)。每個實例依次通過將此鎖從NULL轉換為X模式來執行死鎖檢測。每個死鎖檢測都受到時間限制(number_of_nodes_in_cluster / 2)min。如果在此期間未找到死鎖,則中止死鎖檢測以避免花費太多時間跟蹤死鎖構造死鎖信息。需要注意的是死鎖檢測也是分布式的。

            當鎖被移動到資源的轉換隊列時,此鎖會被加到死鎖隊列的末尾并且這個鎖將成為死鎖檢測的候選者。

            死鎖檢測涉及以下三個步驟:

             1.Deadlock search:構建等待圖表(WFG)。如果死鎖是跨多節點的,則多節點均會參與等待圖的構建。

             2.Deadlock Validation:如果發現死鎖,則涉及死鎖的節點都會搜證各自子等待圖中的每個鎖。

             3.Wait-for graph printing:如果上一步成功,則整個WFG會被打印輸出。

            鎖死處理流

            當入隊鎖進入轉換隊列并且它可能成為死鎖(TM,TX或UL)時,鎖信息也會被置于死鎖隊列中。然后開始計算死鎖檢測的時間,LMD0每五秒檢查一次死鎖隊列,如果死鎖隊列不為空,并且死鎖隊列頭部的鎖在隊列中的時間超過time_to_dd,則啟動死鎖搜索。否則,LMD0將死鎖隊列頭部的鎖定移動到尾部并返回到正?;顒?。

            如果在節點1上開始死鎖檢測,則LMD0將其對DI,0,0的鎖定從NULL轉換為EXCLUSIVE; 在整個集群中,只允許一個節點啟動DD。




            死鎖流:單節點

            當鎖死檢測在本地節點找到死鎖時,或者未找到死鎖或找到遠程實例死鎖發生在遠程節點,WFG生成結束。

            死鎖圖說明:

             ?(R1)具有鎖L1的資源,該資源由X1擁有并處于R1的轉換隊列中。

             ?(X11,X12,X13)表示Grant隊列上鎖的所有者的XID或者與L1鎖有沖突的處于R1的轉換隊列上的鎖所有者。

             ?(R132)資源是X13的一個鎖并且掛在轉換隊列中。

             ?(X1)X1是Grant隊列上的鎖的所有者或者與轉換隊列上的鎖R132有沖突的鎖所有者

             ?(黃色三角形)此處發現死鎖。




            死鎖流:兩個節點

            在發現遠程資源之后并且在LMD0結束其循環消息處理,在節點1上構建的WFG結束。

            死鎖圖:

             ?虛線資源是其他節點擁有的隊列的影子隊列。

             ?在節點1處,執行前面介紹到的WFG構造流程,直到它檢查鎖R132的持有者并發現X1在另一個節點上。

             ?節點1死鎖檢測將消息KJX_DEADLOCK_IND發送到節點2以繼續死鎖檢測。

             ?節點2構建相同的WFG。

             ?X1是Grant隊列上鎖的所有者或轉換隊列上的鎖R132有沖突的鎖所有者。

             ?發現死鎖。

            其他情況:

            節點2檢測得出沒有死鎖的結論:如果示例中X1沒有持有與其他用戶相沖突的鎖,在這種情況下,它向節點1發送BACKTRACK消息,要求進一步搜索或沒有死鎖得出結論。

            節點2可能會發現有資源存在于其他實例(如節點3)上,在這種情況下,它會發送KJX_DEADLOCK_IND消息以進行進一步的遠程處理。




            并行DML死鎖

            由事務標識符(XID)標識的鎖可能無法檢測具有相同XID的PDML操作的死鎖。當申請鎖并發現其涉及PDML時,API會通知IDLM(執行全局DD---kjd)。PDML事務的協調器使用CGS名稱服務發布跨區集(spanning set),Oracle使用CGS名稱服務來創建生成集標識(spanning set)。事務的跨區域集(spanning set)是發生此事務的節點進程列表。name =TX的<XID>  , value = <spanning set>.



            沃趣科技,讓客戶用上更好的數據庫技術!
            三分快3