Re: SIEBEL PERFORMANCE RBO to CBO

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_at_jlcomp.demon.co.uk> 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_at_gmx.net>
> > 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.
> >
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

--
http://www.freelists.org/webpage/oracle-l