Глава 10

Чтобы избавиться от симптома, надо установить причину. К сожалению, нельзя получить список рекомендаций вида если имеются конфликты при установке такой-то защелки, надо делать то-то (если бы все было так просто!). Если установлено наличие конфликтов при установке защелок, надо вернутся к приложению и определить, при обращении к какому ресурсу происходит конфликт.

Dictionary Cache Stats for DB: 0RA8I Instance: ora8i Snaps: 1 -3

-> Pct Misses

should be very low (< 2% in most cases)

я практически не могу повлиять на выдаваемые в нем числа. Кэш словаря целиком управляется сервером Oracle, и мы не можем изменить размеры его компонентов. Можно задавать только размер разделяемого пула, и если размер этот задан корректно, сервер сам о себе позаботится. Поскольку у меня разделяемый пул используется на 75 процентов, его размер вполне достаточен. Если бы разделяемый пул был заполнен и процент попаданий был низким, увеличение разделяемого пула позволило бы увеличить этот процент.

Library Cache Activity for DB: ORA8I -> Pct Misses should be very low

Instance: ora8i Snaps: 1 -3

Стратегии и средства настройки

Здесь выдается информация о коэффициентах попадания в библиотечный кэш по объектам. В хорошо настроенной системе значение Pct Misses близко к нулю. В системе, используемой для разработки, или в той, где объекты часто создаются и удаляются, некоторые показатели будут иметь большие значения, например, столбец Invalidations. Установка соответствующего размера разделяемого пула и сведение к минимуму количество жестких разборов за счет использования связываемых переменных - вот путь получения хороших значений в данном разделе.

SGA Memory Summary SGA regions

for DB: 0RA8I Instance: ora8i Snaps: 1 -3 Size in Bytes

Database Buffers Fixed Size Redo Buffers Variable Size

134,217,728 69,616 532,480 130,187,264

265,007,088

SGA breakdown difference for DB: ORA8I Instance: ora8i Snaps: 1 -3

Глава 10

В этой части отчета использование разделяемого пула показано более детально. Можно увидеть, как со временем меняется использование памяти каждым из компонентов: некоторые освобождают память, другие - захватывают. Мне эта часть отчета кажется полезной, поскольку объясняет результаты, представленные в других частях. Например, я получил серию отчетов StatsPack для анализа. Они показывали относительно стабильные количества жестких и мягких разборов и вдруг, абсолютно неожиданно, количество жестких разборов превзошло все мыслимые пределы примерно на час, а затем вернулось к обычному уровню. По этому разделу отчета я смог определить, что одновременно с ростом количества жестких разборов существенно (на много десятков мегабайт) уменьшилось использование памяти в области SQL разделяемого пула. Пытаясь понять это, я спросил: Никто не освобождал разделяемый пул? и получил ответ: Конечно, да . Это было стандартной процедурой в ходе работы: каждые шесть часов очищать разделяемый пул. Зачем? Никто не знал - просто всегда так делали. Для этого даже б]ло создано специальное задание. Отключение этого задания решило проблему периодического снижения производительности, которое было вызвано сбросом содержимого разделяемого пула (и одновременно всех планов выполнения запросов, накопленных за шесть часов).

init.ora Parameters for DB: ORA8I Instance: ora8i Snaps: 1 -3

Parameter Name

Begin value

End value

(if different)

background dump dest

compatible

control files

core dump dest

db block buffers

/export/home/ora816/admin/ora8i/b 8.1.0, 8.1.6.0.0

/d01/oradata/ora8i/control01.ctl, /export/horae/ora816/admin/ora8i/c

16384

End of Report