[20170206]关于Data Guard Gap Detection and Resolution.txt
--节前遇到的问题,发现实施方建立的dg有一些古怪.链接:http://www.itpub.net/thread-2082892-1-1.html
--参数fal_client,fal_server,log_archive_config没有设置.
--更觉得奇怪的是db_unique_name两边是一样的(注:实际上两边的环境变量ORACLE_SID是一样的,而缺省如果你不设置db_unique_name,默
--认应该等于ORACLE_SID).
--//我介入当时就是解决gap 间隙问题.
--//根据链接的讨论,zergduan给出的结论是:
1. auto gap resolution
通过主库和备库之间的进程心跳来完成传输gap日志，也通过心跳来检测gap
2. FAL
也就是11g之前 FAL client 和 FAL server两个参数，11g开始只有一个参数 FAL Server
通过扫描控制文件发现gap，通过FAL来解决gap
3. 手动解决
由dba来手动传输并注册gap的归档日志，或者通过增量备份前滚恢复解决gap.
--我也看一些文档,转抄如下:
Data Guard Gap Detection and Resolution [ID 232649.1]
Methods of Gap Resolution:
===========================
Data Guard provides two methods for gap resolution, automatic and FAL (Fetch Archive Log). The automatic method requires
no configuration while FAL requires configuration via init.ora parameters. Both methods are discussed below.
Automatic Gap Resolution:
~~~~~~~~~~~~~~~~~~~~~~~~~~~
In both 9.0.1 and 9.2.0 Automatic Gap Resolution is implemented during log transport processing. As the LGWR or ARCH
process begins to send redo over to the standby, the sequence number of the log being archived is compared to the last
sequence received by the RFS process on the standby. If the RFS process detects that the archive log being received is
greater than the last sequence received plus one, then the RFS will piggyback a request to the primary to send the
missing archive logs. Since the standby destination requesting the gap resolution is already defined by the
LOG_ARCHIVE_DEST_n parameter on the primary, the ARCH process on the primary sends the logs to the standby and notifies
the LGWR that the gaps have been resolved.
Starting in 9.2.0, automatic gap resolution has been enhanced. In addition to the above, the ARCH process on the primary
database polls all standby databases every minute to see if there is a gap in the sequence of archived redo logs. If a
gap is detected then the ARCH process sends the missing archived redo log files to the standby databases that reported
the gap. Once the gap is resolved, the LGWR process is notified that the site is up to date.
FAL Gap Resolution:
~~~~~~~~~~~~~~~~~~~~~~~~
As the RFS process on the standby receives an archived log, it updates the standby controlfile with the name and
location of the file. Once the MRP (Media Recovery Process) sees the update to the controlfile, it attempts to recover
that file. If the MRP process finds that the archived log is missing or is corrupt, FAL is called to resolve the gap or
obtain a new copy. Since MRP has no direct communications link with the primary, it must use the FAL_SERVER and
FAL_CLIENT initialization parameters to resolve the gap. Both of these parameters must be set in the standby init.ora.
The two parameters are defined as:
FAL_SERVER:
An OracleNet service name that exist in the standby tnsnames.ora file that points to the primary database listener. The
FAL_SERVER parameter can contain a comma delimited list of locations that should be attempted during gap resolution.
FAL_CLIENT:
An OracleNet service name that exist in the primary tnsnames.ora file that points to the standby database listener. The
value of FAL_CLIENT should also be listed as the service in a remote archive destination pointing to the standby.
Once MRP needs to resolve a gap it uses the value from FAL_SERVER to call the primary database. Once communication with
the primary has been established, MRP passes the FAL_CLIENT value to the primary ARCH process. The primary ARCH process
locates the remote archive destination with the corresponding service name and ships the missing archived redo logs. If
the first destination listed in FAL_SERVER is unable to resolve the gap then the next destination is attempted until
either the gap is resolved or all FAL_SERVER destination have been tried.
As of 9.2.0 FAL Gap Resolution only works with Physical Standby databases as the process is tied to MRP. Gap recovery on
a logical standby database is handled through the heartbeat mechanism.
--//感觉有必要自己做一些测试,来验证一些结论.
--//具体测试看下篇...
