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: Fri, 29 Oct 2004 13:16:39 -0400
Message-ID: <>

Okay, so logminer is problematic.

But you do have the change number, so look in the log_history to find the relevant log. Then you should be able to "dump logfile" and see if it is log file blocks corrupted, first locally, then on the standby server. If you get a difference, it is something in the transmission.

If you're repeatedly producing log files that show corruption on dumping, then you've really found something of interest, although I suppose the interest may be muted somewhat because it is 8.1.7. Still, for regular type database objects I've not seen a documented redolog bug since 6.0.33 or so.

Maybe someone else can help you get your Logminer environment running. Even though that does seem to be a lot of objects in your dictionary, I would be surprised if Oracle can't handle that. Then again, you're using a pretty old version, so that might be where the problems come in.



-----Original Message-----

[]On Behalf Of
Sent: Friday, October 29, 2004 12:02 PM
Subject: RE: 8i Standby Media Corrupt Blocks

Thanks for the suggestion, Mark. I finally tried to use LogMiner, since my database trigger (trapping various DDL) has not uncovererd a NOLOGGING statement.

However, our Production Student Info. System database has 65,000 tables and about 90,000 indexes - as I said, it's a 3rd Party COTS app, not what we would design. It took almost an hour to build the LogMiner Dictionary file, which is 280MB. When I try to add even the smallest archived redo log and start a LogMiner session, it fails with ORA-04030, not enough process memory. It must be that huge Dictionary file.

I know I can use LogMiner without the Dictionary, but how would I query v$LogMnr_Contents?

Only "regular" tables and indexes are in the tablespace in question.

Our online and archived redo logs are on direct-attached SAN, not NFS. Many, if not most, of the archived redo logs transfer and are "digested" by the Standby just fine.

Any suggestions? Anyone?

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 Fri Oct 29 2004 - 12:13:27 CDT

Original text of this message