詳解Oracle數(shù)據(jù)庫(kù)分布式事務(wù)ORA-01591錯(cuò)誤解決方法

作者：波波說(shuō)運(yùn)維 2019-10-27 23:10:33
數(shù)據(jù)庫(kù)
Oracle
分布式 最近在update某張表時(shí)突然提示了個(gè)比較少見的錯(cuò)誤，ORA-01591,這個(gè)問題跟平時(shí)的鎖還有點(diǎn)不一樣，下面一起來(lái)看看吧。

讓客戶滿意是我們工作的目標(biāo)，不斷超越客戶的期望值來(lái)自于我們對(duì)這個(gè)行業(yè)的熱愛。我們立志把好的技術(shù)通過(guò)有效、簡(jiǎn)單的方式提供給客戶，將通過(guò)不懈努力成為客戶在信息化領(lǐng)域值得信任、有價(jià)值的長(zhǎng)期合作伙伴，公司提供的服務(wù)項(xiàng)目有：域名注冊(cè)、雅安服務(wù)器托管、營(yíng)銷軟件、網(wǎng)站建設(shè)、清河門網(wǎng)站維護(hù)、網(wǎng)站推廣。

最近在update某張表時(shí)突然提示了個(gè)比較少見的錯(cuò)誤，ORA-01591,這個(gè)問題跟平時(shí)的鎖還有點(diǎn)不一樣，下面一起來(lái)看看吧~

思路

這個(gè)錯(cuò)誤是由于分布式事務(wù)引起，而不是普通的鎖引起的，檢查一般對(duì)象數(shù)據(jù)表鎖定，只需要檢查v$locked_object和v$transaction視圖，就可以定位到具體的SQL語(yǔ)句和操作人等信息。

  
 
 
 

   
  
  
  
select * from gv$locked_object; 
   
  
  
  
select * from gv$transaction; 
  
 
 
 

使用oerr工具查看該錯(cuò)誤編號(hào)

  
 
 
 

   
  
  
  
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. 
  
 
 
 

簡(jiǎn)單的說(shuō)，01591錯(cuò)誤的原因是該對(duì)象被一個(gè)處在“in-doubt”狀態(tài)的分布式事務(wù)鎖定。分布式事務(wù)使用的是“two-phase commit”二階段提交技術(shù)。解決該問題的方法就是查看內(nèi)部表pending_trans$，確定分布式事務(wù)信息。這種狀態(tài)的事務(wù)主要是由于在進(jìn)行分布式事務(wù)時(shí)候，發(fā)生網(wǎng)絡(luò)突發(fā)中斷的情況，引起分布式事務(wù)無(wú)法正常結(jié)束，等待中斷節(jié)點(diǎn)的事務(wù)響應(yīng)。于是，各節(jié)點(diǎn)的事務(wù)所鎖定的表就不會(huì)被釋放掉。

處理方法

  
 
 
 

   
  
  
  
rollback force '20.13.14721'; 
  
 
 
 

Rollback force的參數(shù)是DBA_2PC_PENDING中記錄本地事務(wù)信息的編號(hào)即LOCAL_TRAN_ID。

處理還是比較簡(jiǎn)單的，這里順便分享下分布式事務(wù)的相關(guān)知識(shí)點(diǎn)。

分布式事務(wù)相關(guān)知識(shí)點(diǎn)

分布式事務(wù)，簡(jiǎn)單來(lái)說(shuō)，是指一個(gè)事務(wù)在本地和遠(yuǎn)程執(zhí)行，本地需要等待確認(rèn)遠(yuǎn)程的事務(wù)結(jié)束后，進(jìn)行下一步本地的操作。如通過(guò)dblink update遠(yuǎn)程數(shù)據(jù)庫(kù)的一行記錄，如果在執(zhí)行過(guò)程中網(wǎng)絡(luò)異常，或者其他事件導(dǎo)致本地?cái)?shù)據(jù)庫(kù)無(wú)法得知遠(yuǎn)程數(shù)據(jù)庫(kù)的執(zhí)行情況，此時(shí)就會(huì)發(fā)生in doublt的報(bào)錯(cuò)。此時(shí)需要dba介入，且需要分多種情況進(jìn)行處理。

Oracle會(huì)自動(dòng)處理分布事務(wù)，保證分布事務(wù)的一致性，所有站點(diǎn)全部提交或全部回滾。一般情況下，處理過(guò)程在很短的時(shí)間內(nèi)完成，根本無(wú)法察覺到。

但是，如果在commit或rollback的時(shí)候，出現(xiàn)了連接中斷或某個(gè)數(shù)據(jù)庫(kù) 站點(diǎn)CRASH的情況，則提交操作可能會(huì)無(wú)法繼續(xù)，此時(shí)DBA_2PC_PENDING和DBA_2PC_NEIGHBORS中會(huì)包含尚未解決的分布事務(wù)。 對(duì)于絕大多數(shù)情況，當(dāng)恢復(fù)連接或CRASH的數(shù)據(jù)庫(kù)重新啟動(dòng)后，會(huì)自動(dòng)解決分布式事務(wù)，不需要人工干預(yù)。只有分布事務(wù)鎖住的對(duì)象急需被訪問，鎖住的回滾段阻止了其他事務(wù)的使用，網(wǎng)絡(luò)故障或CRASH的數(shù)據(jù)庫(kù)的恢復(fù)需要很長(zhǎng)的時(shí)間等情況出現(xiàn)時(shí)，才使用人工操作的方式來(lái)維護(hù)分布式事務(wù)。 手工強(qiáng)制提交或回滾將失去二層提交的特性，Oracle無(wú)法繼續(xù)保證事務(wù)的一致性，事務(wù)的一致性應(yīng)由手工操作者保證

使用ALTER SYSTEM DISABLE DISTRIBUTED RECOVERY，可以使Oracle不再自動(dòng)解決分布事務(wù)，即使網(wǎng)絡(luò)恢復(fù)連接或者CRASH的數(shù)據(jù)庫(kù)重新啟動(dòng)。

ALTER SYSTEM ENABLE DISTRIBUTED RECOVERY恢復(fù)自動(dòng)解決分布事務(wù)。

兩個(gè)重要的視圖

1. DBA_2PC_PENDING

DBA_2PC_PENDING:列出所有的懸而未決的事務(wù)﹐此視圖在末填入懸而未決的事務(wù)之前是空的﹐解決這后也被清空。

DBA_2PC_PENDING的STATE列的說(shuō)明

SELECT * FROM DBA_2PC_PENDING;

2. DBA_2PC_NEIGHBORS

DBA_2PC_NEIGHBORS:列出所有獲得的(從遠(yuǎn)程客戶)和送出的(給遠(yuǎn)程服務(wù)器)懸而未決的事務(wù)﹐也表示該本地節(jié)點(diǎn)是不是事務(wù)的提交點(diǎn)站點(diǎn)。

文章名稱：詳解Oracle數(shù)據(jù)庫(kù)分布式事務(wù)ORA-01591錯(cuò)誤解決方法
網(wǎng)頁(yè)網(wǎng)址：http://www.dlmjj.cn/article/cdodjoc.html