Re: Is it just me

From: Tanel Põder <tanel.poder.003_at_mail.ee>
Date: Thu, 12 Aug 2004 17:19:22 +0300
Message-ID: <01cb01c48077$5d6bb5a0$71849fd9@porgand>

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_at_rsiz.com> To: <oracle-l_at_freelists.org> 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_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 - 09:15:39 CDT