备库log_archive_dest_2的问题

最新推荐文章于 2021-05-11 17:59:59 发布

magic5650

最新推荐文章于 2021-05-11 17:59:59 发布

阅读量7.5k

点赞数

分类专栏： oracleDG 文章标签： oracle dataguard

本文链接：https://blog.csdn.net/magic5650/article/details/43954143

版权

本文探讨了在Oracle Data Guard环境中，log_archive_dest_n 参数设置导致的问题及其解决方案。讲解了该参数的作用、常用特性，如 SYNC、ASYNC、NET_TIMEOUT 和 REOPEN，并给出了主备库的示例配置。通过调整LOG_ARCHIVE_DEST_n 的 valid_for 参数，解决了主备库异常的问题。

摘要由CSDN通过智能技术生成

事情是这样的：
备库的log_archive_dest_2的值和fal_server原先是直接copy主库的（疏忽了，当时没改），但也一样跑起来（主备库的tns是一样的），
这天因为备库开启实时应用发现这个问题。
这个备库报这个东西
ARC5: Archive log rejected (thread 1 sequence 8124) at host 'GZDBDG'
FAL[server, ARC5]: FAL archive failed, see trace file.
‘GZDBDG’是备库的tns
于是就把备库的fal_server改成了GZDB1（主库的tns），把备库的log_archive_dest_2的值改成了GZDB1 LGWR ASYNC，指向主库
重启实时应用后，主库报这个东西
RFS[3]: Assigned to RFS process 26680
RFS[3]: Database mount ID mismatch [0