Hi Ed,

I would agree with the _kgl_latch_count change, but the _kgl_bucket_count change seems 
unwarranted and extreme. Rather I
suspect that the size of your library cache hash table rather reflects an oversized 
shared pool, probably with some use
of literal SQL.

@   Regards,
@   Steve Adams
@   http://www.ixora.com.au/              -  For DBAs
@   http://www.secularislam.org/call.htm  -  For Muslims
@   http://www.christianity.net.au/       -  For all


-----Original Message-----
Sent: Friday, 19 October 2001 18:02
To: [EMAIL PROTECTED]
Cc: Steve Adams


Hi Steve,

thanks for your reply. I'm thinking about twice increasing  number of
library latches ( _kgl_latch_count = 23 ) in order to mitigate loading on
them.
Also I would like to set _kgl_bucket_count = 8 according to output of your
script. Do you think it's a good idea in my case.

NAME                          IMPACT SLEEP_RATE    HOLDING     LEVEL#
------------------------- ---------- ---------- ---------- ----------
library cache              60333579.3      0.32%  172945238        5
shared pool                19313269.2      1.40%     8265405         7
cache buffers chains    1950080.11      0.00%       629411         1
row cache objects       738401.912     0.04%    3369329          4
session allocation         70758.0784     0.01%      144008          5
cache buffer handles    56104.2222      0.01%       71913          3
redo allocation            33494.1227      0.02%     215582           6
cache buffers lru chain 12784.3859      0.00%    198869           3
checkpoint queue latch10980.4325      0.00%      52259           7
latch wait list               9976.33016      0.04%      24412           9
redo writing                  4846.5256      0.01%      75484     5

Regards,
Ed

> Hi Ed,
>
> My scripts use the rule of thumb you mention, but it is not a black and
white issue. I would characterise your
> contention here as having a few hot spots, but a general library cache
wide problem as well.
>
> @   Regards,
> @   Steve Adams
> @   http://www.ixora.com.au/
> @   http://www.christianity.net.au/
>
> -----Original Message-----
> Sent: Thursday, 18 October 2001 9:25
> To: Multiple recipients of list ORACLE-L
>
>
> Hi List,
>
> what is the criteria of uneven distribution of sleeps on the library cache
latches? Is there a rule
> of thumb to determine uneven distribution? For example, no of sleeps on a
latch is twice bigger than
> average no of the sleeps on the others latches? Is it correct?
>
> Do you estimate the following distribution as uneven?
>
> NAME                 GETS     MISSES     SLEEPS     SLEEP1     SLEEP2
SLEEP3
> -------------- ---------- ---------- ---------- ---------- ---------- ----
------
> library cache   806881977   10346278    3105912     335866    1020725
217664
> library cache   464142903     3937558    1318015     154644      422509
94864
> library cache   283177601     1991648    1127057     120761      368308
80551
> library cache   839438890     7967497    1478426     195907      479182
95918
> library cache   978851575   13104596    1614737     213383      527238
104408
> library cache   279613950     1453222      759127       77395      255984
51334
> library cache   834477709   11623000    3101181     405102    1058753
168282
> library cache   260953580     1434471      825151       93505      278275
52608
> library cache   470252271     5262933    1484982     162567      489911
103336
> library cache   501042073     5134467    1595443     180043      507939
119648
> library cache  1265644171  25013169    2374937     371608      754426
152126
>
>
> TIA,
> Ed
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Steve Adams
>   INET: [EMAIL PROTECTED]
>
> Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
> San Diego, California        -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Steve Adams
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to