Re: Cache buffer chains (kslbegin)

  • From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
  • To: <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 25 Apr 2006 08:46:08 +0100

Shared Read latches appeared in 9i (although I have
heard that they may been used in a few cases in 8i).
There are some statistics relating to their use:
       shared hash latch upgrades - no wait
       shared hash latch upgrades - wait

Check Tanel Poder's website for some information
on the technology.

As Mark Bobak points out, as "buffer busy waits" was
your biggest problem, you should be addressing that
at source (at which point any issue you see with the cache buffers chains latches may simply disappear).

However, I see that you have quite a lot of activity on the
multiblock read objects 502,619 472 51
which means you are doing a relatively large amount of
tablescanning, or index fast full scanning. Buffer busy waits
can be a consequence of segment scans, so that might be your
first target for investigation. Note - it is possible to be suffering
from 'disk-based' segment scans even if you don't see much time lost on db file scattered reads, as the scans may be satisfied from filesystem cache.

As others have mentioned, there is a (9i) view that reports segment
level work and waits: v$segment_statistics if you want to use the
friendly but expensive version, v$segstat if you want to use the
cheap version.  Depending on version, this can tell you which object
is subject to most buffer busy waits, and most segment scans.


Jonathan Lewis

The Co-operative Oracle Users' FAQ

Cost Based Oracle: Fundamentals

----- Original Message ----- From: "FreeLists Mailing List Manager" <ecartis@xxxxxxxxxxxxx>
To: "oracle-l digest users" <oracle-l@xxxxxxxxxxxxx>
Sent: Tuesday, April 25, 2006 7:06 AM

Date: Mon, 24 Apr 2006 14:39:23 +0100
From: "Stephen Anderson" <st.anderson@xxxxxxxxx>
Subject: Cache buffer chains (kslbegin)

I have a 10 minute statspack report from a busy time period, and have seen
that buffer busy waits were the highest wait events. Would I be correct to
then look at the Latch Miss Source at the largest sleeps?  I have the
following information there:
Latch Sleep breakdown for DB: MERLIN  Instance: MERLIN  Snaps: 244 -245
-> ordered by misses desc
                                     Get                            Spin &
Latch Name                       Requests      Misses      Sleeps Sleeps
-------------------------- -------------- ----------- -----------
cache buffers chains          156,103,492      15,773       4,067 0/0/0/0/0
simulator hash latch            5,788,739         604          25
multiblock read objects           502,619         472          51
library cache                     486,962         409          44
Latch Miss Sources for DB: MERLIN  Instance: MERLIN  Snaps: 244 -245
-> only latches with sleeps are shown
-> ordered by name, sleeps desc
Latch Name               Where                       Misses     Sleeps
------------------------ -------------------------- ------- ----------
cache buffers chains     kcbgtcr: kslbegin excl           0      2,439
cache buffers chains     kcbrls: kslbegin                 0        973
cache buffers chains     kcbzib: multi-block read:        0
308        0
cache buffers chains     kcbzgb: scan from tail. no       0
199        0

Can anyone confirm what "kslbegin excl" is?  I found something listing
kslbegin as a "macro to lock a latch", but didn't realise you could lock a
latch in anything other than exclusive.  With high sleeps on "kslbegin
excl", where would be the best place to start digging into what caused these
cache buffer chain sleeps?

Many thanks,


Other related posts: