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.
Regards,
Mark W. Farnham
-- --Original Message-- --
From: oracle-l-bounce@(protected)
[mailto:oracle-l-bounce@(protected)]On Behalf Of
JApplewhite@(protected)
Sent: Thursday, October 28, 2004 10:44 AM
To: oracle-l@(protected)
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
