目錄?? 前言我們在使用 oracle 數(shù)據(jù)庫時,有時候會碰到需要使用分布式事務(wù),并且會碰到一些報錯! ?? 分布式事務(wù)當(dāng)需要在多個Oracle數(shù)據(jù)庫之間進(jìn)行數(shù)據(jù)一致性操作時,就會用到分布式事務(wù)。 例如: insert into T_log@remote_db; --遠(yuǎn)程數(shù)據(jù)庫插入insert into T_local; --本地數(shù)據(jù)庫插入commit; 分布在本地和遠(yuǎn)程兩個db的事務(wù)同時操作,這就構(gòu)成了一個分布式事務(wù)。 分布式事務(wù)采用 在這種機(jī)制下,事務(wù)處理過程分為三個階段:
各關(guān)聯(lián)節(jié)點(diǎn)此時會做三個事情:刷新redo信息到redo log中;將持有的鎖轉(zhuǎn)換為懸疑事務(wù)鎖;取各節(jié)點(diǎn)中最大的SCN號進(jìn)行同步! ?? 常見錯誤以下是三種常見的分布式事務(wù)問題場景:
通過報錯會有提示,例如: ORA-01591: lock held by in-doubt distributed transaction 10.20.360 這個10.20.360就是我們需要檢查分布式事務(wù)ID! 由于分布式事務(wù)涉及到多個數(shù)據(jù)庫之間進(jìn)行操作,偶爾會遇到一些異常情況(例如系統(tǒng)或網(wǎng)絡(luò)中斷)導(dǎo)致上述三個階段出現(xiàn)異常,這就在一個或多個節(jié)點(diǎn)上,產(chǎn)生不完整的“懸疑分布式事務(wù)”。 大多數(shù)情況下,出現(xiàn)這種問題,Oracle 會由 Reco 進(jìn)程進(jìn)行自動修復(fù),Oracle 數(shù)據(jù)庫會在
但有些情況下(例如節(jié)點(diǎn)無法正常訪問或事務(wù)表中記錄的數(shù)據(jù)不完整),Reco 進(jìn)程不能正常完成這個工作,就會拋出異常。 對于分布式事務(wù),對應(yīng)的異常代碼區(qū)間是 例如: ORA-02054: transaction in-doubt The transaction is neither committed or rolled back locally, and we have lost communication with the global coordinator. 此時往往需要手工處理進(jìn)行干預(yù)。 常用的 2pc_clean 命令如下: select 'rollback force '||''''||local_tran_id||''''||';' "RollBack" from dba_2pc_pending where state='prepared';select 'exec dbms_transaction.purge_lost_db_entry('||''''||local_tran_id||''''||');' "Purge" from dba_2pc_pending;select 'rollback force ''' || LOCAL_TRAN_ID || ''';' || chr(10) ||'execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY(''' || LOCAL_TRAN_ID || ''');' || chr(10) || 'commit;' from DBA_2PC_PENDING; 本次分享到此結(jié)束啦~ 如果覺得文章對你有幫助,點(diǎn)贊、收藏、關(guān)注、評論,一鍵四連支持,你的支持就是我創(chuàng)作最大的動力。 |
|
來自: LuciferLiu > 《待分類》