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

From: <TESTAJ3_at_nationwide.com>
Date: Thu, 17 Dec 2009 14:34:51 -0500
Message-ID: <OF4EF2C52F.02E0C4BD-ON8525768F.006B7524-8525768F.006B8F6A_at_lnotes-gw.ent.nwie.net>

I personally would rebuild it, unfortunately since you're not in 11g, you can't just take a copy of the current database but I'l defer my answer as a hard/fast rule based on what others say.

joe

---

Joe Testa, Oracle Certified Professional Senior Engineering & Administration Lead
(Work) 614-677-1668
(Cell) 614-312-6715

Interested in helping out your marriage? Ask me about "Weekend to Remember"
Dec 11-13, 2009 here in Columbus.

From:
"Newman, Christopher" <cjnewman_at_uillinois.edu> To:
<oracle-l_at_freelists.org>
Date:
12/17/2009 02:32 PM
Subject:
Force Logging and Standby's 10g Solaris 64 Sent by:
oracle-l-bounce_at_freelists.org

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

Received on Thu Dec 17 2009 - 13:34:51 CST