首页 » ORACLE 9i-23ai » v$archived_log.applied列不更新的解决方法

v$archived_log.applied列不更新的解决方法

在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)

 

打赏

对不起,这篇文章暂时关闭评论。