ANBOB™

在Oracle Data Guard环境中，如果查询Primary库的v$archived_log.applied列一直显示为NO，但实际上Standby库已经应用了归档日志，可能会导致无法删除主库的归档日志，因为无法确认日志是否已经被应用。

这种情况通常是由于网络延迟或者Standby库的应用进程出现问题导致的。为了解决这个问题，你可以尝试以下方法：

1. 检查Standby库的应用进程是否正常运行。可以使用以下命令来检查：

SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;

如果应用进程的状态为IDLE或者其他异常状态，可以尝试重启该进程。

2， 检查standby gap

在《如何检查Oracle Dataguard Gap？》已分享几个查询standby gap的方法，请确认standby 已和primary同步。

3 , 检查alert log是否有报错，或实际应用该日志。
grep “Media Recovery Log ” alert.log

4, 检查网络连接是否正常。确保Primary库和Standby库之间的网络连接稳定，并且没有丢包或者延迟问题。

可能解决的方法
1,  arch-rfs心跳问题

在DATAGUARD 主备数据库之间的 ARCH-RFS 心跳 Ping 负责更新primary数据库上 v$archived_log 的 APPLIED-Column。prmary数据库上有一个指定的心跳 ARCn 进程来执行此 Ping。 如果此进程开始挂起，则它不再与远程(standby db) RFS 进程通信，因此无法相应地更新主进程。

将 log_archive_max_processes 切换到 1 并返回到原始值（示例 4）将使进程重新启动。

SQL>archive log list;
SQL>alter system set log_archive_max_processes=1 scope=memory;
SQL>alter system set log_archive_max_processes=4;
SQL>alter system archive log current;
SQL> select thread#, sequence#, applied from v$archived_log where sequence# = ;

注意：您可能需要等待一两分钟才能正确更新 APPLIED 列。

另外也可以先重启备库，如果不同步，再kill  primary库的 arch_n_dest对应的arcN 进程，不会导致实例crash，而arc进程会自动重启动。

2, 18c bug
检查是否应用 bug 29056767.

在备库配置发如下参数 standby database:
SQL> alter system set “_time_based_rcv_ckpt_target”=0;

NOTE: Once parameter is set on the standby, you must restart media recovery for it to pick up the new parameter value.

NOTE: this parameter can also be proactively set on the primary, so the parameter exists if the primary becomes the standby in the future.

如果以上方法都无法解决问题，建议联系www.anbob.com

reference

v$archived_log.applied is not Being Updated by Data Guard Causing RMAN-08120 (Doc ID 2071445.1)

Applied Column of V$archived_log on Standby is Not Updated (Doc ID 2696048.1)

打赏

微信扫一扫，打赏作者吧～