Re: SIEBEL PERFORMANCE RBO to CBO
- From: "Milen Kulev" <makulev@xxxxxxx>
- To: jonathan@xxxxxxxxxxxxxxxxxx, oracle-l@xxxxxxxxxxxxx
- Date: Mon, 05 Feb 2007 10:39:56 +0100
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 .
-------- Original-Nachricht --------
Datum: Mon, 5 Feb 2007 07:33:12 -0000
Von: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
An: oracle-l@xxxxxxxxxxxxx
CC:
Betreff: Re: SIEBEL PERFORMANCE RBO to CBO
>
> 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
>
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen:
http://www.gmx.net/de/go/topmail?ac=OM.GX.GX003K11713T4783a
--
//www.freelists.org/webpage/oracle-l
Other related posts:
