RE: Recover Scenario - Solaris 10.2.0.2

  • From: "Newman, Christopher" <cjnewman@xxxxxxxxxxxxx>
  • To: "Goulet, Richard" <Richard.Goulet@xxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 11 Mar 2010 07:32:11 -0600

Hi Dick,

 

Turns out we had to rebuild the standby.  Your theory is correct, but
the standby stopped applying logs and was getting 600's when attempting
to restart recovery, so the drop tablespace would never make it through,
as it was stuck on the 'bad' redo.

 

-       Chris

 

From: Goulet, Richard [mailto:Richard.Goulet@xxxxxxxxxxx] 
Sent: Thursday, March 11, 2010 7:28 AM
To: Newman, Christopher; oracle-l@xxxxxxxxxxxxx
Subject: RE: Recover Scenario - Solaris 10.2.0.2

 

I'm going to assume that you have "standby_file_management=auto" on the
standby in which case whatever you do to the primary will replicate
nicely to the standby.  Namely that as you drop the tablespace and
datafile the same will occur there thereby making a rebuild unnecessary.

 

Dick Goulet 
Senior Oracle DBA/NA Team Lead 
PAREXEL International 

 

 

________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Newman, Christopher
Sent: Wednesday, March 10, 2010 7:57 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Recover Scenario - Solaris 10.2.0.2

Hello,

We've had datafile moved in our production box; then moved back.  This
has caused logical errors in the datafiles.  These are all index
tablespace related datafiles, so our plan there is to drop the
tablespaces, recreate, and recreate the indexes.

My question... is there any way to manipulate this on the physical
standby's, or is rebuilding the standby's the only logical move?

Errors look like this:

ORA-10564: tablespace GEN_LARGE_INDX

ORA-01110: data file 149: '/u07/oradata/BANPROD/gnli02BANPROD.dbf'

ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object#
70727

Wed Mar 10 18:15:59 2010

Media Recovery failed with error 600

I'm thinking rebuild is going to be our only option, as the standby's
won't get past the 'bad' redo to be able to get to the fix.

Chris Newman

Database Specialist

AITS, University of Illinois

217-333-5429

Other related posts: