Re: Primary shows no gap, but standby is missing an archivelog

From: Kenny Payton <>
Date: Tue, 24 Feb 2015 21:26:35 -0500
Message-Id: <>

I’d have to give your question a little more thought for a good answer but hopefully you have a backup of that log or are prepared to rebuild the standby or ship an incremental backup over and apply it to the standby.

I have a suggestion moving forward. If you’re not already using RMAN use it minimally to manage your archivelog deletions. You can define the ARCHIVE DELETION POLICY to SHIPPED or APPLIED TO STANDBY and when you run a delete archivelog statement it will not delete archivelogs that don’t meet your requirements unless you provide the force option.

> On Feb 24, 2015, at 9:19 PM, Maureen English <> wrote:
> I have a situation where I know what happened and how to prevent it
> from happening in the future, but I don't know why it looks like the
> problem shouldn't exist.
> A while back, I was doing something in our primary database that
> resulted in a lot of archivelogs being generated. We don't have that
> much space for archivelogs, so I delete some of them when we start to
> run out of space. I always run the following query in the primary
> database, before and after deleting archivelogs, and never delete all
> of them at the same time:
> where 3 is the standby. This query consistently returns 'NO GAP', so I figured
> that everything was fine. However, when restarting the standby today, it now
> appears that there is an archivelog that has been missing for a very long time.
> Querying v$archived_log shows when the problem started, but why does v$archive_gap
> return no rows and v$archive_dest_status return 'NO GAP'? Our standby database is
> in realtime apply mode.
> - Maureen

Received on Wed Feb 25 2015 - 03:26:35 CET

Original text of this message