Re: SIEBEL PERFORMANCE RBO to CBO
- From: "LS Cheng" <exriscer@xxxxxxxxx>
- To: jonathan@xxxxxxxxxxxxxxxxxx
- Date: Mon, 5 Feb 2007 11:52:12 +0100
Not sure what does mutex do, if someone can explain...
I have seen a place where _kks_use_mutex_pin was set to FALSE to reduce
compilation time because 100% of application was written in PL/SQL packages
and compiling was a nightmare for them after moving from 9i to 10g,
compilation elapsed time contention was around 400% higher due to library
cache latching. It was z/OS.
On 2/5/07, Jonathan Lewis <jonathan@xxxxxxxxxxxxxxxxxx> wrote:
Idle thought about HP-UX being the only case
where you see CURSOR: PIN S WAIT ON X
I believe the HP chip does not have a compare and
swap operation - which Oracle uses for sharable read
latches on most platforms. I would guess that the
mutex mechanism uses the same chip feature.
Presumably the CAS emulation that Oracle does
on HP-UX works okay for sharable latches, but
has a greater impact on the visibility of mutex
operations.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
Author: Cost Based Oracle: Fundamentals
http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
----- Original Message ----- >
> From: "Milen Kulev" <makulev@xxxxxxx>
> Subject: RE: 10Gr2 and Library Cache Lock Waits
> Date: Sun, 4 Feb 2007 12:13:49 +0100
>
> Ian,
> What waits events (from v$session_wait) do you get ?
> If it is "CURSOR: PIN S WAIT ON X" you can try
> _kks_use_mutex_pin = FALSE.
> I have several databases , that are running since years well, but after
10g
> upgrade
> I have got many "CURSOR: PIN S WAIT ON X".
> Perhaps it is a coinsidence, but all the databases that are experiencing
this
> problem are
> Runnung on HPUX. Perhaps this problem has something to do with mutexes
> implementation
> On HPUX.
>
--
//www.freelists.org/webpage/oracle-l
Other related posts: