RE: 8i Standby Media Corrupt Blocks
- From: "Hitchman, Peter" <Peter.Hitchman@xxxxxxxxxxx>
- To: "'JApplewhite@xxxxxxxxxxxxxxxxxxxx'" <JApplewhite@xxxxxxxxxxxxxxxxxxxx>, oracle-l@xxxxxxxxxxxxx
- Date: Sat, 30 Oct 2004 14:58:41 +0100
Hi Jack,
Are there any clob/blob(s) involved here? There is an 8.1.7.4 bug where by
if the lob is marked as cache reads, nologging changes get generated,
because in some cirumstances Oracle thinks it has read an inconsistent block
in memory (Oracle have never released exact details.) The fix is to alter
the lob setting just to "cache" or "no cache".
Regards
Pete
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of JApplewhite@xxxxxxxxxxxxxxxxxxxx
Sent: 28 October 2004 15:44
To: oracle-l@xxxxxxxxxxxxx
Subject: 8i Standby Media Corrupt Blocks
8.1.7.4 on HP-UX 11 64bit
I recently created a standby for one of our production databases. Got it
in Managed Recovery mode, no problem. A couple of days later, the
standby's Alert log started showing "Recovery is repairing media corrupt
block X of file Y" errors for the 25 datafiles of our main application's
(3rd Party COTS Student Info. package that doesn't work on 9i) tablespace.
No errors for the datafiles for System, RBS, Users, etc.
I checked and there are absolutely no tables or indexes in that tablespace
with LOGGING = NO. In fact, the only tables in the entire database with
LOGGING = NO are Global Temporary Tables.
I suspected the COTS app. of issuing "Alter Table...NoLogging" commands
and slapped an After Alter database trigger on the primary. So far it has
only caught the "Alter Tablespace Begin/End Backup" commands for our
nightly hot backup - nothing else.
The Unrecoverable_Change# in v$Datafile continues to increment
periodically in the primary for those 25 datafiles, leading me to believe
that the NOLOGGING operations are continuing there. However, I'm at a
loss to discover the source.
Am I an idiot? What am I missing?
I've created a TAR, but wanted to run this by the vast experience of this
list for advice.
Thanks.
Jack C. Applewhite - Database Administrator
Austin (Texas) Independent School District
512.414.9715 (wk)
512.935.5929 (pager)
May have come a long way, but we got a long way to go.
-- B.W. Stevenson
--
//www.freelists.org/webpage/oracle-l
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
--
//www.freelists.org/webpage/oracle-l
Other related posts:
