关于11G DataGuard 日志传输的案例

案例探讨

  在归档和非归档模式下,配置参数log_archive_dest_2后,DG的备库是否传输日志。

案例环境描述

  本次环境如下,一套RAC+单机DG,然后从DG还原出来一个单独的测试库A,测试库A和DG1中同样配置有log_archive_dest_2参数,但测试库A没有开启归档。

  

  在昨天检查客户数据库RAC1和RAC2 实例的alert日志时,发现日志信息中有RFS进程,此进程往往是在DG备库中出现,用于接收主库日志(具体作用大家可百度),出现在

主库就很令人惊慌,虽然RFS进程处于报错的状态,于是回想了一下之前有关此实例的操作,想起前几日由于某种需要,打开了测试库A的归档,会不会和这个有关。

  

  于是查看了测试库A 实例的alert日志,发现确实有进程在发日志往主库,通过查看具体的log_archive_dest_2进程信息可以发现LGWR进程有可能触发了LNS进程发送日志,但是报错ORA-16009,这也正是与主库RFS进程报错对应。

  

  

  问题到这里可以发现,可能是开启归档引起的问题,于是关闭测试库A的归档,再次查看,log_archive_dest_2进程配置,发现SCHEDULE值为PENGDING(等待),而且ERROR字段无值,再次查看RAC1和RAC2日志恢复正常,问题解决,确实是开启归档引起。

  

案例遗留问题

  1、这个案例问题所在,就是开启归档后,会传输日志,但是LGWR在非归档模式下为什么不和LNS进程交互传输日志,毕竟log_archive_dest_2参数是没有改变过。

  2、log_archive_dest_2参数采用的是默认日志传输模式,即ARCH传输(这个从官方文档也是这么说),但是从视图查询的确是LGWR进程在传输,耐人寻味。

  

猜你喜欢

转载自www.cnblogs.com/bicewow/p/10686452.html
今日推荐