>Let me do way Jonathan suggested... Sure. >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 -- //www.freelists.org/webpage/oracle-l