Dataguard的 Heartbeat ARCn-Process

关于Dataguard的日志应用问题的理解。

我们知道当日志在备端得到应用后
可以通过如下sql在备端查询v$archived_log 的applied列是 YES
SQL> set line 300 
SQL> col name for a80 
SQL> select thread#,name,SEQUENCE#,APPLIED,first_time from v$archived_log order by SEQUENCE# ; 

那如果我们查询主端的v$archived_log视图的applied时，显示的YES表示的是什么意思呢？

Dataguard主备之间有一个心跳体系 Heartbeat ARCn-Process，那就是主端的一个ARCn进程和备端的一个RFS进程组成这个心跳通讯。

主端的alert日志如下：

ARC1 started with pid=21, OS id=6585
...
ARC1: Becoming the heartbeat ARCH
-> In this Case we can find that ARC1 with pid 21 (OS-pid 6585) is the current Heartbeat ARCn-Process.

备端日志：
This Process tries to ping an associated RFS-Process on the Standby Database. If you look into the Standby ALERT.LOG you can find Entries like this:

RFS[2]: Assigned to RFS process 6621
RFS[2]: Identified database type as 'physical standby': Client is ARCH pid 6585
-> So here RFS-Process with OS-pid 6621 is the corresponding RFS-Process for the Heartbeat Ping

当备端的日志应用后，会通过该心跳机制将来更新主端的V$archived_log的applied项为YES。

如果发现主端的v$archived_log的applied选项不会自动更新，那可能是进程hang
请参考文档2071445.1的解决方法进行修改，然后再次查询归档状态： 

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> set line 300 
SQL> col name for a80 
SQL> select thread#,name,SEQUENCE#,APPLIED,first_time from v$archived_log order by SEQUENCE# ; 

如果还不能进行更新，那也许还有别的原因，如下面的这个案例：


11g 的单机对单机的Dataguard环境， dataguard同步正常，同时rman中修改删除归档日志策略 CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
然后主端部署有第三方的带库备份软件，主端的归档通过备份软件来清理，也 就是三方备份软件备份后进行删除已备份归档日志。
但是发现删除不了 提示： RMAN-08120: WARNING: archived log not deleted, not yet applied by standby
按照以前的经验，我们可以使用脚本来delete archivelog的时候加force参数就可强制删除。
但是很好奇的是明明主端的归档已经在备库应用了， 为什么还提示在不能删除呢？

最终检查配置发现，主端的log_archive_config设置的是dg_config(a,b) ，但是log_archive_des_2中的db_unique_name写的是a（理论上应该是备机的b），而且去备机上检查发现
备机由于在设置备机参数的时候手误，并没有修改备机的db_unique_name而导致备机的db_unique_name和主端的一致，都是a

所以这套Dataguard可以正常的进行数据的同步，但是备机applied应用的日志情况，不能反馈到主端的v$archive_log的applied列中，因此导致主库认为归档一直未在备端上应用，
加上主端的 CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;参数的作用，所以导致主端的归档日志从未被成功删除。


找到原因后修改备端的db_unique_name并修改主端的痾log_archive_config参数，解决问题。


参考文档：

How To Trace The Remote File Server (RFS) Process In Physical Standby Database (文档 ID 1481125.1)
RMAN-08120 raised because v$archived_log.applied is not being updated by Data Guard (文档 ID 2071445.1)
'APPLIED'-Column not updated if Heartbeat-ARCH hangs (文档 ID 1369630.1)
Troubleshooting - Heartbeat failed to connect to standby (文档 ID 1432367.1)
RMAN-08120 raised because v$archived_log.applied is not being updated by Data Guard (文档 ID 2071445.1)

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24052272/viewspace-2131331/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/24052272/viewspace-2131331/