ORA-01591錯誤與分散式事務

perfychi發表於2012-09-10
 

下午,一個開發組長過來找到筆者,說一個表被鎖定,不能修改資料。開始以為是簡單的,開發階段由於工具使用的原因,經常發生鎖表的事件。查詢鎖定物件,定位鎖定人和機器之後,就可以了。

 

1、問題現象

 

但是實際情況,完全出乎筆者的想法。檢查一般物件資料表鎖定,只需要檢查v$locked_objectv$transaction檢視,就可以定位到具體人。但是檢查之後的結果如下:

 

 

SQL> select * from v$locked_object;

   XIDUSN   XIDSLOT    XIDSQN OBJECT_ID SESSION_ID

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

 

SQL> select * from v$transaction;

ADDR                XIDUSN   XIDSLOT    XIDSQN  

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

 

 

 

兩個關鍵檢視中,沒有鎖定的物件,也沒有正在進行沒有提交的事務。那是不是沒有鎖定呢?嘗試對資料表加鎖。

 

 

SQL> select * from nbs_common.inc_inputlog for update;

select * from nbs_common.inc_inputlog for update

 

ORA-01591:鎖被未決處理4.30.31555持有

 

SQL> select count(*) from nbs_common.inc_inputlog;

 COUNT(*)

----------

      426

 

 

 

系統沒有像一般阻塞那樣等待,而是報錯Ora-01591。並且提示鎖被一個分散式事務持有,不能實現加鎖操作。

 

看來是一個沒有見到過的新錯誤。

 

2、分析問題

 

Ora-01591錯誤究竟是什麼呢?我們使用oerr工具檢視該錯誤編號,看看有沒有值得關注的資訊。

 

 

[oracle@bspdev ~]$ oerr ora 01591

01591, 00000, "lock held by in-doubt distributed transaction %s"

// *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.

 

 

 

簡單的說,01591錯誤的原因是該物件被一個處在“in-doubt”狀態的分散式事務鎖定。分散式事務使用的是“two-phase commit”二階段提交。解決該問題的方法就是檢視內部表pending_trans$,確定分散式事務資訊。這種狀態的事務主要是由於在進行分散式事務時候,發生網路突發中斷的情況,引起分散式事務無法正常結束,等待中斷節點的事務響應。於是,各節點的事務所鎖定的表就不會被釋放掉。

 

 

此時,我們檢查檢視DBA_2PC_PENDING(或者基表pending_trans$),檢視是否存在這種情況。

 

 

SQL> select * from DBA_2PC_PENDING;

 

LOCAL_TRAN_ID   GLOBAL_TRAN_ID                      STATE           

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

4.30.31555  096044365.31302E312E33392E38392E746D30303034313030303237  Pepared

 

(篇幅原因,有省略……

 

果然,當前存在一個阻塞分散式事務,處在prepared狀態。

 

3、知識介紹

 

現代資料庫系統往往伴隨著複雜的結構和環境,其中分散式資料庫組成是一個重要方面。系統後臺的資料庫系統不再是由單個資料構成,而是由多臺獨立資料庫、甚至是多臺異構資料庫構成。這種情況下,分散式事務就是開發設計人員不能不面對的一個難題。

 

處理分散式事務的方案,有兩種趨勢。其一是藉助資料庫自身的分散式處理能力,如的分散式二階段提交模型,進行多個資料庫的分散式事務同步。其二是將分散式事務處理權交付給應用中間層,讓應用去處理分散式事務問題。

 

 

進行分散式事務的時候,使用的“二階段提交”模型,大致分為幾個過程。(參考:http://blog.itpub.net/post/38439/477038

 

ü        Prepare階段:多個資料庫的commit_point_strength進行比較,確定出一個資料庫作為commit point site。由全域性協調者(Global Coordinator)通知除了commit point site外所有節點準備好commitrollback。同時,各節點對事務相關資料表加鎖。之後,各個節點通知全域性協調者自己的SCN,選擇最大的那個SCN作為當前事務的SCN注意,從此刻開始,除了commit point site外,其他節點均進入in_double狀態;

ü        Commit階段:全域性協調者將確定好的最大SCN通知給commit point site,授權該節點進行commit操作。Commit point site進行事務commit/rollback之後,通知全域性協調者事務完成。全域性協調者通知其他所有節點進行commit操作;

ü        Forget階段:當各個節點結束事務之後,通知commit point site當前事務已經完成。當全部都完成了,commit point site開始清理分散式事務資訊,然後通知全域性協調者清理資訊。最後全域性協調者將最後清理掉本地的事務資訊;

 

 

當前問題,主要是源於在進入prepared階段之後,發生了網路中斷的現象,引起commit的階段不能等待到事務資訊。所以,才會一直處在Prepared狀態,資料表也就不會進行釋放。

 

4、問題解決

 

對於這個事務,只能透過連線網路或者強制提交回退事務來結束。我們可以使用commit force或者rollback force來進行處理。

 

 

SQL> rollback force '4.30.31555';

 

Rollback complete

 

 

Rollback force引數是DBA_2PC_PENDING中記錄本地事務資訊的編號。

 

此時,再次檢視資料。

 

 

SQL> select * from DBA_2PC_PENDING;

 

LOCAL_TRAN_ID   GLOBAL_TRAN_ID                          STATE  

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

4.30.31555 096044365.31302E312E33392E38392E746D30303034313030303237forced rollback   

 

 

此時,該事務狀態已經變化為forced rollback。已經強制回退。

 

 

SQL> select seq_number from nbs_common.inc_inputlog where rownum<2 for update;

 

   SEQ_NUMBER

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

            2

 

 

 

5、結論

 

這個故障解決,使我獲取到如下認識:

 

ü        系統一旦涉及到分散式資料庫,整體的複雜性就要提升很多。所以,要對分散式事務處理技術有非常成熟的認識和理解,而且要經過嚴格的測試;

ü        鎖表的現象多種,不同事務型別,檢視資訊的方式有所差異;

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/27042095/viewspace-743016/,如需轉載,請註明出處,否則將追究法律責任。

相關文章