Library cache latch child

@Alex
Дата: 29.09.2004 08:36:55
Господа !
У меня такая ситуация. Периодически много пользователей ожидают latch free (v$session_wait), где P2 = 106 = Library cache latch

Далее вижу что 50% из этих ожидающих имеют одинаковый P1RAW.
P1RAW это адрес "дитяти"

Выполнив
SELECT name, 'Child '||child#, gets, misses, sleeps
FROM v$latch_children
WHERE addr='&P1RAW'

получаю что это 6 child, а всего их 7.

Куда мне двигаться дальше ? как узнать что за этим childom стоит ? Как определить что за кусок программного кеша такой, к которому все лезут ?

С уважением Alex
olek
Дата: 29.09.2004 08:57:11
v$latch_child.child# = v$sql.child_latch
Oracle newbie
Дата: 29.09.2004 11:08:22
Честно говоря не думаю что вам что то скажет информация из v$sqlarea.
одним латчем защищаются достаточно много sql предложений.

Обычно борьба за латчи в кеше предложений является следствием из 2 - неправильных вещей
1) слишком большой shared pool
2) не используются bind variables

В следствиие нарушении этих вещей получается борьба за
library cache latch при парсинге обьекта
shared pool latch при загрузке обьекта в память

то есть
когда время доступа к обьекту увеличивается(большой shared pool) то латчи держаться дольше и получается конкуренция.
когда обьекты часто парсяться , латчи добываются чаще и получается конкуренция.

поэтому борьба вся сводиться к поиску предложений который делают черезмерный парсинг и к тем которые делают парсинг слишком долго.
смотрите на статистики
parse count
execute count
parse time CPU
session cursor cache hits

также посмотреть какие SQL часто парсяться parse_count из v$sqlarea
и конечно же посмотреть похожие SQL статементы, которые не используют bind
variables (v$sqlarea order by sql_text)


Regards.
@Alex
Дата: 29.09.2004 11:25:51
Да, к сожалению парсинг там частый. Скажу больше, парсинг там ОЧЕНЬ частый. Иной раз в трассе на один запрос, парсов больше чем экзекьютов
Программисты используют IMMEDIATE в цикле, и поменять это быстро не удасться, так мне сказал "хозяин".

- С неиспользованием биндов тоже борюсь регулярно
- SHARED pool тоже не большой,

но хочется в такой ситуации выжать больше ....
поэтому и хочу посмотреть что лежит в той области того childa , куда все подозрительно лезут

Спасибо всем за ИНФО !
Oracle newbie
Дата: 29.09.2004 13:59:11
автор
Программисты используют IMMEDIATE в цикле, и поменять это быстро не удасться, так мне сказал "хозяин".


скажи "хозяину" что когда делаешь execute immediate можно использовать USING для bind переменных :-)

Regards.
Markelenkov
Дата: 29.09.2004 22:40:43
Можно как временное решение поюзать:

1. cursor_sharing=force
2. увеличить _kgl_latch_count
3. если на одной защелкой защищаются несколько нагруженных объектов, то можно чуть поменять тексты SQL-выражений/названия таблиц/имена синономов/... (например, добавить пробел в текст SQL и т.д.), чтобы они распределились более равномерно по другим защелкам.
@Alex
Дата: 30.09.2004 06:03:43
Oracle newbie
автор
Программисты используют IMMEDIATE в цикле, и поменять это быстро не удасться, так мне сказал "хозяин".


скажи "хозяину" что когда делаешь execute immediate можно использовать USING для bind переменных :-)

Regards.


Используют где можно, там хитрою строку конструируют