Re: log file format

"John" <j_barbe_at_hotmail.com> wrote in message news:8bc78dd8.0105220426.4e558108_at_posting.google.com...
> >
> > Your descriptions of Log Miner's limitations are pretty accurate so far!
> > From the Backup and Recovery course guide: "SQL on chained data rows is
 not
> > reconstructed" (as you point out). There's nothing about partitions
 being a
> > particular problem, though -but then you do say it's "hard", not
 impossible!
> >
> > I just honestly don't know what you expect to be able to achieve by
 poking
> > around in the logs "on your own" that Log Miner can't do. Or, to put it
 the
> > other way, that which Log Miner can't do probably can't be done, unless
 you
> > are willing to pay big bucks (I know that there are third party tools
 out
> > there which do the same sort of things as Log Miner, but last time I
 vaguely
> > checked, we were talking maybe 5-digit numbers for costs).
> >
> > Any particular problem you are trying to deal with, or is this just the
> > spirit of adventure and technical curiosity?
> >
> > Regards
> > HJR
> >
>
>
> OK my problem is that I'm not trying to use logminer in order to undo
> SQL queries but to be aware of modifications above particular tables
> or rows of tables.

I'd say from my experience that most people don't use Log Miner for undoing stuff, but as a comprehensive audit utility, without all the extraneous overhead of AUDIT_TRAIL=DB. So you're in good company.

> So in order to identify these rows I need to build something like a
> ROWID dictionnary.
> The problem with partitionned tables is that queries can imply rowid
> modification and it's very hard to notice.
>

Nope, you lost me there. Queries don't modify rows, and aren't in the redo logs at all. DML is. Maybe that's what you meant.

> So I was asked to look in the log files in order to determien if it's
> possible to use them directly instead of using logminer.
>

I confess up front I've never checked for partitioned tables. But every piece of DML stored in the logs includes the rowid, and I would be highly surprised if an update to a row in a partition didn't likewise include the rowid. And I don't quite see why one rowid is any more difficult to notice than another -it's all Base-64 code crap anyway! Have you applied the DBMS_ROWID package against the ROW_ID column in v$logmnr_contents to turn it into something rather more workable (like decimal!).

> I've never found third party tools.
> Are they more efficient?

Wouldn't have a clue. I've only heard about them by reputation, and I've never worked with them. But it depends how you define 'efficient'! They probably have nice point-and-click interfaces, and don't require you to do battle with mangled package/procedure syntax, but I doubt they do much more than Log Miner itself -it's the same redo stream they are analysing, after all.

> If so , it means that there may be more to find in the log files.
>
> Do you know if Oracle agrees giving or sending their log file format?

OK, so you wonder whether the column descriptions in v$logmnr_contents accurately reflects the actual composition of the redo log stream, or whether there are bits and pieces it misses out. I doubt it misses anything major out, but Jonathan or Steve could probably tell you for sure. The speak fluent hexadecimal.

Regards
HJR Received on Tue May 22 2001 - 08:54:13 CDT