It's a restriction in log mining that takes some
working around; but it is 'bypassed' in Oracle 9
by using 'supplemental' logging, which is a feature
that allows you to specify that some columns of
a table should appear in the redo log (and log
miner WHERE clause) even if they have not been
changed.
It is possible to set up a system to bypass the
issue (as Quest have done with their product) but
I don't think you can do it with log miner, you have
to be scraping the redo log directly.
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
For one-day tutorials:
(see http://www.jlcomp.demon.co.uk/tutorial.html )
____UK_______April 8th
____UK_______April 22nd
____Denmark May 21-23rd
____USA_(FL)_May 2nd
Next dates for the 3-day seminar:
(see http://www.jlcomp.demon.co.uk/seminar.html )
____UK_(Manchester)_May
____Estonia___June (provisional)
____USA_(CA, TX)_August
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
"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?
>
Received on Fri Mar 28 2003 - 03:17:35 CST
