Re: Is it just me

From: Ron Rogers <RROGERS_at_galottery.org>
Date: Thu, 12 Aug 2004 13:40:10 -0400
Message-Id: <s11b7355.098@galottery.org>

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_at_radisys.com 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_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/ 
FAQ is at http://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_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Thu Aug 12 2004 - 12:50:09 CDT