有关Real-time Apply和FAL_SERVER字段的疑问

临近年关，今天对数据库及其备库进行了一些检查，发现颇多。

查看备库日志，发现如下信息
RFS[6]: No standby redo logfiles created
这个以前没见过。这个备库是主库升级迁移至11G以后两个月前一并建立的，当时检查没问题，没太在意，之后检查过一次，不知是不是疏忽了，竟然没看见。
这条语句说的很清楚了，就是没有创建standby redo logfiles。之前有过了解，就是用来开启备库实时应用用的。因为之前的管理员从来不考虑实时应用的问题，
所以我刚来时继承了传统。闲着没事去查了查这实时应用，看来还挺管用的。虽然这个库的redologfile5分钟就切换一次，但想一想有总比没有好。于是就是主
备库都创建了standby redo logfiles。
主库可直接创建，主库创建standby redo logfiles是为了切换成备库的时候也有（standby redo logfiles是给备库用的）。备库的话，要先停掉日志应用，再进行
创建。至于创建多少个组，oracle推荐是比redo logfiles多一组就行了（单实例）。然后开启日志应用。
与原来开启不一样的是，中间得加上“  using current logfile”
alter database recover managed standby database  using current logfile  disconnect from session;
Real-time Apply示意图
 
事情还没有结束。
继续观察备库日志，又发现：
ARC5: Archive log rejected (thread 1 sequence 8124) at host 'GZDBDG'
FAL[server, ARC5]: FAL archive failed, see trace file.
这个以前也没见过，冷静了一下。跑去查看了备库的parameters字段FAL_SERVER，同时也去看了主库的parameters字段FAL_SERVER，发现一模一样，这下事大
了，难道tns文件记录的“GZDBDG”不一样，赶紧去查看主备库的tns文件，发现GZDBDG的描述是一样的，都指向备库。一下子懵了。
按理说FAL_SERVER的值指向的应该是现在的主库才对，备库才能从主库那里接收日志啥的，但现在错了也没事，这就奇怪了？
难道说只要设置了主库的log_archive_dest_n字段就行了吗，回头看主备库的log_archive_dest_n字段
都是log_archive_dest_2                   string      SERVICE=GZDBDG LGWR ASYNC
这都是指向备库的，当然现在备库没有使用，这个字段是给主库用的，指明备库的传输模式和tns文件描述的名称，“ LGWR ASYNC”是oracle推荐的，为了主备切
换，我还是把备库的改了，免得切换失败。

这下我彻底疑惑了，FAL_SERVER不是用来备库识别主库的吗，现在都错了，为什么备库还能知道自己的主库是谁，还能接受接受和应用日志呢？
真的搞不懂了！

查了下资料，异常问题不是由FAL_SERVER造成的。FAL_SERVER的具体作用如3楼所说（链接 板凳 ）

继续思考，觉得应该是备库的log_archive_dest_2有问题（排除法：备库定义有“GZDBDG”的字段除了FAL_SERVER就是log_archive_dest_2） 

高人：

附上使用standby log的图片。

Jane 发表于 2014-1-21 17:23  看到主备参数FAL_SERVER 都是指向GZDBDG（备库），这是由于在创建备库时备库参数没改好的原因导致的，正常  ... 是呀！我查了资料后，感觉异常的原因不是出在备库的FAL_SERVER，而是出在备库的log_archive_dest_2参数。