DeepEdit!

К анализу буферного кэша базы данных относится получение ее статистики, в том числе: количества логических и физических операций чтения; выполне­ния проверок, позволяющих увидеть, какие сегменты в настоящее время забло­кированы; определения готовых ресурсов, связанных с буферным кэшем базы данных. Информацию обо всем этом можно тщательно отобрать из отчета report.txt, отчетов пакета STATSPACK и представлений V$SYSTEM_EVENT и V$SESSION_EVENT. Кроме того, буферный кэш базы данных предоставляет ин­формацию, которая может помочь в диагностировании связанных с приложени­ем проблем ввода/вывода. Итак, начнем с самого известного - с коэффициента попадания в кэш.

Коэффициент попадания в кэш

"Попасть в кэш" звучит очень похоже на пришедший из Лас-Вегаса термин, имеющий отношение к сфере игорных автоматов. Хотя он и не так возбуждает,

как пребывание в Лас-Вегасе.

Так всего лишь называется отношение величин, показывающих, сколько раз запрашивался блок и сколько раз Oracle терпел неудачу при попытке получить

этот блок из буфера базы данных путем логических или физических операций

чтения. Логическое чтение происходит, когда процесс сервера находит блок в
буферном кэше базы данных. Физическое чтение осуществляется в том случае,
если серверу приходится считывать данные из файла данных и затем копиро-
вать блок в кэше. Вслед за физическим чтением обязательно происходит логи-
ческое чтение (сначала блок считывается с диска в кэш, а затем Oracle
логически считывает его из        хотя не всем операциям логического чтения

предшествует физическое считывание. Логические чтения являются комбина­циями показателей 

consistent get и db block get ш 

представления VSSYSSTAT или от­чета report.txt.

Ниже приводится общепринятая формула определения CHR. В ней вычис­ляется отношение числа физических чтений к числу логических чтений и вычи­тается число физических чтений, предшествовавших логическим.

О CHR = 100* (1 - (physical reads / (consistent gets + db

gets - physical reads))

Если в V$SYSSTAT показаны следующие значения:

= 47229 2148

3923

consistent gets db block gets = physical reads

можно вычислить CHR, как

CHR = 100 *  (1-  (3923/(47229+2148-3923))) = 91,37%

При выполнении анализа CHR не забудьте соотнести его значение со време-
нем суток. Сравните показания в интервале с 14:00 одних суток до того же вре-
мени следующих суток, чтобы определить, имело ли место падение
производительности.'При сопоставлении производительности для двух различ-
ных моментов времени убедитесь, что видите различия в нагрузке и типах вы-
полняемых операций. Например, сравнение производительности в 14:00, когда
имеет место пик активности        с производительностью в 2:00, когда преимущественную нагрузку составляют массивные обновления базы данных посредст­вом пакетных заданий, кажется не совсем допустимым. Не удивительно, что в случаях, подобных этому, производительность будет разной.

При сравнении значений производительности, даже если оно делается для аналогичных моментов времени, следует знать, что значения показателей вторых суток измерений как бы несут в себе значения показателей дня первого. Значения показателей производительности, полученные почти из всех динамических представлений (представлений V$) являются накопительными (кумулятивными) с момента последнего ■старта экземпляра. Выделить показатели первых суток из показателей для вторых суток - очень важная деталь при сборе данных о производительности.

Если реализовано несколько пулов, можно в вопросе с коэффициентами по­падания зайти еще глубже и получить значения этих коэффициентов для отде­льных пулов. Требующаяся информация хранится в представлении V$BUFFER_POOL_$TATISTICS. Для создания этого представления необходимо выполнить сценарий $ORACLE_HOME/rdbms/admin/catperf.sql (если вы не выполнили его раньше). Применяйте туже самую формулу, которой мы пользо­вались при вычислении CHR. Ниже приведен пример запроса к V$BUFFER_

POOL_STATISTICS:

□ select Physical.Reads,   DB_Block_Gets,   Consistent.Gets from V$BUFFER_P00L_STATISTICS where Name =   'KEEP';

Данный запрос можно применить и для пула повторного использования, для чего достаточно заменить строку KEEP на RECYCLE. В случае необходимости изменяются и размеры буферного кэша базы данных для любого из этих пулов. Чтобы добиться осмысленных результатов, советуем прогнать этот запрос не­сколько раз и попытаться уловить тенденцию.

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

И снова, в порядке предупреждения. Значение коэффициента, равное 100%, показывает, что, возможно, для пула сохранения выделено слишком много па­мяти. С другой стороны, для пула повторного использования основная идея со­стояла в том, чтобы его блоки быстро освобождались для следующего, идущего

"повторным циклом" объекта. Как и во всех остальных вопросах, связанных с

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