Re: severe performance issues when flashback is on

>I read that note years ago but it states maximum 30% overhead but as we
can
see from the insert select stats it is not 30% but 300% :-)

hmmm, I'd like to see the proof why 30, not 50 or 150. Ok, in short there are bugs and there are algorithms. If you are hitting a bug then fine. If you are hitting algorithm then... I see flashback feature as almost(but only almost) a redo: some kind of operations(e.g. direct data file modifications) have to go into flashback log file immediately - not into buffer because flashback durability is needed as soon as datafile is modified. LOB handling is a particular case of synchronous flashback writes.
Some operations can be postponed but anyway, every DBWR touch of datafile must save(not allways) a pre-image of a block immediately - because of flashback durability. Under some circumstances (direct writes onto used blocks I'd think) it is necessary to read the pre-image - I'd not be surprised to observe additional direct-reads. All that adds-up into the fact that flashback disk writes must be fast enough...

Please consider the environment before printing this e-mailpro

--
http://www.freelists.org/webpage/oracle-l