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
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.
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
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
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
May have come a long way, but we got a long way to go.
-- B.W. Stevenson