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

From: Newman, Christopher <>
Date: Fri, 18 Dec 2009 07:44:12 -0600
Message-ID: <>

Hi Terry et al,

It turns out there were more than just a few out of sync, so we opted for the rebuild, however, even after the rebuild we're still having issues. Here's our current status:

The standby on dstest for dsprod01 was recreated this evening without issue. We did this because of a failure in duplicating DSPROD01 on dstest to DSTEST01. The error we saw indicated that the primary wasn't in FORCE LOGGING mode, and NOLOGGING operations happened on the standby. The primary was placed into FORCE LOGGING per the following:

Thu Dec 17 13:27:43 2009
alter database force logging
Thu Dec 17 13:27:43 2009
ALTER DATABASE FORCE LOGGING command is waiting for existing direct writes to finish. This may take a long time. Completed: alter database force logging

It looks like after this operation we didn't get a log switch and didn't switch manually until Thu Dec 17 14:16:11 2009.

A full backup started at 17-Dec-2009 13:49:46, and the standby was restored from that backup. We used the following to see any files that were out of sync:

       TO_CHAR(UNRECOVERABLE_TIME, 'mm-dd-yyyy hh:mi:ss') FROM V$DATAFILE; This query *still* shows 110 files out of sync (out of 180), with most of the sync timestamps being from the morning before the restore (12-17-2009). Could this be because of the log switch timing (ie, no log switch after enabling force logging?)

The clone to DSTEST01 worked without errors, and the query above returned no files out of sync. I'm not sure why the clone would show nothing using the above query, while the standby still shows 110 entries.

Metalink note: Document TitleThe Gains and Pains of Nologging Operations (Doc ID 290161.1)        

The above technique does seem to resolve individual datafile issues, but I don't understand why a full recreate wouldn't do it, unless it's the log issue.

Clone is able to be created without issue, standby isn't reporting any issues, but I'm still concerned about the integrity of the standby.

Add info: Clone created using RMAN duplicate, full backup, ship to standby site, restore via duplicate target db for standby, no errors at all during this process.

-----Original Message-----
From: Terry Sutton [] Sent: Friday, December 18, 2009 1:57 AM
To: Newman, Christopher; Subject: 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.


> 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
> errors on the physical standby, and the only indication of a problem
> the above after a cloning operation.
> Thanks- Chris
> --

Received on Fri Dec 18 2009 - 07:44:12 CST

Original text of this message