Re: severe performance issues when flashback is on

  • From: Laimutis.Nedzinskas@xxxxxx
  • To: LS Cheng <exriscer@xxxxxxxxx>
  • Date: Fri, 21 Oct 2011 08:42:41 +0300

>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


Other related posts: