From: Johne_uk on 2 Feb 2010 06:28 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
From: Johne_uk on 2 Feb 2010 10:30 On 2 Feb, 11:28, Johne_uk <edg...(a)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.
|
Pages: 1 Prev: database network performance requirements Next: Optimizer issue in 11g |