一般情況dataguard出現(xiàn)問題都會在alert日志中看到相關(guān)錯誤信息，或者執(zhí)行SQL語句命令

成都創(chuàng)新互聯(lián)制作網(wǎng)站網(wǎng)頁找三站合一網(wǎng)站制作公司,專注于網(wǎng)頁設(shè)計,成都網(wǎng)站制作、網(wǎng)站設(shè)計、外貿(mào)網(wǎng)站建設(shè),網(wǎng)站設(shè)計,企業(yè)網(wǎng)站搭建,網(wǎng)站開發(fā),建網(wǎng)站業(yè)務(wù),680元做網(wǎng)站,已為1000+服務(wù),成都創(chuàng)新互聯(lián)網(wǎng)站建設(shè)將一如既往的為我們的客戶提供最優(yōu)質(zhì)的網(wǎng)站建設(shè)、網(wǎng)絡(luò)營銷推廣服務(wù)!

select error  from   v$ archive_dest可以查詢報錯。 如果出現(xiàn)錯誤，檢查步驟為：

（1）檢查主庫和備庫的alert日志，通過日志知道是什么地方出現(xiàn)問題

（2）登陸主庫(RAC)檢查歸檔日志的狀態(tài)

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）檢查備庫的狀態(tài)

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

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

一般會有ARCH/RFS/MRP0進程

ARCH 進程就是負責在重做日志文件切換后將已經(jīng)寫滿的重做日志文件復(fù)制到歸檔日志文件中，以防止循環(huán)寫入重做日志文件時將其覆蓋。

RFS日志接收進程；

MRP0是管理恢復(fù)進程；

也就是說，ARCH進行redo log的歸檔，然后RFS就接收這個歸檔的日志，MRP0就進行這個歸檔日志的恢復(fù)，三者缺一不可。

三者都有可以看看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'；檢查備庫沒有應(yīng)用的日志

上述是一般dg的檢查步驟，上次出問題是因為災(zāi)備停電，備庫關(guān)掉了，之后啟動起來的時候，沒有關(guān)注日志是否繼續(xù)在應(yīng)用，主備庫日志里面沒有報erro，日志傳輸是正常的，且沒有g(shù)ap（select * from v$archive_gap)，但是就是備庫沒有應(yīng)用日志，所以考慮是MRP0進程沒有啟動，于是。。。

alter  database recover managed standby database disconnect from session;

日志就開始應(yīng)用了，考慮下次停電后，執(zhí)行這個語句，避免災(zāi)備到機房的數(shù)據(jù)不同步。