RE: Physical Standby Issue
- From: <bill@xxxxxxxxxxxx>
- To: "Phil Jones" <phil@xxxxxxxxxx>
- Date: Tue, 05 Jul 2011 10:45:59 -0700
Thanks for the quick reply.
1. Took a fresh backup of production
2. Restored backup on standby
3. Created new standby control file
4. Copied new control file to standby
5. Started standby database
6. Attempted to recover but database is still looking for corrupt file.
In querying the v$archived_log on primary the APPLIED column shows YES up to the file last applied to the old standby database. The first file with NO in the APPLIED column is the corrupt/missing log file.
-------- Original Message --------
Subject: Re: Physical Standby Issue
From: Phil Jones <phil@xxxxxxxxxx
Date: Tue, July 05, 2011 10:38 am
Because you have a dud log file your only option is to take a full backup of the primary now & recreate the standby from that (and pray there's no actual block corruption on the primary). Unless you have a good copy of the log the old backup is essentially useless.
Whatever you do, I recommend you take a backup of the primary ASAP.
Have a physical standby database on an alternate server/location which received a corrupt log file from the primary. Attempted to copy the logfile from the primary, but original file must be corrupt. Oracle support has not been any help and unable to escalate the issue at this time. We figure the best solution is to restore the database from a recent backup and recreate the physical standby. When this was done and the database recovery was initiated again, the standby database was still looking for the corrupt logfile even though it was created before the backup. When I query v$archived_log it shows all of the log files that need to be applied, including the corrupt file. Is there any way to reset the primary so I can create a new physical standby? It seems to still have information related to the old standby database. Thoughts??
Other related posts: