Re: alter system dump...

> > I 've been advised to use this command to read redo log files.
>
> I think that might be stretching the case. You were told (by Jonathan,
> IIRC) that this command would enable you to dump the contents of the redo
> logs, so that you might see whether anything was contained therein that you
> couldn't find from v$logmnr_contents. Slightly different from "being
> advised" to use it.
>

true.

> > But I don't really understand the dump file that is created.
> >
>
> That puts you in very good company. If we were intended to understand it,
> we wouldn't have needed Log Miner, would we?! For a start, redo contains
> 'change vectors' -a hexadecimal representation of the changes applied to
> objects. Provided you are fluent in hexadecimal, you'll have no problem
> interpreting the dump. For the mortals amongst us, the Log Miner dictionary
> file provides a mapping between hexadecimal and plain ol' English object
> names.
>

still OK  

> > I'm currently searching in the archives to have info about this file
> > but as I don't manage to get what I'm looking for.
> > I'm asking directly.
> >
> > Can someone explain me how to understand this file?
> > What are the different field?
> >
> > Is there a documentation or a book about it?
> >
>
> I doubt it. Why not re-phrase your post to say it as it really is. "I want
> to track DML on partitioned tables and Log Miner doesn't do that very well,
> so I'm looking for a better method".
>

Actually that's the chained rows problem that i'm trying to avoid by using this file directly.
and without understanding basics I won't be able to find a folution for such a problem.
I mean if I can't find a classic DML in this file I won't be able to find chained rows or partitionned tables. So that's why I'm interested in the different parameter of this file.

> To which my answer would be "I doubt there is one, it's an inherent
> limitation in Log Miner, no-one seems to know of a better third-party
> product, so you'll have to learn to live with it".
>

The problem is that we really want to base our product upon redo logfiles so we keep searching that could help us. Logminer has those little problems combined with the fact that it can't read files from Oracle 7 and we don't know how it will evolves in the next versions.

> I don't mean to be harsh, but this one has been out there long enough for us
> to be fairly sure that there isn't a swarm of DBAs out there finding an
> awful lot more in the log files than we poor fools using Log Miner are able
> to discover.

Bad news...

> Regards
> HJR
Thanks

John Received on Thu May 31 2001 - 08:50:55 CDT