【故障處理】分散式事務ORA-01591錯誤解決

【故障處理】分散式事務ORA-01591錯誤解決

1  BLOG文件結構圖

 

 

 

2  前言部分

2.1  導讀和注意事項

各位技術愛好者，看完本文後，你可以掌握如下的技能，也可以學到一些其它你所不知道的知識，~O(∩_∩)O~：

① 分散式事務的簡單概念

        ② ORA-01591錯誤解決

  Tips：

① 本文在ITpub（http://blog.itpub.net/26736162）、部落格園(http://www.cnblogs.com/lhrbest)和微信公眾號（xiaomaimiaolhr）有同步更新

② 文章中用到的所有程式碼，相關軟體，相關資料請前往小麥苗的雲盤下載（http://blog.itpub.net/26736162/viewspace-1624453/）

③ 若文章程式碼格式有錯亂，推薦使用搜狗、360或QQ瀏覽器，也可以下載pdf格式的文件來檢視，pdf文件下載地址：http://blog.itpub.net/26736162/viewspace-1624453/，另外itpub格式顯示有問題，可以去部落格園地址閱讀

④ 本篇BLOG中命令的輸出部分需要特別關注的地方我都用灰色背景和粉紅色字型來表示，比如下邊的例子中，thread 1的最大歸檔日誌號為33，thread 2的最大歸檔日誌號為43是需要特別關注的地方；而命令一般使用黃色背景和紅色字型標注；對程式碼或程式碼輸出部分的注釋一般採用藍色字型表示。

  List of Archived Logs in backup set 11

  Thrd Seq     Low SCN    Low Time            Next SCN   Next Time

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

  1    32      1621589    2015-05-29 11:09:52 1625242    2015-05-29 11:15:48

  1    33      1625242    2015-05-29 11:15:48 1625293    2015-05-29 11:15:58

  2    42      1613951    2015-05-29 10:41:18 1625245    2015-05-29 11:15:49

  2    43      1625245    2015-05-29 11:15:49 1625253    2015-05-29 11:15:53

 

[ZHLHRDB1:root]:/>lsvg -o

T_XDESK_APP1_vg

rootvg

[ZHLHRDB1:root]:/>

00:27:22 SQL> alter tablespace idxtbs read write;

 

====》2097152*512/1024/1024/1024=1G 

 

本文如有錯誤或不完善的地方請大家多多指正，ITPUB留言或QQ皆可，您的批評指正是我寫作的最大動力。

 

 

3  故障分析及解決過程

 

3.1  故障環境介紹

 

專案	source db
db 型別	RAC
db version	11.2.0.3
db 儲存	ASM
OS版本及kernel版本	AIX 64位 6.1.0.0

 

3.2  故障發生現象及報錯資訊

有同事發來錯誤：

 

 

執行一個update語句的時候報錯ORA-01591的錯誤。

 

3.3  故障分析及解決過程

這個錯誤是由於分散式事務引起，而不是普通的鎖引起的，檢查一般物件資料表鎖定，只需要檢查v$locked_object和v$transaction檢視，就可以定位到具體的SQL語句和操作人等資訊，但是檢查之後的結果如下：

SYS@oraLHR12>  select * from gv$locked_object;

 

no rows selected

 

SYS@oraLHR12> select * from gv$transaction;

 

no rows selected

兩個關鍵檢視中，沒有鎖定的物件，也沒有正在進行沒有提交的事務。那是不是沒有鎖定呢？或者鎖已經釋放了，我們嘗試對資料表加鎖：

SYS@oraLHR12> select * from LHR.LHRBOKBAL for update;

select * from LHR.LHRBOKBAL for update

                   *

ERROR at line 1:

ORA-01591: lock held by in-doubt distributed transaction 20.13.14721

 

SYS@oraLHR12> select count(1) from LHR.LHRBOKBAL;

 

  COUNT(1)

----------

  30998411

 

 

系統沒有像一般阻塞那樣等待，而是報錯ORA-01591的錯誤，並且提示鎖被一個分散式事務持有，不能實現加鎖操作,那麼ORA-01591錯誤究竟是什麼呢？我們使用oerr工具檢視該錯誤編號，看看有沒有值得關注的資訊。

root@ZFLHRRSP:/# oerr ora 1591

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$），檢視是否存在這種情況。

 

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

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

SYS@oraLHR12> rollback force '20.13.14721';

 

Rollback complete.

 

SYS@oraLHR12>

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

 

此時，再次檢視資料。

 

此時，該事務狀態已經變化為forced rollback表示已經強制回退,我們再次嘗試鎖定表操作：

16:25:31 SQL> select CURRENCY from tpcc.TPCCBOKBAL WHERE ROWNUM=1  for update;

CURRENCY

--------

001

Executed in 0.025 seconds

可以看出已經不報錯了，可以正常執行。

4  分散式事務相關知識點

分散式事務，簡單來說，是指一個事務在本地和遠端執行，本地需要等待確認遠端的事務結束後，進行下一步本地的操作。如通過dblink update遠端資料庫的一行記錄，如果在執行過程中網路異常，或者其他事件導致本地資料庫無法得知遠端資料庫的執行情況，此時就會發生in doublt的報錯。此時需要dba介入，且需要分多種情況進行處理。

Oracle會自動處理分佈事務，保證分佈事務的一致性，所有站點全部提交或全部回滾。一般情況下，處理過程在很短的時間內完成，根本無法察覺到。

但是，如果在commit或rollback的時候，出現了連線中斷或某個資料庫 站點CRASH的情況，則提交操作可能會無法繼續，此時DBA_2PC_PENDING和DBA_2PC_NEIGHBORS中會包含尚未解決的分佈事務。 對於絕大多數情況，當恢復連線或CRASH的資料庫重新啟動後，會自動解決分散式事務，不需要人工干預。只有分佈事務鎖住的物件急需被訪問，鎖住的回滾段阻止了其他事務的使用，網路故障或CRASH的資料庫的恢復需要很長的時間等情況出現時，才使用人工操作的方式來維護分散式事務。 手工強制提交或回滾將失去二層提交的特性，Oracle無法繼續保證事務的一致性，事務的一致性應由手工操作者保證

使用ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY，可以使Oracle不再自動解決分佈事務，即使網路恢復連線或者CRASH的資料庫重新啟動。

ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY恢復自動解決分佈事務。

 

5  兩個重要的檢視

5.1  DBA_2PC_PENDING

DBA_2PC_PENDING:列出所有的懸而未決的事務﹐此檢視在末填入懸而未決的事務之前是空的﹐解決這後也被清空。

列名	說明
LOCAL_TRAN_ID	本地事務標識﹐格式為integer.integer.ingeger。 當一個連線的local_tran_id和global_tran_id相同時﹐那麼該節點是該事務的全域性協調器。
GLOBAL_TRAN_ID	全域性事務標識,格式為﹕global_db_name.db_hex_id.local_tran_id,其中db_hex_id是用來標識資料庫八字元的十六進位制數﹐公共事各id在分散式事務的每個節點都是相同的。
STATE	下圖表進行說明
MIXED	“YES”意味著一部分事務已經在一個節點上提交﹐而在另一個節點上被回滾。
TRAN_COMMENT	事務的註釋﹐或者如果使用了事務命名﹐當事各被提交時﹐事務的名字就會出現在此處
Host	主機名
Commit#	已提交的事務的全域性提交數

 

DBA_2PC_PENDING的STATE列的說明

列值	說明
Connecting	通常情況下﹐只有全域性協調器和本地協調器才使用這個條目﹐節點在能夠決定它是否能夠準備好之前﹐要收集來自於其它資料庫服務的資訊。
Prepared	節點已準好﹐可能或者也可能沒有將已準備好的訊息通知本地協調器﹐但此時﹐該節點還沒有接收到提交的請求﹐仍保持著准許備好的狀態﹐控制著提交事務所必需的任何本地資源。
Commited	節點(任何型別)已經提交了事務﹐但該事務所包含的其它節點可能並沒有提交﹐也就是該事務在一個個或多個其它節點上仍然是懸而未決 。
Forced commit	DBA進行判斷後﹐可以強行提交未決的事務﹐如果一個事務由DBA在本地節點進行手動提交時﹐產生此專案
Forced abor(rollback)	DBA進行判斷後﹐可以強行回滾未決的事務﹐如果一個事務由DBA在本地節點進行手動回滾時﹐產生此專案

 

SELECT * FROM DBA_2PC_PENDING;

 

 

5.2  DBA_2PC_NEIGHBORS

DBA_2PC_NEIGHBORS:列出所有獲得的(從遠端客戶)和送出的(給遠端伺服器)懸而未決的事務﹐也表示該本地節點是不是事務的提交點站點。

列名	說明
LOCAL_TRAN_ID	同上
IN_OUT	獲得事務為IN﹐送出事務為OUT
Database	對獲得事務來說指本地節點資訊的客戶資料庫的名稱﹔對送出的事務來說指用於訪問遠端伺服器上資訊的資料庫連結的名稱
DBuser_owner	對獲得事務來說指遠端資料庫連結用於連線的本地賬戶﹔對於送出事務來說指該資料庫連結的擁有者。
INTERFACE	‘C’代表提交資訊﹐’N’表示已準備好狀態的一條訊息或是一條請求只讀提交的請求。 當’IN_OUT’為OUT時﹐’C’表示該連線的遠端的站點是提交點站點,並且知道是提交還是中斷。’N’表示本地節點正在通知遠端節點﹐說它已準備好。 當’IN_OUT’為IN時﹐‘C’表示本地節點或送出的遠端的一個資料庫是提交點站點﹐’N’表示本地節點正在通知遠端節點﹐說它已準備好。

 

---

---

About Me

............................................................................................................................... ● 本文作者：小麥苗，只專注於資料庫的技術，更注重技術的運用 ● 本文在itpub（http://blog.itpub.net/26736162）、部落格園（http://www.cnblogs.com/lhrbest）和個人微信公眾號（xiaomaimiaolhr）上有同步更新 ● 本文itpub地址：http://blog.itpub.net/26736162/viewspace-2122999/ ● 本文部落格園地址：http://www.cnblogs.com/lhrbest/p/5738544.html ● 本文pdf版及小麥苗雲盤地址：http://blog.itpub.net/26736162/viewspace-1624453/ ● 資料庫筆試面試題庫及解答：http://blog.itpub.net/26736162/viewspace-2134706/ ● QQ群：230161599     微信群：私聊 ● 聯絡我請加QQ好友(646634621)，註明新增緣由 ● 於 2016-08-02 09:00~2016-08-03 19:00 在魔都完成 ● 文章內容來源於小麥苗的學習筆記，部分整理自網路，若有侵權或不當之處還請諒解 ● 版權所有，歡迎分享本文，轉載請保留出處 ............................................................................................................................... 拿起手機使用微信客戶端掃描下邊的左邊圖片來關注小麥苗的微信公眾號：xiaomaimiaolhr，掃描右邊的二維碼加入小麥苗的QQ群，學習最實用的資料庫技術。

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