oracle高級復制維護中要注意的幾點內容
2024-08-29 13:42:16
供稿：網友
前段時間一致在做Oracle高級復制，下面是在維護過程中對出現問題的一些分析、解決，貼出來希望對大家有幫助：
高級復制是oracle數據庫的高級功能，它的維護比普通數據庫復雜，下面是在已有高級復制數據庫維護過程中出現過一些問題和解決辦法。
1、穩定的物理鏈路：連接服務器的網絡由于故障斷開，服務器彼此之間數據就不能訪問，數據無法傳輸；網絡不穩定，數據就會發生丟包，不完整。
2、傳輸速度方面要求較高：否則還不如單級版本。
3、參與的服務器不能長期不開機：這樣會積壓大量的延遲任務，導致數據無法進行發布。
4、參與復制的表，不能在它上面直接執行任何DDL語句：因為ORACLE自動在參與復制的表上建立了內部的支持復制的TRIGGER和PACKAGE，在它上面直接執行任何DDL語句都會破壞這些復制支持。應該先SUSPEND要修改表所在的復制組，在REPICATION MANAGER中或調用REPCAT API執行DDL語句，然后重新GENERATE該表的復制支持，最后將復制組狀態恢復為NORMAL。注重修改表結構的DDL語句中表名前一定要帶上屬主，并且最后沒有分號。假如不小心直接執行了DDL語句，應該將該表移出復制環境，刪掉，重新建立或從其它節點復制過來。
5、修改一張表加一個字段，并設置缺省值，如 ALTER TABLE OWNER.TABLE_NAME ADD(FIELD_NAME VARCHAR2(20) DEFAULT 'AAA');在9i之前不能一次執行，要分成兩部分執行：
1、ALTER TABLE OWNER.TABLE_NAME ADD FIELD_NAME
2、ALTER TABLE OWNER.TABLE_NAME MODIFY FIELD_NAME DEFAULT 'AAA'
這是因為執行任何DDL語句，需要SUSPEND復制組，此時復制表只能查詢，不能執行其它DML語句。假如直接加上一個字段同時賦予缺省值，此時的處理是加上一個字段，并馬上給該字段賦上給定的缺省值，這后面的DML語句是不能執行的，所以會報錯。而分成兩部分執行，第一部分先加一個字段，第二部分再修改該字段的定義，不會發生插入缺省值的DML操作，因此可以執行。
6、執行任何ADMIN REQUEST（對復制環境的治理命令）前，都要保證此時沒有堆積的DEFERRED TRANS。
7、執行任何ADMIN REQUEST，必須一步一步執行。因為ADMIN REQUEST的工作原理，是用一個REPCATLOG表保存ADMIN REQUEST語句，執行完一條消失一條，后面的再繼續執行。假如前面一條沒執行完，后面的ADMIN REQUEST就無法執行，而REPCATLOG表假如不為空，復制組就無法恢復為NORMAL。因此每次發出ADMIN REQUEST后，都要檢查REPCATLOG表，當所有節點上的REPCATLOG表都為空后，才能發出下一條命令。
8、假如發現REPCATLOG表中有無法執行的命令，可以重新APPLY或PURGE掉再重新發出命令執行。假如只是某一個節點上有遺留命令，可以在該節點上多APPLY幾次執行。
9、假如發出命令后一直沒有響應，而ADMIN REQUEST又無法PURGE掉，現象類似死鎖。可以試著BROKEN掉該ADMIN REQUEST對應的JOB，重新刷新命令。假如命令能繼續執行，恢復JOB的狀態。假如還不行，從V$session 和V$LOCK中查出死鎖，用ALTER SYSTEM KILL SESSION 殺掉死鎖的進程，假如還是殺不掉。就需要查出類型為'RQ'的分布式死鎖，用SID再從V$PROCESS、V$BGPROCESS查出對應的后臺進程，從操作系統級殺掉后臺進程的方式來解鎖，可能還需要重啟數據庫。最后再恢復JOB的狀態和其他涉及的復制環境狀態。
10、可以通過REPLICATION MANAGER或相關系統表查詢復制環境情況，以REPADMIN用戶登陸：
查看復制組和復制對象：
select gname,status from dba_repgroup;
--其中gname 即為復制組名,status 表示狀態
select gname,oname,status from dba_repobject where type =’TABLE’ and oname =
‘table_name’;
--要查詢某張表在哪個復制組中，將table_name 替換成表名，注重表名一定要大寫。
查看分布式狀態：
select job,what,next_sec,this_sec,last_sec,failures,broken from dba_jobs;
failures 小于16，broken 為N 表示分布式狀態正常
查看數據庫連接
select * from dba_db_links;
恢復傳播復制任務
當連接復制環境中數據庫的網絡出現問題，可能會造成復制任務的停止。具體現象
表現為本地數據庫的更新操作沒有發布到遠地數據庫中。當出現這種情況時，請參考
前面提到的查看分布式狀態的方法，檢查復制任務是否正常。假如failures 大于等于16，
broken 為Y 表示分布式狀態不正常，需要恢復傳播復制任務。
exec dbms_job.run(jobno);
-- jobno 為在dba_jobs 表中ailures 大于等于16，broken 為Y 的job。
查看執行出錯的事務
當分布式數據庫出現不正常時，請執行下列語句，并根據查詢的error_msg 來解決
問題。
select distinct origin_tran_db,destination,error_msg from deferror;
嘗試執行出錯的事務
根據查詢的error_msg 解決了網絡無法連接等問題后，請執行下列語句，并拷貝生
成的拼接exec 語句在客戶端執行。
select ' exec dbms_defer_sys.execute_error ( ' ' ' DEFERRED_TRAN_ID ' ' ' , ' ' '
DESTINATION ' ' ' )' from deferror;
刪除執行出錯的事務
可能會碰到這樣一種狀況，嘗試執行出錯的事務，該事務依舊執行不成功。假如此
時deferror 表中的error_msg 都是“NO DATA FOUND”的錯誤，那么可以考慮刪除執
行出錯的事務。請非凡注重，必須確認已經解決了出錯原因，并在每個分布式節點都
嘗試執行出錯的事務后，才可以刪除再次執行出錯的事務，否則會造成分布式數據庫
的數據不一致。
select ' exec dbms_defer_sys.delete_error ( ' ' ' DEFERRED_TRAN_ID ' ' ' , ' ' '
DESTINATION ' ' ' )' from deferror;
