關於dataguard出現問題的檢查步驟

記錄每一次錯誤發表於2018-12-17


一般情況dataguard出現問題都會在alert日誌中看到相關錯誤資訊,或者執行SQL語句命令

select error  from   v$ archive_dest可以查詢報錯。 如果出現錯誤,檢查步驟為:

(1)檢查主庫和備庫的alert日誌,透過日誌知道是什麼地方出現問題

(2)登陸主庫(RAC)檢查歸檔日誌的狀態

select dest_id,thread#,max(sequence#) from v$archived_log where archived='YES' group by thread#,dest_id;

記下tread 1 和tread 2的max sequence

(3)檢查備庫的狀態

select archived_thread#,archived_seq#,applied_thread#,applied_seq# from v$archive_dest_status; 檢查是否與主庫同步,如果已經和上述主庫的max sequence一致,那就完事,沒必要檢查了,因為狀態是正常的,但是一般情況下因為網路有延時問題,可能差個一兩個也是ok的狀態。

select process,status,sequence# from v$managed_standby;

一般會有ARCH/RFS/MRP0程式

ARCH 程式就是負責在重做日誌檔案切換後將已經寫滿的重做日誌檔案複製到歸檔日誌檔案中,以防止迴圈寫入重做日誌檔案時將其覆蓋。

RFS日誌接收程式;

MRP0是管理恢復程式;

也就是說,ARCH進行redo log的歸檔,然後RFS就接收這個歸檔的日誌,MRP0就進行這個歸檔日誌的恢復,三者缺一不可。

三者都有可以看看RFS和MRP0的seq,如果和主庫差不多,也不用檢視了,一般是正常的。

select dest_id,thread#,max(sequence#) from v$archived_log where archived='YES' group by thread#,dest_id; 檢查這個備庫歸檔日誌接收的情況

select sequence#,applied from v$archived_log where applied='NO';檢查備庫沒有應用的日誌

上述是一般dg的檢查步驟,上次出問題是因為災備停電,備庫關掉了,之後啟動起來的時候,沒有關注日誌是否繼續在應用,主備庫日誌裡面沒有報erro,日誌傳輸是正常的,且沒有gap(select * from v$archive_gap),但是就是備庫沒有應用日誌,所以考慮是MRP0程式沒有啟動,於是。。。

alter  database recover managed standby database disconnect from session;

日誌就開始應用了,考慮下次停電後,執行這個語句,避免災備到機房的資料不同步。


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

相關文章