RE: Physical Standby Issue
Date: Tue, 5 Jul 2011 15:38:25 -0400
Message-ID: <6B0D50B70F12BD41B5A67F14F5AA887F11D5FC26_at_us-bos-mx022.na.pxl.int>
Bill,
I’ve seen a situation like that before. Solution was to recreate the control file on the primary with resetlogs and then rebuild the standby. This will incur an outage on your primary, but it’s about the only way I know of to purge that information.
Richard Goulet
Senior Oracle DBA/Na Team Leader
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of bill_at_intactus.com
Sent: Tuesday, July 05, 2011 1:46 PM
To: Phil Jones
Cc: oracle-l_at_freelists.org
Subject: RE: Physical Standby Issue
Phil -
Thanks for the quick reply.
We already...
- Took a fresh backup of production
- Restored backup on standby
- Created new standby control file
- Copied new control file to standby
- Started standby database
- 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.
Bill
- Original Message -------- Subject: Re: Physical Standby Issue From: Phil Jones <phil_at_phillip.im> Date: Tue, July 05, 2011 10:38 am To: "bill_at_intactus.com" <bill_at_intactus.com>
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.
Cheers,
Phil
On 5 Jul 2011, at 18:26, <bill_at_intactus.com> wrote:
Oracle 9.2.0.8.0
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??
Thanks,
Bill
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jul 05 2011 - 14:38:25 CDT