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

  • From: "Newman, Christopher" <cjnewman@xxxxxxxxxxxxx>
  • To: "Terry Sutton" <terrysutton@xxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
  • Date: Fri, 18 Dec 2009 07:44:12 -0600

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:

SELECT UNRECOVERABLE_CHANGE#,
       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 [mailto:terrysutton@xxxxxxx] 
Sent: Friday, December 18, 2009 1:57 AM
To: Newman, Christopher; oracle-l@xxxxxxxxxxxxx
Subject: Re: Force Logging and Standby's 10g Solaris 64

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: