I am trying to learn how to resolve the gap between primary and standby manually, the version of my oracle database is 11gr2.

What I did as follow:

  1. At the beginning, primary and standby is synchronized with same log sequence
  2. Disable the parameter log_archive_dest_2,which is used by primary to send redo to standby
  3. Create the archive log by alter system switch logfile at primary
  4. perform a query against v$archive_gap at standby to find the gap between primary and standby

At step4, there is no rows return from v$archive_gap, so I came out with confuses with this situation:

Q1: I has the parameter fal_client and fal_server set at standby, is this factor responsible for “no data return from v$archive_gap

Q2:If everything goes find, some data rows will be returned from v$archive_gap.In fact, I have log_archive_dest_2 disable at primary ,so standby and primary didn’t not realize each other, how standby know there is a gap?

  • Enable the log_archive_dest_2 to see the gap.
    – atokpas
    Commented Nov 16, 2016 at 15:49
  • @JSapkota if i enable the log_archive_dest_2,the log will be transfered immediate Commented Nov 16, 2016 at 15:51
  • Switch log files on Primary for few times.
    – atokpas
    Commented Nov 16, 2016 at 15:53
  • @KrisJohnston if the log no longer exist at primary ,how can the gap resolved manually? Commented Nov 16, 2016 at 15:58

1 Answer 1


An archivelog gap simply means that the apply service on the standby site cannot continue because there is a missing sequence between the sequence that was applied and the next sequence that is available (either shipped from the primary or copied manually).

In other words, if sequence 57 was applied at the standby site, but the next sequence available is 59, then the apply service cannot continue until sequence 58 is available (and has been applied).

Resolving gaps largely depends on why there is a gap. This can happen if an archivelog backup is taken on the primary site with the "delete all input" option and those archivelogs have not been sent to the standby site yet. Since archivelog backups are not automatically sent to the standby site when the shipping process to re-enabled, the gap is detected on the standby site and the gap is then viewable in v$archive_gap.

In the above example, resolving the gap involves (assumes a Windows environment):

Manually copying the archivelog backup to the standby site via OS commands (in this example, I copied the archivelog backups into l:\oracle\archivegaps):

Register the archivelog backups with the standby site:

catalog start with 'l:\oracle\archivegaps';

Unpacking the archive files from the archivelog backup:

  SET ARCHIVELOG DESTINATION TO 'l:\oracle\archivegaps';
  RESTORE ARCHIVELOG FROM sequence 58 UNTIL sequence 58;

Register the archivelogs with the standby site (this step may be optional, as unpacking the archivelogs from the backup may register the archivelogs automatically, but I honestly don't remember).

catalog start with 'l:\oracle\archivegaps';

You may also need to restart the apply service before the gap is resolved:

alter database recover managed standby database cancel; 
alter database recover managed standby database using current logfile disconnect from session;

As for your specific questions:

A1: fal_client and fal_server should have no bearing on whether rows are in v$archive_gap.

A2: A gap is detected on the apply side, not technically the shipping side, so a gap can be detected even if shipping is turned off. Additionally, if a gap is detected while shipping is on, then shipping is turned off, the gap will still be listed in v$archive_gap until the gap has been resolved.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.