Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: SIEBEL PERFORMANCE RBO to CBO

Re: SIEBEL PERFORMANCE RBO to CBO

From: Milen Kulev <makulev_at_gmx.net>
Date: Mon, 05 Feb 2007 10:39:56 +0100
Message-ID: <20070205093956.311630@gmx.net>


Hi Jonathan ,
you are right (again) ;)

The list of appripriate ML notes:
1) Latch : CAS -> ML 283378.1
2) Heavy Use Of Latches: 'cas latch' And 'simulator hash latch' -> ML 243778.1

According to ML 243778.1 :
"
'Cas latch' is used to simulate an atomic "compare and swap" functionality" for those platforms that are thought not to support this feature in the native
operating system. If the operating system does offer this support then this latch is unused.
HP does not support CAS so this latch is used. "

(Probably)that is why SIEBEL recommends setting db_cache_advice=OFF, in order to reduce SHARED_POOL fragmentation.

Best Regards. Milen

P.S. Which other platform doesn't hava CAS operation ? I am only aware of HPUX .

>
> 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
>

-- 
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail?ac=OM.GX.GX003K11713T4783a
--
http://www.freelists.org/webpage/oracle-l
Received on Mon Feb 05 2007 - 03:39:56 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US