Re: cursor: pin S wait on X

  • From: "K Gopalakrishnan" <kaygopal@xxxxxxxxx>
  • To: "Mladen Gogala" <mgogala@xxxxxxxxx>
  • Date: Fri, 28 Apr 2006 14:09:17 -0700


Yes, It is_kks_use_mutex_pin asking the (K)ompliation layer
to use the mutex.I was on the road while replying that message
hence the swap.

You are right on intelligent than latch part as latches themself
become hot and introduce a false contention. Mutex on the other
hand does not become hot as every structure can have (at least)
theoritically its own mutex.And also mutex is lighter than latches.


On 4/28/06, Mladen Gogala <mgogala@xxxxxxxxx> wrote:
Actually, it's "_kks_use_mutex_pin". The explanation that I have
is that mutexes are "a bit more intelligent latches", which
"are split in phases and can share locks in so called parse or
 compilation phases". The only Metalik paper that mentions the
parameter is the note 216205.1.

--- K Gopalakrishnan <kaygopal@xxxxxxxxx> wrote:

> Charles:
> Cursor: pin S wait on X is used like a replacement to library cache
> pin either during compiling the child or the execution of the KGL
> object. You see this wait when the mutex is held by the other session
> on X mode.
> You can look the V$mutex_sleep views to find out the requesting
> session and blocking session and deal this issue like the same old
> library cache pin waits.
> If you want the traditional library cache mechanism to be used for
> library cahce operations, you can turn this feature (!) off by setting
> the parameter _use_kks_mutex_pin to false.
> Other alternative is to look in the mutex_sleep view and find the
> locations of the waits. This will give a clear picture on which
> location it is waiting for that wait.
> --
> Best Regards,
> K Gopalakrishnan
> Co-Author: Oracle Wait Interface, Oracle Press 2004
> --

Mladen Gogala Oracle DBA

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around

Best Regards,
K Gopalakrishnan
Co-Author: Oracle Wait Interface, Oracle Press 2004

Other related posts: