Re: RAC resource affinity

It's a funny document. It uses the word "resource" a lot, and, it seems, with more than one meaning. I'm sorry, but this is going to be a looong explanation (no greek letters, though):

In the good, old days, OPS used locks (called PCM - Parallel Cache Management - locks) to coordinate the access to buffers in the two or more buffer caches. Those extra locks took up memory in the SGA, so the SGA typically grew a good deal due to those Lock Elements, as they were known. Each of them could take up several hundred bytes. I think the extra memory area was called the Lock Area, but I'm not sure.

There were two types of PCM locks - static (hashed) ones, and dynamic ones. To put it briefly, the static ones are faster than the dynamic ones (of course - less computation to perform).

The static ones were hashed to one or more blocks in a datafile using the wonderfull parameter gc_files_to_locks. Remember that each of these locks take up memory. If you wanted one static lock per block in the database you could end up needing a LOT of memory. So you hashed 100s or 1000s of blocks to one static PCM lock in order to save memory (and remember it's part of the SGA). However, if I needed block 42 covered by a certain PCM lock and you wanted block 43 covered by the same PCM lock, a ping (called a false ping) would have to be performed, meaning the need to write block 42 to disk before the PCM lock could be handed over to you in shared mode. So you didn't want a hashed lock to be covering too many blocks, since it would mean too many false pings.

So in 7.3 they came up with dynamic PCM locks. They were slower than static/hashed ones, but you didn't have to think about how many blocks should be covered by a PCM lock, etc. - they were allocated as the need arose. I think they took up slightly more memory per lock, too, but I could be wrong here.

So in 9i they're doing all pings via the High-Speed Interconnect or similar - and they're only using dynamic locks unless you ask specifically for static ones (you can still use the gc_files_to_locks parameter for dire cases). And they're doing smart optimisations in order to minimize the need for checking some of the locks across all the nodes.

So it's all a question of words. "Lock" is now a VBW (Very Bad Word) to use in connection with RAC. They're called enqueues, resources or nothing at all - but never, ever locks. Like deciding that your spade is now officially known as a Digging Tool or Active Hole Creation Aid. It's still a spade to some simple-minded people who don't see the light.

It's a wonderful world. If the documentation and the training materials start to reflect this kind of wording, there'll be lots of things we can teach and tell in order to explain what is really going on. I love it.

chao_ping wrote:

>hi, friends:
>
> You are talking about rac, and I have a question about rac:
> look at http://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=159372.1
> It says resource dynamic remastering, but I cannot find any document talking about how to find out:
>1.What is the unit of the resource? One table, one segment, one block or several blocks?
>2.How to measure which instance is the master of which resource?
>
>
>
>
>Regards
>zhu chao
>msn:chao_ping_at_163.com
>www.happyit.net
>www.cnoug.org(China Oracle User Group)
>
>======= 2003-02-20 07:13:00 ,you wrote£º=======
>
>
>
>>Vladimir:
>>
>>I have not seen any GOOD book for RAC (for that matter even OPS). But
>>the Oracle documentation is very good at least in that front. There are
>>some other books coming (or already published???) for RAC, check
>>amazon.com for the details.
>>
>>
>>
>>=====
>>Have a nice day !!
>>------------------------------------------------------------
>>Best Regards,
>>K Gopalakrishnan,
>>Bangalore, INDIA.
>>--
>>Please see the official ORACLE-L FAQ: http://www.orafaq.net
>>--
>>Author: K Gopalakrishnan
>> INET: kaygopal_at_yahoo.com
>>
>>Fat City Network Services -- 858-538-5051 http://www.fatcity.com
>>San Diego, California -- Mailing list and web hosting services
>>---------------------------------------------------------------------
>>To REMOVE yourself from this mailing list, send an E-Mail message
>>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>>the message BODY, include a line containing: UNSUB ORACLE-L
>>(or the name of mailing list you want to be removed from). You may
>>also send the HELP command for other information (like subscribing).
>>
>>
>
>= = = = = = = = = = = = = = = = = = = =
>
>
>
>
>
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: =?ISO-8859-1?Q?Mogens_N=F8rgaard?=
  INET: mln_at_miracleas.dk

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).