Re: RAC vs OPS

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.

>