一般情况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;
日志就开始应用了,考虑下次停电后,执行这个语句,避免灾备到机房的数据不同步。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。