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

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
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

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