Другие статистические показатели, подлежащие контролю

Оценить
(0 голоса)

Закончим обзор данного раздела файла report.txt рассмотрением нескольких показателей из длинного списка статистических данных, выводимых сценариями utlbstat и utlestat.

•             dirty buffers inspected. Этот статистический показатель определяет количество раз, когда теневой процесс находил "грязный" буфер в списке буферов LRU (Least Recently Used - наиболее давний по использованию). Обычно Database Writers (редакторы БД) находят такие "грязные" буферы и перемешают их в связанный список заголовков "грязных" буферов. Если редакторы БД работают эффективно, то этот статистический показатель должен иметь нулевое (и следовательно не отображаться в рассматриваемом отчете) или малое значение. Решить данную проблему помогает добавление дополнительных редакторов БД (их количество устанавливается параметром db_writer_processes в файле init.ora). В рассматриваемом случае "грязные" буферы обнаруживались 24 раза в секунду, или в среднем по одному разу на каждые восемь транзакций. При этом естественно предположить, чго количество редакторов БД могло быть увеличено с пользой для производительности.

•             redo log space reqaests. Этот статистический показатель определяет количество раз, когда теневой процесс останавливался, ожидая места (пространства) в файле журнала. Обычным заблуждением является мнение, что данный статистический показатель определяет количество раз, когда процесс останавливался в течение своего выполнения, поскольку отсутствовало достаточное количество памяти в буфере журнала. Остановы могут происходить и в контрольных точках.

•             sorts (disk) и sorts (memory). Первый из этих двух статистических показателей определяет количество операций сортировки, которые переходят во временное табличное пространство из-за того, что они не смогли быть размещены в памяти, выделенной в соответствии со значением параметра sort_area_size в файле init.ora. Второй - определяет количество операций сортировки, которые были в состоянии выполняться в оперативной памяти без необходимости обращения к временному табличному пространству. В приведенном отчете в течение 30-минутного периода показано 857 операций сортировки на диске в сравнении с 71791 операцией сортировки в оперативной памяти. Таким образом только чуть больше 1% всех операций сортировки переходит на диск с интенсивностью менее одной сортировки в минуту. Для увеличения значения параметра sort_area_size в данном случае серьезных причин нет.

•             table scans (short tables) и table scans (long tables). Первый из этих двух статистических показателей определяет количество сканирований, выполненных на коротких таблицах (имеющих размер меньший или равный 5 блокам) или на таблицах, которые были помечены как кэшируемые.

Таблицы могут быть определены как кэшируемые либо при создании, либо позднее с помощью команды alter table из sqlplus (например, alter table customer cache;). Обычно блоки данных, считанные во время полного сканирования таблицы, маркируются как LRU, и пространство, которое они занимают, быстро освобождается. В отличие от них блоки данных, считанные из кэшируемых таблиц в процессе их сканирования, обрабатываются как MRU (Most Recently Used - наиболее используемые в последнее время). Кэширование небольших таблиц с высокой частотой обращений может в ряде случаев улучшить производительность.

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

Общесистемные события ожидания
Блок данных
События ожидания защелок
Защелки с ожиданием
Статистика ожидания занятых буферов

Добавить комментарий


Защитный код
Обновить