OC 8 RAC and Ruin

Addenda and Errata for Oracle Core Chapter 8 RAC and Ruin

Addenda

p.202

For a convenient reference (until Oracle changes the URL) to the SCAN address, see http://www.oracle.com/technetwork/database/clustering/overview/scan-129069.pdf

Errata

p.209

First line below Note: “… we have v$dlm_ress that is analogous to v$resources …” the second object referenced should be v$resource (singular, not plural).

Typos/Grammar/Style/Punctuation

p.208

Bullet point “GCS”: There should be a closing bracket at the end of paragraph.

Back to Index

Comments (5)

5 Comments »

Hi Jonathan,

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.

Comment by Merrill B Lamont Jr — December 18, 2011 @ 2:03 am UTC Dec 18,2011 | Reply
- Merrill,
  
  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)
  
  Comment by Jonathan Lewis — December 19, 2011 @ 12:35 pm UTC Dec 19,2011 | Reply
11.2.0.1 Scan listeners only support a single ip (TCP) port. The Listener will support mutiple IP ports

Comment by Josie — February 3, 2012 @ 12:55 am UTC Feb 3,2012 | Reply
In RAC and Ruin chapter , Shared Current Buffers [SCUR] are maintained till the execution of the select query is finished . This is applicable to both Single Instance and RAC Databases . Pls let me know .

Thanks,
Prashanth

Comment by Prashanth — September 20, 2012 @ 8:14 am UTC Sep 20,2012 | Reply
- Prashanth,
  
  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.
  
  Comment by Jonathan Lewis — December 31, 2012 @ 12:26 pm UTC Dec 31,2012 | Reply