Re: Maybe very silly question abou Log Miner

Need to go to 9ir2 or else buy a third party product designed to support this feature.

You also need to think about "unsupported" and/or "hard to support" data types. Do you want to audit LONGS? Do you want to audit LOBS? What about "User Defined Types"?

Do you homework and check into LogMiners ability to fully support your needs.

Other Info:

LogMiner pre 9ir2 is severely limited by the type of information included in the redo log. Hence its actual usefulness is limited as well. The redo log was not originally designed to support things like LogMiner. The redo log actually records "datablock level" operations, not "row level" operations.

For example: Consider a chained row which occupies 3 datablocks and has 3 key columns that just happen to be positioned such that there is 1 key column per datablock. An update operation on a nonkey column which resided totally within a single data block would result in the redo log only recording a change for that single affected datablock. There would be no information recorded in the redo log about the other two datablocks since they did not actually change. This makes it very hard for LogMiner to actually report the key value, since the redo log has no information about the other two columns making up the key.

So: In order to support concepts like Oracle Streams & Logical Standby SQL Apply (and LogMiner) additional information has to be recorded in the redo log. The Supplemental Logging feature of 9ir2 provides this. (Note: 9ir1 is not a candidate since its redo log did not contain full support for Streams or the SQL Apply.)

"Dusan Bolek" <pagesflames_at_usa.net> wrote in message news:1e8276d6.0303280047.45cb0dbf_at_posting.google.com...
> I'm trying to use Log Miner as some kind of audit technology. Original
> idea was to take archived redologs and read them on other dedicated
> database. However, I cannot overcome one single problem, which I know
> from beginning of my logmining in 8.1.6. Problem is that keys used for
> identifiing row to be updated (in where conditions) are ommited and
> instead of this in sql_redo from v$logmnr_contents are used rowids.
> Example of original insert:
>
> update log_test set text3 = 'some new value'
> where id = 777;
>
> and INSERT from v$logmnr_contents:
>
> update "BOLEK"."LOG_TEST" set "TEXT3" = 'some new value' where "TEXT3"
> = 'some old value' and ROWID = 'AAAFrVAABAAAHrKAAC';
>
> I knew that this is the format of logminer output, but it still
> puzzles me if there is no other way to find a key used for original
> update. With this is logmining in any other database then the original
> one unusable from audit point of view. For auditing, I need to know
> exactly which row was updated.
> Is there any way to accomplish this, or is this just a limitation that
> logminer has and there is nothing to do with?
>
> Thanks for your answers
>
> --
> _________________________________________
>
> Dusan Bolek, Ing.
> Oracle team leader
>
> Note: pagesflames_at_usa.net has been cancelled due to changes (maybe we
> can call it an overture to bankruptcy) on that server. I'm still using
> this email to prevent SPAM. Maybe one day I will change it and have a
> proper mail even for news, but right now I can be reached by this
> email.
Received on Fri Mar 28 2003 - 10:57:59 CST