Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: 8i Standby Media Corrupt Blocks

RE: 8i Standby Media Corrupt Blocks

From: Mark W. Farnham <>
Date: Thu, 28 Oct 2004 11:16:21 -0400
Message-ID: <>

Can you match up the unrecoverable_change# with other activity in the log
(possibly via logminer) and backtrack to see if there is an unrecoverable
operation on the file in question?

What sort of object resides on the block in question? It should narrow your search if you identify the object in question.

If it turns out to be a user defined type or clob or blob or iot or something like that, the information should help the folks at metalink narrow their search as well.

Finally, what sort of media are your online and archived logs on? If NFS, what vintage? Have you tried dumping the archived log in question locally to isolate the possibility of communication error (or at least a checksum locally and on the standby).

That's all I can think of on the spur of the moment. I'm definitely curious if this turns out to be an Oracle software problem with logs as opposed to some other component of the problem.


Mark W. Farnham

-----Original Message-----
[]On Behalf Of
Sent: Thursday, October 28, 2004 10:44 AM To:
Subject: 8i Standby Media Corrupt Blocks 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.


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.


Received on Thu Oct 28 2004 - 10:12:49 CDT

Original text of this message