關(guān)于dataguard出現(xiàn)問(wèn)題的檢查步驟

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

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

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

（2）登陸主庫(kù)(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）檢查備庫(kù)的狀態(tài)

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

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

一般會(huì)有ARCH/RFS/MRP0進(jìn)程

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

RFS日志接收進(jìn)程；

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

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

三者都有可以看看RFS和MRP0的seq，如果和主庫(kù)差不多，也不用查看了，一般是正常的。

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

select sequence#,applied from v$archived_log where applied='NO'；檢查備庫(kù)沒(méi)有應(yīng)用的日志

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

alter  database recover managed standby database disconnect from session;

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