Re: RAC vs OPS

Hello Jonathan,
thanks for your absolutely clear answer. I was confused with metalink discussion on the same subject. Oracle guy wrote about log flush before block transfer: "The force log flush indicated is not as costly as having to write the entire block to disk and than read from disk into the other given nodes cache. This flushing if you will does not have to perform a costly disk seek to write only the changes which have occured, given there are changes. So, the IO involved here is very cheap and minimum. "

It seems I realize now how it works.

Regards,
Slava.  

"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.
> >
Received on Thu Feb 07 2002 - 01:54:10 CST