| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: RAC vs OPS
"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.
Received on Tue Feb 05 2002 - 08:36:02 CST
 |
 |