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