Re: how 8.1.7.4 calculates the # of 'library cache' latch children ?

From: Tanel Poder <change_to_my_first_name_at_integrid.info>
Date: Thu, 27 Nov 2003 13:48:10 +0200
Message-ID: <3fc5e47a$1_1@news.estpak.ee>

Comments below:

"Alberto Dell'Era" <alberto.dellera_at_bigfoot.com> wrote in message news:f4ed41c5.0311250712.4124d566_at_posting.google.com...
> Does anybody know how the number of 'library cache' latches are
> determined by the 8.1.7.4 kernel ?
>
> Yesterday we had 11 children and today we have 17 of them, after
> (1) upping the shared_pool dimension from 150M to 400M
> (2) increasing cpu_count from 10 to 14
>
> Which one (or other) caused the birth of the 6=17-11 children ?
>
> This is very relevant to us since a f#@%ing third-party applications
> overparses millions of statements (no bind variables, parse
> once-execute once ...) and, until they solve the problem (in 2020AD I
> guess), i would like to limit the damage by at least increasing that
> number.

You can control your number of library cache latches using parameter _kgl_latch_count. You should keep it's value a prime number, the max is 67. In 9i, you can even split your shared pool to be protected by multiple latches using parameter _kghdsidx_count, this may speed up memory allocation process for parsed statements.

But you should first try to reduce parsing, either by pushing the app vendor or using cursor_sharing = force.

Tanel. Received on Thu Nov 27 2003 - 05:48:10 CST