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 (9)

9 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 GMT 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 GMT 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 GMT 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 BST 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 GMT Dec 31,2012 | Reply
Hi Jonathan,
I have been trying to understand the connectivity between [ ‘Locks and latches’ pertaining to single instance AND ‘GES’ ] from RAC perspective, but I am unable to get the right clarity.

Is there any inter-dependency between V$DLM_RESS and V$RESOURCES !
Similarly is there any inter-dependency between V$GES_ENQUEUE and V$LOCK !

Let us assume the case of TM lock in RAC database. Is it true that inter-instance enqueue is managed by GES through V$GES_ENQUEUE and intra-instance enqueue is managed using V$LOCK ? Or if it is just V$GES_ENQUEUE, how come it does not have SID as a column to manage different session-requests on the same table if there are 2 different SIDs seeking enqueues on the table back-to-back. I am unable to understand how inter and intra instance enqueue is managed at the SID level in a RAC database.

I know it is too much to ask for, but I could not get a right picture as yet and it would be great if you could manage some time out of your busy schedule to clarify this please.

Thanks and regards,
Vineet Ranjan

Comment by Vineet Ranjan — August 23, 2013 @ 3:29 am BST Aug 23,2013 | Reply
- Hi Jonathan
  
  I am 100% sure you had replied to my query above right after I had posted it. I just thought of looking back and, to my surprise, I am not finding your reply to my query on this page. :(
  It may be the case that you replied to me via an email. However I am unable to track back and find the email in my inbox as well.
  
  It is funny though, but just in case you keep a track of replies somewhere else, I would love to have a look at the answer to above query.
  
  Thanks
  Vineet
  
  Comment by Vineet Ranjan — June 23, 2016 @ 1:22 am BST Jun 23,2016 | Reply
  - Vineet,
    
    I must have been travelling at the time, or not had access to the blog, because I emailed a reply as follows:
    
    That’s a very good question, and one I’ve not considered in detail before.
    
    The answer comes from realising the DLM resources and enqueues are INSTANCE related, and an instance has to have suitable privileges on a resource before a session in that instance take any control of that resource. So:
    
    I believe that when a session requires a lock on a given table (and assuming that no-one else has already set up the necessary resources) its first action is to call the RAC daemons to create a DLM resource for the table with GES_ENQUEUE attached – when the GES Enqueue is available the session can set up the entries in v$resource and v$lock. (I am making assumptions here, and there are details which I simply don’t know – for example if the instance has to wait for the GES_ENQUEUE it’s quite possible that the session is allowed to set up the v$resource and v$lock and then wait for the instance to be granted the GES enqueue – bear in mind that the enqueue may be created but in a “requested” state.
    
    Comment by Jonathan Lewis — June 23, 2016 @ 9:54 am BST Jun 23,2016 | Reply
A usage error, as opposed to a technical one.

Under “How Can It Work?”

Within the third note, this phrase:

“The principle exception is for read-only tablespaces…”

should read,

“The principal exception is for read-only tablespaces…”

Comment by Ted Persky — September 13, 2017 @ 8:37 pm BST Sep 13,2017 | Reply