FAL (Fetch Archive Log) Gap Resolution

Once an Archive Log is received or archived from a Standby Redo Log on the Standby Database, it is registered in the Standby Control file (you can query the Registration by v$archived_log on a Physical Standby Database and dba_logstdby_log on a Logical Standby Database). If such a File is missing or corrupted for any Reason (eg. it got deleted by Fault), FAL is called to perform a Gap Resolution. This is the Case because such missing Logfiles are typically detected by the Log Apply Services on the Standby Database. Those are working independent from the Log Transport Services and do not have a direct Link to the Primary Database. To use FAL, there must be one or two (prior Oracle 11.2.0) Initialization Parameters setup on the Standby Database:

FAL_SERVER: 

Specify an Oracle Net Service Name (TNS-Alias or Connect Descriptor) that points to the Database from where the missing Archive Log(s) should be requested. 

This can either be the Primary Database, but also another Standby-, Archive Log Repository- or Far Sync Standby (> Oracle 12.1.0) Database inside the Data Guard Configuration. 

It is possible to specify multiple Service Names (Comma separated). FAL will then sequentially attempt those Databases to resolve the Gap.

FAL_CLIENT 

(< Oracle 11.2.0): Specify an Oracle Net Service Name (TNS-Alias or Connect Descriptor) that points from the FAL_SERVER Database(s) back to the Standby Database (i.e. that’s the Destination where the FAL_SERVER Database should send the Redo to). 

Ensure this TNS-Alias exists in the TNSNAMES.ORA of your FAL_SERVER Database(s). 

This Parameter is not required any more since Oracle 11.2.0. However you have to ensure there exists a corresponding log_archive_dest_n on your FAL_SERVER Database(s) which is pointing to the Standby Database requesting the Gap Resolution.

Once the Log Apply Services detect an Archive Gap it sends a FAL Request to the FAL_SERVER handing over the FAL_CLIENT (or db_unique_name for Version > 11.1.0). 

An ARCH-Process on the FAL_SERVER tries to pick up the request Sequence(s) from that Database and sends it back to the FAL_CLIENT (or uses the Destination valid for this db_unique_name).

If the first FAL_SERVER is not able to resolve the Gap, the next FAL_SERVER in the List will be attempted. If it cannot be resolved by all FAL_SERVERs the FAL-Request fails and a corresponding Message will be put in the ALERT.LOG of the Standby Database.

In order to successfully complete a Gap Request the requested Archive Log Sequence(s) must be available on the FAL_SERVER Database (on Disk and the corresponding Entry in the Control file).

FAL is available since Oracle 9.2.0 for Physical Standby Database and Oracle 10.1.0 for Logical Standby Databases.

Manual Gap Resolution

If an Archive Gap cannot be resolved automatically by any of the previously mentioned Methods, you can still try to manually resolve an Archive Gap.

You can query v$archive_gap on a Physical Standby Database or dba_logstdby_log on the Logical Standby Database to determine a current Archive Gap, eg.

On Physical standby:

SQL> select * from v$archive_gap;

On Logical standby:

SQL> select thread#, sequence# from dba_logstdby_log l where next_change# not in (select first_change# from dba_logstdby_log where l.thread#=thread#) order by thread#, sequence#;

Now copy the returned Sequences to the Standby Database manually to the desired Location. If the missing are not yet registered on the Standby Database, you have to register them before the Log Apply Services are able to read those Logfiles. You can register Archive Logs using

Physical Standby:

SQL> alter database register logfile ‘<File-Specification>’;

 Logical Standby:

SQL> alter database register logical logfile ‘<File-Specification>’;

Once they are registered Log Apply Services will pick up the Archive Logs and proceed.