ORA-02062: distributed recovery 引起的 ORA-02019: connection description for remote database not found

一個測試資料庫隔三差五的報一個ORA-02019出來，查詢alert檔案，有一個詳細的trace：
*** 2007-10-12 21:47:55.083
ERROR, tran=2.34.74876, session#=1, ose=0:
ORA-02062: distributed recovery received DBID 78d96835, expected 2421f8a5
*** 2007-10-12 21:49:08.093
ERROR, tran=2.34.74876, session#=1, ose=0:
ORA-02019: connection description for remote database not found
看來這個ORA-02019只是表面現象，引起的原因應該是ORA-02062

[@more@]

網上搜尋了下，找到了老和尚的解決辦法，記錄在此吧：
處理辦法：

(1) set transaction use rollback segment system
(this is VERY important, otherwise database loss can occur)
(2) select * from dbc_2pc_pending where state='collecting';
(3) for each local_tran_id in selected rows, delete where local_tran_id is that value from the following tables:
dba_2pc_pending
pending_sessions$
pending_sub_sessions$

因為是817 undo是手工管理的，就不用進行第一步設定。如果是auto 管理undo 段的話

要先遮蔽掉對undo操作的錯誤提示:
sql>alter system set UNDO_SUPPRESS_ERRORS = TRUE
sql>EXECUTE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('1.29.81672')
sql>alter system set UNDO_SUPPRESS_ERRORS = false

首先:

/****1.查詢處於分散式事務狀態下的本地事務ID號***/

select local_tran_id from dba_2pc_pending;

29.22.266482
8.36.982659
27.40.380788

/*****清楚這個分散式事務（該事務已經無法完成），不會對資料庫有影響***/

SQL> EXECUTE DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('29.22.266482');

PL/SQL procedure successfully completed

SQL> commit;

PL/SQL procedure successfully completed

問題解決了，原因也就很容易找到了，是做一個大的透過dblink的兩個db間的分散式事務的時候，修改了dblink的連結指向，導致了正在執行的事務找不到原先正確的dblink了，分散式事務卡在那裡了。