Re: RAC vs OPS

Jonathan

You are (as always!) correct. The great thing about these newsgroups is that there is (nearly) always someone to correct you if you make a mistake (thank Heaven for that "Additions and corrections welcome" in my sig!). I don't have access to the source (for some strange reason that seems to be fairly tightly controlled), but received an email from one of the developers who confirmed the log flush does take place before shipping across the interconnect for recovery reasons. This is, as you say, the same for RAC as it was for OPS, so that's presumably why it doesn't need to be taken into account for the performance improvement between the two products.

My apologies for any confusion I may have inadvertently caused.

--
HTH.  Additions and corrections welcome.

Pete
Author of "Oracle8i: Architecture and Administration Exam Cram"

"Controlling developers is like herding cats."
Kevin Loney, Oracle DBA Handbook

"Oh no, it's not.  It's much harder than that!"
Bruce Pihlamae, long-term Oracle DBA

"Jonathan Lewis" <jonathan_at_jlcomp.demon.co.uk> wrote in message
news:1013016138.4562.0.nnrp-14.9e984b29_at_news.demon.co.uk...


>

> I think Slava's point is that in a fairly busy system,

> a block could move across the interconnect before

> the first change had committed.  In a non-RAC

> environment, this could mean that the redo would

> not be written for a couple more seconds (i.e. until

> the 3-second timeout, or until the next commit

> irrespective of who did it).  However, in an RAC

> environment, uncommitted redo could be written

> 'prematurely' because the local instance uses the

> cross-instance call from the remote instance as

> another trigger for writing redo.

>

> Of course, this is just the same as it used to be

> in the old OPS ping, since a block can NEVER

> be written before the redo protecting the last

> change has been written; so Oracle is not adding

> an overhead that is new for RAC __when compared

> with OPS___ by doing this; nevertheless there

> is still some potential for busier disk activity in

> an RAC system than in a non-RAC system.

>

>

> --

> Jonathan Lewis

> http://www.jlcomp.demon.co.uk

>

> Now running 3-day intensive seminars

> http://www.jlcomp.demon.co.uk/seminar.html

>

> Host to The Co-Operative Oracle Users' FAQ

> http://www.jlcomp.demon.co.uk/faq/ind_faq.html

>

> Author of:

> Practical Oracle 8i: Building Efficient Databases

>

>

> Pete Sharman wrote in message ...

> >Slava

> >

> >I still go back to my point that this is normal processing that occurs

> >whether we're in single instance mode or not.  We must log the changes to

> >the block and flush them because the block has changed.  Otherwise we're

in


> >a non-recoverable situation, right?

> >

> >If you go back to the original point Howard was making, the step in the

> >processing that is different between OPS and RAC is how we move the block

> >from one node to another.  In OPS that step required a block ping.  In

RAC,


> >the block is passed through the interconenct and is as a result much

> faster.

> >In EITHER case, we need to do the nromal block processing, which we're

> >ignoring for the timing of why the RAC interconnect transfer is so much

> >faster than the OPS block ping.

> >

>

>

>