[table=98%]
起因是这样的：之前我们有一台不靠谱的某个数据库DG备机，老是隔一段时间网络就断掉，由于当时没做告警，总是隔个几天才有人检查日志时发现（值班人员不认真）。当时有时候备库重新启动归档日志应用 时，发现主机不传日志过来，配置也没改过，网络也是通的，万分不解，查看备库的DG进程，发现没有RFS进程，主库切换日志不起作用。只好重新在主库上声明备机的相关参数，也不知道哪个参数起作用，然后备库的RFS进程就起来了，也就没去总结。
后来，又有一个数据库的DG备机问题更糟糕，由于是ESX的虚拟机（前任做的），隔段时间就重启在上面的所有虚拟机，包括那台DG备机。悲催的我总是得去处理下。在这过程中也重复发生前面的问题。只好在网上去查找问题，找了半天没找到，倒是在一篇文章里面看到说log_archive_dest_state_n这个参数有时候数据库不认，show paremeter 出来的参数不一定就是数据库认定的参数，所以必要时重新修改参数后在修改回来。抱着试一试的心态，在之后再发生RFS进程不存在的问题时，我就重新声明一遍log_archive_dest_state_n参数，先defer在enable，还真管用。
总结经验下来：几乎所有重新启动归档日志应用 后，RFS进程不存在的问题都发生在主机与备机网络断开长时间后，也就是说主机很久都找不着备机了，所以我想是不是因为oracle在长时间找不到备机的情况下，自动的把重做日志传输进程LNS给停掉了，这样备机没有收到LNS进程的通知，自然不会启动RFS进程接收重做日志。而主机切换日志并不会使得主机去启动LNS进程。但当log_archive_dest_state_n参数变化时，主机会根据参数情况主动启动之前因为长时间连不上备机而停掉的LNS。
而根据一些使用rman active duplicate做备机的方法对比发现，主机都是在声明log_archive_dest_state_n='enable'后，才开始传输重做日志的，所以利用声明log_archive_dest_state_n='enable'启动主库的LNS进程是一个靠谱的方法。
以上是我的个人经验，不知道正不正确，实用就好，希望对大家有所帮助。
原帖地址：[url]http://bbs.dbsupport.cn/thread-523-1-1.html