Archive Log Transfer Gap (LogTransferGap)

Displays a gap during redo transfers from a primary to a standby destination.
During the transfer from a primary to a standby destination, the LogTransferGap parameter displays a gap, either in the redo logs or the archive logs.
When the LGWR process is used, the LGWR process of the primary instance simultaneously tries to write redo information to the standby redo log files.
When the ARCH process is used, the archive redo logs are simultaneously generated on the standby destination.
The log_archive_dest_n parameter of a primary instance can either have a LGWR or an ARCH process to transfer redo data to the standby site. For example, log_archive_dest_n = '<tns-service_entry> LGWR/ARCH ….
The redo gap at the standby site can be for the following reasons:

• Problem in the primary instance.
• Network between the primary and the standby instance is slow.
• Primary instance is unable to identify the standby site.
• Standby TNS service entry is deactivated, deferred, or removed from the primary LOG_ARCHIVE_DEST_n parameter.
• Problems in the standby instance, for example, when - the standby listener is down.- the stndby instance is down.- there is an error at the standby destination.
• The primary instance's, LGWR or ARCH process is unable to write to the standby site.
• The primary instance is unable to resolve the service name when the TNS service entry of a standby instance is removed from the tnsnames.ora file at the primary site.

There are two types of gaps at a standby site:

• Logs missing in between during transfer
• Logs missing sequentially during transfer

The following example explains the sequential gaps for logical and physical standy:

The sequential gap formula for both logical and physical standby is:
max (last archived sequence on primary destination) – max(last archived sequence on standby destination)
When you apply the above formula to the example and subtract the highest sequence number at the standby site (16) from the highest sequence number at the primary site (20), the result is 4.
The following example explains the in between gaps for physical standy:

In this example, the query uses the v$archive_gap from the standby instance and it displays

In this example, the query uses the v$archive_gap view and it displays a high sequence value of 14 and a low sequence value of 12. When you apply the formula to the example, subtract the lowest unmatched sequence number at the standby site (12) from the highest unmatched sequence number at the standby site (14), and add 1 to the result of that calculation, the result is 3.

1. 
   
   1. The v$archive_gap view displays rows only when the recovery process is running on the physical standby instance. The view displays only one gap that appears to be stopping the recovery process from applying log files.

The total LogTransferGap for physical standby = sequential gap calculation plus the v$archive gap calculation (4 + 3 = 7)
The following example explains the formula to find in between gap for a logical standby:

4 rows are selected.

The in-between gap for above scenario is 1+1+2 = 4
The total LogTransferGap for logical standby = sequential gap + in-between gap (3 + 4 = 7)

BMC PATROL propertiess

When this parameter reaches the specified range, an event gets triggered, and the event details display those sequence numbers, which have not been transfered to the standby instance.

The annotation report for the parameter displays the following information:

HostName:Instance = HostName:InstanceName;  LogTransferGap = ParameterValue;  Parameter Status =  ParameterStatus

Log Sequence Numbers from Sequence X to Sequence Y are not transferred.

For more information on how to apply thresholds for this parameter, see the PATROL Configuration Manager User Guide.

BMC ProactiveNet Performance Management properties