Re: Is it just me
- From: Tanel Põder <tanel.poder.003@xxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 12 Aug 2004 17:19:22 +0300
The problem with flashback is of course that you can't nor shouldn't go back
in time too much using it.
Imagine that even if you had 6 months worth of undo space, then when you'd
want to flash back a very frequently modified block, all the undo blocks in
given data block undo chain from present to requested point of time would
have to be applied.
This means lots of CPU + possibly many physical IOs for reading each of the
old undo blocks in, just to get the old value of single row.. Also there is
no possibility whatsoever to index a rollback segment (which, again, you
might not want to do either, in order to keep the auditing overhead low)
Nuno: You're welcome, but be sure to check logminers restrictions first
(which I'm sure you do anyway ;)
Tanel.
----- Original Message -----
From: "Mark W. Farnham" <mwf@xxxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Thursday, August 12, 2004 4:46 PM
Subject: RE: Is it just me
> cool idea, but if the possibility of an insert bottleneck is the main
topic
> at this point, if initrans (or ASSM) fails to keep the audit log from
being
> a pacing object, I'm thinking either real partitioning or poor man's
> partitioning would solve this. Probably who and table_name are decent
> candidates for the partitioning (and of course you still gotta keep some
> sort of date thingy or rotate/grandfather synonyms so you don't die death
by
> monolith.) If one user or table dominates the change stream so much that
it
> alone is a problem, you'd special case that bad boy so its audit write
> bottleneck is no worse than the table or user itself.
>
> Still your idea is intriguing in a cache capacity sort of way. Hmm, does
> this imply that the flashback area itself will be the bottleneck? Not on
the
> retrieval part that you pointed out you could do asynchronously, but the
----------------------------------------------------------------
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:
