Re: Is it just me
- From: "Ron Rogers" <RROGERS@xxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 12 Aug 2004 13:40:10 -0400
Jared,
I don't think that it is the amount of data changes even if they are
caused by the Oracle meteorollgists, It depend on the undo_retention
parameter
and the size of the disk space available for the undo_tablespace.
If the undo_retention is set to 1 hour then the undo data is saved for
1 hour.
The space used can be over written after that time frame. If the undo
retention
is set to days then the undo_tablespace will grow intil the time limit
is reached
or the disk fills up and then you have other problems.
If you know the table that was maladjusted you can query the table
with
the SELECT * from tablename VERSIONS BETWEEN clause to see the
difference
in the data. To find out who made the changes you could use the info
in the dba_transaction_query view.
Ron
>>> Jared.Still@xxxxxxxxxxx 08/12/2004 12:26:06 PM >>>
> The idea is not using fashback as the audit trail, but use it very
> temporarily (seconds, or minutes at most) to provide the AQ-handler
with
> actual information. When the queue cannot be handled within a very
> limited amount of time, I think flashback/AQ isn't the right
solution
> either. I like the logminer thing very much. Extending that idea,
one
> could also think of streams to put the logging in a separate database
on
> another server.
This would seem to be a good opportunity for someone to maliciously
modify data, and delete the audit trail. The lack of audit trail
could then be blamed on flashback not having the data due to high
activity.
Or even better, cause a storm of activity, or take advantage of
a naturally occurring one ( Oracle Meteorologists? ) and ensure
the the audit trail for the nefarious activity is never created.
I admittedly know little yet about how flashback works, so maybe
this none of this will work. I'm sure someone will point it out
if so.
Jared
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
