Re: Force Logging and Standby's 10g Solaris 64

  • From: "Terry Sutton" <terrysutton@xxxxxxx>
  • To: <cjnewman@xxxxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Thu, 17 Dec 2009 23:56:36 -0800

Chris,
You do NOT need to rebuild the standby. If you the put tablespace that had the issues into backup mode on the primary, and then copy the datafiles to the standby (i.e., replacing the existing datafiles which have the corruption), you can then resume recovery on the standby without issue. Be sure to take the tablespace out of backup mode on the primary after copying. 

--Terry



Hi List,

Quick Q:  We've a dataguard physical standby that we cloned, and the
clone bonked on:

GATHER_STATS_JOB encountered errors.  Check the trace file.
Errors in file
/u01/app/oracle/admin/DSTEST01/bdump/dstest01_j001_10559.trc:
ORA-01578: ORACLE data block corrupted (file # 185, block # 36931)
ORA-01110: data file 185: '/u07/oradata/DSTEST01/edwindx37_4m.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option

We see this error multiple times, all for various datafiles within one
of our index tablespaces.


I checked the primary and oops, it appears that it was *not* in force
logging mode.  This has since been corrected, but my question is this:
Do we have to rebuild the standby to ensure consistency?  There are zero
errors on the physical standby, and the only indication of a problem is
the above after a cloning operation.

Thanks- Chris

--
//www.freelists.org/webpage/oracle-l





--
//www.freelists.org/webpage/oracle-l

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 12-2009