DG 中处理archive gap的方法
====================
当Primary Database的某些日志没有成功发送到Standby Database, 这时候Standby DB上就会出现归档裂缝(
Archive Gap)。
Oracle主要由两个参数处理Archive Gap:
FAL_* 是Fetch Archive Log的缩写,通过配置
FAL_server和
FAL_client实现Gap检测的一种机制。从FAL 这个名字可以看出,这个过程是Standby DB主动发起的“取”日志的过程,Standby DB就是FAL_CLIENT. 它是从FAL_server中取这些缺失的Gap, 10g中,这个FAL_server可以是Primary DB, 也可以是其他的Standby DB。如:
FAL_SERVER='PR1,ST1,ST2';
当Lgwr和Arch进程发送redo/archive到standby端的时候,当前log sequence会同standby端RFS进程上次接收到的log sequence做比较,如果发现二者有断档,RFS会根据FAL_Server发送请求,要求主库传送缺失的日志。或者当备端的RFS进程收到archivelog的时候,更新standby的控制文件以记录这些归档信息,一旦MRP发现控制文件被更新,会进行Recover/Apply log。如果MRP发现所需的日志出现缺失或者所需的日志文件不可用(损坏或者被物理移除等),也会通过FAL_Server来发送相应的处理请求。
MRP是standby端的恢复进程,不像RFS进程一样与parimary有直接关联,通过FAL的参数配置来主动请求primary处理gap。
从9i以后,一般都不需要手工处理确实的日志,FAL自动会帮我们处理这些问题。 但是,并非我们就完全不用手工处理了,比如,你的磁盘空间爆满,归档日志在传到备库前被转移到其他地方,这种情况下FAL是不能解决问题的,需要手工处理一下。
解决办法:
解决gap的方法有两种,方法虽然略有不同,但是原理是相同的
一、gap较少,可以直接将缺少的归档scp到standby,在standby手工注册下即可
二、gap较多,在primary 做基于scn的backup,同时创建一个新的standbycontrolfile,将备份好的backupset ,standbycontrolfile 拷贝的备库的相应目录下,进行restore、recover的操作即可因为这个案例中,standby丢失的归档太多,推荐用第二种方法
///