Re: RAC vs OPS

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.

--
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

"Slava" <leichivp_at_my-deja.com> wrote in message
news:a775741a.0202050636.5a5375f3_at_posting.google.com...


> "Pete Sharman" <peter.sharman_at_oracle.com> wrote in message

news:<_xB78.8$P87.371_at_inet-nntp1.oracle.com>...


> > I think this is just a case of less than clear documentation.  I looked

at


> > the 9.2 beta doc and that entire phrase has disappeared, which sort of

> > reinforces my opinion.

> >

> > What happens really is what I sent out in mid January and what I told

Nuno


> > to go looking for.  If you need that sent again I can probably find the

> > email, but a search of the newsgroup should locate it.  The pinning,

logging


> > etc. is normal processing we go through regardless of whether this is

RAC or


> > not.

> >

>

> Hello Pete,

> I've found your previous message. You wrote:

> "Instance 1 now makes a change and commits it (SCN is now 1001). Again

> it

> communicates this to the GCS, which updates the SCN information it's

> tracking. Status is still XL0.

>

> Instance 2 now decides it wants to update another row or even the same

> row

> in the same block (Instance 1 has committed so another update to the

> same

> row is fine). Instance 2 asks the GCS who has the block. GCS tells

> instance

> 2 that instance 1 has it, and tells instance 1 to send it to instance

> 2

> ACROSS THE INTERCONNECT (i.e. no pinging to disk which is where the

> performance hit came in OPS). "

>

> But what's happened if transaction is not yet committed? This scenario

> is described in the article "ORACLE9i REAL APPLICATION CLUSTERS

> DEPLOYMENT FOR THE ENTERPRISE" (you can find this one at

> www.oracle.com/openworld):

> "If Instance 1 has dirtied the block, Instance 1 completes its work

> (i.e. logging any changes to the block and forcing a flush,

> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> and converting its usage of the block from XL0 to NG1 to indicate it

> now holds a past image), and ships the block to Instance 2. "

>

> Regards,

> Slava.