Another of your questions that slipped through the net, I fear.

Are you quoting something from the book when you make the comment about SCUR being maintained – I can’t find it, but if I said it, it’s wrong.

You have to remember that Oracle is a shared system – you might want to read 100 blocks in a query, and in total isolation they might all come into your local cache as SCUR; but if some of them are already there in SCUR when you start your query it’s possible that a session on another node will demand one of them for update, which means they will need the block in XCUR, so your SCUR could be downgraded to CR before you get to it.

In single instance, of course, the second session would have updated the block and you would need to create a consistent read copy of it when you got there, so the scenario doesn’t quite match.

Thanks,
Prashanth

Thanks for the comments and the link. This is an example of a point where I avoided going into technical detail because of how much extra space that it would take to explain the process; but it certainly merits a little extra space on the blog. The “omitted” material included a couple of srvctl calls to make the point – here’s an example of the effect of crashing node three, and then asking about its (virtual) IP address and listener:

$ srvctl status vip -i linux02 -v
VIP linux02-vip is enabled
VIP linux02-vip is running on node: linux02

$ srvctl status vip -i linux03 -v
VIP linux03-vip is enabled
VIP linux03-vip is running on node: linux02
Detailed state on node linux02: FAILED OVER

$ srvctl status listener
Listener LISTENER is enabled
Listener LISTENER is running on node(s): linux02,linux01

$

The first two calls show us that the node called linux02 is operating two virtual IP addresses: the one which I expect to see for instance linux02, and the one which is normally associatd with instance linux03 which is supposed to be running on node linux03.

Although we have two virtual IPs on node linux02, the last command shows us that we dont have a “magical” extra listener running on linux02; and if I issue a lsnrctl stat call on linux02 I can see that the listener is listening only only the following endpoints:

Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.91.52)(PORT=1521)))

(where 192.68.91.52 is the virtual IP address linux02-vip)

Perhaps a minor (nit) clarification about “handle” current requests, in that “handle” means “send connection refused error to (any new requests)”:

Given this is not a book about RAC, with limited space for explanations, on p201, the text says,

“Because Oracle is using virtual IPs, when a machine fails, one of the other instances will detect the failure very rapidly and take on the virtual IP of the failed machine to handle current requests. This reconfigures the system to stop future connections going to the failed VIP (until the machine and instance are live again). This means that clients will not experience a long wait if the instance they are addressing fails.”

The 11.2 docs say,

http://docs.oracle.com/cd/E11882_01/rac.112/e16795/admcon.htm#CJHJDEHJ

If a node fails, then the node’s VIP address fails over to another node on which the VIP address can accept TCP connections, but it does not accept connections to the Oracle database.

Generally, VIP addresses fail over when:

The node on which a VIP address runs fails
All interfaces for the VIP address fail
All interfaces for the VIP address are disconnected from the network

Clients that attempt to connect to the VIP address receive a rapid connection refused error instead of waiting for TCP connect timeout messages. When the network on which the VIP is configured comes back online, Oracle Clusterware fails back the VIP to its home node where connections are accepted.