ORA-01591錯誤解決方案

摘要：
 
在訪問某些表的特定行時報ORA-01591錯誤
 
select * from BF_INCOME_EXPENSES_T
 
where account_id = 36816153
 
and user_id = 39964213
 
and city_code = '185'
 

ORA-01591: 鎖定已被有問題的分配交易處理72.0.1608712掛起

SQL> select count(*) from UNITELE.BI_MQSYNC_SOURCE_CONTROL_T1;

ORA-01591: 鎖定已被有問題的分配交易處理72.0.1608712掛起
 
由於該表是業務關鍵表，部分前台業務受到影響。
 
關鍵詞：ORA-01591 DBA_2PC_PENDING 分散式交易

1.故障分析
 
首先，在遇到ORA錯誤時，我們不可能知道每個ORA錯誤都是什麼意思，所以通過Oracle的聯機文檔查錯誤的cause和action可以讓我們初步瞭解該錯誤。
 
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.
 

Oracle對ORA-01591錯誤的描述是"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’該錯誤是由訪問一個處於prepared狀態的二階段事務所持有鎖的資源造成的。
 
下面簡單介紹一下分散式交易。
 
分散式交易，簡單來說，是指一個事務在本地和遠程執行，本地需要等待確認遠端事務結束後，進行下一步本地的操作。如通過dblink update遠端資料庫的一行記錄，如果在執行過程中網路異常，或者其他事件導致本機資料庫無法得知遠端資料庫的執行情況，此時就會發生in doublt的報錯。此時需要dba介入，且需要分多種情況進行處理。
 
分散式交易的Two-Phase Commit機制，會經曆3個階段：
 
1.PREPARE PHASE：
 
1.1 決定哪個資料庫為commit point site。（注，參數檔案中commit_point_strength值高的那個資料庫為commit point site）
 
1.2 全域協調者（Global Coordinator）要求所有的點（除commit point site外）做好commit或者rollback的準備。此時，對分散式交易的表加鎖。
 
1.3 所有分散式交易的節點將它的scn告知全域協調者。
 
1.4 全域協調者取各個點的最大的scn作為分散式交易的scn。
 
至此，所有的點都完成了準備工作，我們開始進入COMMIT PHASE階段，此時除commit point site點外所有點的事務均為in doubt狀態，直到COMMIT PHASE階段結束。
 
2.COMMIT PHASE：
2.1 Global Coordinator將最大scn傳到commit point site，要求其commit。
2.2 commit point嘗試commit或者rollback。分散式交易鎖釋放。
2.3 commit point通知Global Coordinator已經commit。
2.4 Global Coordinator通知分散式交易的所有點進行commit。
 
3.FORGET PHASE：
3.1 參與的點通知commit point site他們已經完成commit，commit point site就能忘記（forget）這個事務。
3.2 commit point site在遠端資料庫上清除分散式交易資訊。
3.3 commit point site通知Global Coordinator可以清除本地的分散式交易資訊。
3.4 Global Coordinator清除分散式交易資訊。
 
有關分散式交易的詳細資料請參閱oracle聯機文檔.
 
當前的分散式交易處於Two-Phase Commit機制中的prepared階段，這個階段事務已經在表上加鎖了，現在我們要訪問這些表，但事務沒有結束，一直持有鎖，導致訪問資源失敗報ORA-01591。(在這裡需要指出：分散式交易所持有的鎖之所以堵塞讀操作，是因為oralce不知道該顯示哪個版本的資料) 如果結束這個事務，那相應的鎖也會釋放，這樣就能解決這個問題。我們知道要結束一個事務有兩種辦法：commit和rollback。現在我們嘗試結束這個事務：
 
commit force '72.0.1608712';
 
ORA-02058: no prepared transaction found with ID 72.0.1608712
 

報錯並沒有發現prepared狀態的事務，由於該事務是分散式交易，我們首先想到的是dba_2pc_pending這個試圖
 

SQL> select * from dba_2pc_pending;
 
no rows selected
 
該試圖並沒有查到資訊，所以我們無法用commit force結束這個分散式交易，那麼現在我們查看是否存在該事務，通過實際報錯，我們可以清晰的看到事務號為72.0.1608712，該事務在72號復原段的0號事務槽上並且序號是1608712，這時查詢一個基表x$ktuxe，看看72號復原段上是否有該事務。
 
SQL> SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */
 
2 KTUXESTA Status,
 
3KTUXECFL Flags
 
4FROM x$ktuxe
 
5WHERE ktuxesta!='INACTIVE'
 
6 AND ktuxeusn= 72;
 

KTUXEUSNKTUXESLTKTUXESQN STATUSFLAGS
 
---------- ---------- ---------- ---------------- ------------------------
 
7201608712 PREPAREDSCO|COL|REV|DEAD
 
通過x$ktuxe這個基表，我們看到確實存在這個事務，而且是prepared狀態。
 

此時，我們基本清楚了這個問題的原因：當一個分散式交易死掉時，由於該事務沒有正常結束，導致事務持有的鎖一直沒有釋放，所以在訪問這個事務涉及的資源時，申請不到鎖資源，所以報ORA-01591。由於是分散式交易，當在dba_2pc_pending中查詢不到事務資訊時，我們是無法通過commit或者rollback結束該事務。
 
所以，我們目前的任務是類比出這個分散式交易。由於dba_2pc_pending試圖是依賴於pending_trans$這個表，同時事務是與session關聯在一起的，所以我們需要手工往pending_trans$和pending_sessions$兩個表中插入資料。
 

2.故障處理
 

SQL> alter system disable distributed recovery;
 

系統已更改。
 

SQL> insert into pending_trans$ (
 
2LOCAL_TRAN_ID,
 
3GLOBAL_TRAN_FMT,
 
4GLOBAL_ORACLE_ID,
 
5STATE,
 
6 STATUS,
 
7SESSION_VECTOR,
 
8RECO_VECTOR,
 
9TYPE#,
 
10FAIL_TIME,
 
11RECO_TIME)
 
12values( '72.0.1608712',

13306206,
 
14'XXXXXXX.12345.1.2.3',
 
15'prepared','P',
 
16hextoraw( '00000001' ),

17hextoraw( '00000000' ),
 
180, sysdate, sysdate );
 

已建立 1 行。
 

SQL> insert into pending_sessions$
 
2values( '72.0.1608712',
 
31, hextoraw('05004F003A1500000104'),
 
4'C', 0, 30258592, '',
 
5146
 
6);
 

已建立 1 行。
 

SQL> commit;
 

提交完成。
 
SQL> alter system enable distributed recovery;
 

系統已更改。
 

此時，查詢dba_2pc_pending發現已有該事務，並且狀態是我們類比出的prepared狀態
 
SQL> select * from dba_2pc_pending;
 
LOCAL_TRAN_IDGLOBAL_TRAN_ID STATEMIX A TRAN_COMMENTFAIL_TIMEFORCE_TIME RETRY_TIME OS_USER
 
OS_TERMINAL HOSTDB_USER
 
COMMIT#
 
----------------
 
72.0.1608712XXXXXXX.12345.1.2.3 prepared no12-11月-0812-11月-08
 

此時我們結束這個事務
 
SQL> COMMIT FORCE '72.0.1608712';
 

提交完成。
 

重新查詢dba_2pc_pending,發現事務是forced commit狀態，該事務已經結束。
 
SQL> select * from dba_2pc_pending;
 

LOCAL_TRAN_IDGLOBAL_TRAN_ID STATEMIX A TRAN_COMMENTFAIL_TIMEFORCE_TIME RETRY_TIME OS_USER
 
OS_TERMINALHOSTDB_USER COMMIT#
 
----------------
 
72.0.1608712XXXXXXX.12345.1.2.3 forced commitno12-11月-08 12-11月-08 12-11月-08
 

通過x$kutxe 查詢事務資訊，發現事務釋放了復原段，事務已經結束。
 
SQL> SELECT KTUXEUSN, KTUXESLT, KTUXESQN, /* Transaction ID */
 
2KTUXESTA Status,
 
3KTUXECFL Flags
 
4FROM x$ktuxe
 
5WHERE ktuxesta!='INACTIVE'
 
6AND ktuxeusn= 72;
 

未選定行
 

此時，我們需要清除dba_2pc_pending中分散式交易的殘餘資訊
 
SQL> alter session set "_smu_debug_mode"=4;―― 在session層級設定復原段處於手工管理員模式，如果不設定這個參數，在復原段自動管理員模式下，清除事務資訊會報錯
 
會話已更改。
 

SQL> execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('72.0.1608712');――用dbms包清除事務資訊
 

PL/SQL 過程已成功完成。
 

SQL> select * from dba_2pc_pending;
 

未選定行
 

測試訪問業務表
 
SQL> select count(*) from UNITELE.BI_MQSYNC_SOURCE_CONTROL_T1;
 

COUNT(*)
 
----------
 
367
 
問題解決。
 

其實，我在另外一個客戶處也碰到過類似問題，當時也是報ORA-01591，但是在dba_2pc_pending中可以查到prepared狀態的事務，此時只需要commit force結束這個事務，並清除事務資訊就可以了。對於上面的案例，我懷疑開發商直接清除了分散式交易資訊，但是事務並沒有結束，導致鎖資源得不到釋放報ORA-01591。

總結：ORA-01591錯誤一般是由於分散式交易造成的，造成分散式交易失敗的原因主要是庫之間的網路突然中斷，造成兩個庫中的事務資訊不一致，所以會有殘餘的分散式交易資訊。此時，要針對不同的事務狀態做不同的處理。同時在遇到棘手的問題時，可以查詢metalink，該案例參��metalink文檔：NOTE:401302.1
[@more@]