Re: Problem with 10G Physical Standby Database (archive gap). HELP :-)
From: Johne_uk <edgarj_at_tiscali.co.uk>
Date: Tue, 2 Feb 2010 07:30:12 -0800 (PST)
Message-ID: <35bababc-8f3a-4caf-9596-070ba4ac908d_at_d27g2000yqn.googlegroups.com>
On 2 Feb, 11:28, Johne_uk <edg..._at_tiscali.co.uk> wrote:
> Hi
>
> I'm having some isses with a 10G physical standby database and an
> archive gap. The standby instance does not use dataguard because of
> bandwidth limitations so instead I periodically copy over and manually
> register any archive logs from the primary instance i.e. alter
> database register physical logfile xxxxx. All of the logs are being
> reported as successfully registered.
>
> I created the standby instance a few weeks ago and all was going well
> until last weekend. I have a daily monitoring script that runs after
> the logs have been copied over and registered which shows the current
> log sequence on both primary/standby instances and checks if there is
> an archive gap. The entries below was the last log before things
> started to go wrong.
>
> Standby Current Log Sequence (DR) : 14383
> Primary Current Log Sequence (PROD) : 14383
> Archive Gap
> no rows selected
>
> Then an archive gap appeared
> Standby Current Log Sequence (DR) : 14531
> Primary Current Log Sequence (PROD) : 14531
>
> Archive Gap
> THREAD# LOW_SEQUENCE#
> HIGH_SEQUENCE#
> ---------- -------------
> --------------
> 1 13310 13411
>
> The strange thing is the range of logs in the gap were lower than the
> previous day's email that indicated that the current log was 14383 and
> there was no gap. The missing archive logs have now been purged on
> both instances although I may be able to restore from from tape.
>
> NB: Just checked todays logs and now the gap stands at
> THREAD# LOW_SEQUENCE#
> HIGH_SEQUENCE#
> ---------- -------------
> --------------
> 1 13310 13535
>
> This is the first time I've setup a physical standby and most
> documentation assumes I would be using Dataguard. I'd appreciate a few
> pointers on what I may have done wrong as I thought once a logfile had
> been registered then the database would be updated.
>
> Thanks in advance
> John
Date: Tue, 2 Feb 2010 07:30:12 -0800 (PST)
Message-ID: <35bababc-8f3a-4caf-9596-070ba4ac908d_at_d27g2000yqn.googlegroups.com>
On 2 Feb, 11:28, Johne_uk <edg..._at_tiscali.co.uk> wrote:
> Hi
>
> I'm having some isses with a 10G physical standby database and an
> archive gap. The standby instance does not use dataguard because of
> bandwidth limitations so instead I periodically copy over and manually
> register any archive logs from the primary instance i.e. alter
> database register physical logfile xxxxx. All of the logs are being
> reported as successfully registered.
>
> I created the standby instance a few weeks ago and all was going well
> until last weekend. I have a daily monitoring script that runs after
> the logs have been copied over and registered which shows the current
> log sequence on both primary/standby instances and checks if there is
> an archive gap. The entries below was the last log before things
> started to go wrong.
>
> Standby Current Log Sequence (DR) : 14383
> Primary Current Log Sequence (PROD) : 14383
> Archive Gap
> no rows selected
>
> Then an archive gap appeared
> Standby Current Log Sequence (DR) : 14531
> Primary Current Log Sequence (PROD) : 14531
>
> Archive Gap
> THREAD# LOW_SEQUENCE#
> HIGH_SEQUENCE#
> ---------- -------------
> --------------
> 1 13310 13411
>
> The strange thing is the range of logs in the gap were lower than the
> previous day's email that indicated that the current log was 14383 and
> there was no gap. The missing archive logs have now been purged on
> both instances although I may be able to restore from from tape.
>
> NB: Just checked todays logs and now the gap stands at
> THREAD# LOW_SEQUENCE#
> HIGH_SEQUENCE#
> ---------- -------------
> --------------
> 1 13310 13535
>
> This is the first time I've setup a physical standby and most
> documentation assumes I would be using Dataguard. I'd appreciate a few
> pointers on what I may have done wrong as I thought once a logfile had
> been registered then the database would be updated.
>
> Thanks in advance
> John
I re-applied the single 13310 log and the entire gap disappeared. Received on Tue Feb 02 2010 - 09:30:12 CST