Gap Detection and Resolution

 < Day Day Up > 

When we see network glitches like those discussed in the previous section, it is possible to see gaps in the archivelog sequences on the standby host. Essentially, an archive gap is any number of missing archived redo logs that were created on the primary while the standby was unavailable. For example, an archive gap occurs when the network becomes unavailable, and while unavailable the primary database cycles through several online redo logs. When the network is available again, transmission of redo to the remote standby resumes and thus creates a gap.

Methods of Gap Resolution

Data Guard provides two methods for gap resolution, automatic and FAL (fetch archivelog). The automatic method requires no configuration, while FAL requires configuration via init.ora parameters. Both methods are discussed here.

Automatic Gap Resolution

Automatic gap resolution is implemented during log transport processing. As the LGWR or ARC 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 archivelog being received is greater than the last sequence received plus one, the RFS will piggyback a request to the primary to send the missing archivelogs. Since the standby destination requesting the gap resolution is already defined by the LOG_ARCHIVE_DEST_n parameter on the primary, the ARC process on the primary sends the logs to the standby and notifies the LGWR that the gaps have been resolved.

In addition to the above, the ARC 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, the ARC 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 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 at least the standby parameter file. The two parameters are defined as the following:




An Oracle Net service name that exists in the standby tnsnames.ora file and 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.


An Oracle Net service name that exists in the primary tnsnames.ora files and 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 log apply services 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, the FAL_CLIENT value is passed to the primary ARC process. The primary ARC 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, the next destination is attempted until either the gap is resolved or all FAL_SERVER destinations have been tried.

 < Day Day Up > 

Oracle Database 10g. High Availablity with RAC Flashback & Data Guard
Oracle Database 10g. High Availablity with RAC Flashback & Data Guard
ISBN: 71752080
Year: 2003
Pages: 134 © 2008-2017.
If you may any questions please contact us: