Мониторинг и настройка производительности
Оценить
(0 голоса)
Первый раздел рассматриваемого отчета относится к библиотечному кэшу, который хранит операторы на языках SQL и PL/SQL для многократного использования другими приложениями (в SQL AREA), а также кэширует другие объекты для внутреннего использования СУБД Oracle. SQL>     column library format al2 trunc; SQL>     column pinhitratio heading PINHITRATI; SQL>     column gethitratio heading GETHITRATI; SQL>     column invalidations heading INVALIDATI; SQL>     set numwidth 10; SQL>     Rem Select Library cache statistics.The pin hit rate should be high. SQL>     select namespace library, 2             gets, 3             round(decode(gethits,0,1,gethits)/decode(gets,0,1,gets),3) 4             gethitratio, 5             pins, 6             round(decode(pinhits,0,1,pinhits)/decode(pins,0,1,pins),3) 7             pinhitratio, 8             reloads, invalidations 9             from stats$lib; LIBRARY               GETS GETHITRATI            PINS PINHITRATI RELOADS INVALIDATI…
Оценить
(0 голоса)
Следующий раздел рассматриваемого отчета относится к подключениям пользователей к БД. SQL> column "Statistic"                format a27 trunc; SQL> column "Per Transaction" heading "Per Transact"; SQL> column ((start_users+end_users)/2) heading "((START_OSER" SQL> set numwidth 12; SQL> Rem The total is the total value of the statistic between the time SQL> Rem bstat was run and the time estat was run. Note that the estat SQL> Rem script logs on to the instance so the per_logon statistics will SQL> Rem always be based on at least one logon. SQL> select Users connected at ,to_char(start_time, dd-mon-yy hh24:mi:ss),:,start_users from stats$dates; OSERSCONNECTEDAT   TO_CHAR(START_TIME                               START_OSERS Dsers connected at       …
Оценить
(0 голоса)
Следующие статистические показатели включают некоторые из наиболее важных <онтролируемых параметров. Если проанализировать команду языка SQL, с помощью <оторой были сгенерированы эти результаты, то можно заметить, что выводятся только статистические показатели с ненулевыми значениями. Следовательно, если юзднее еще раз выполнить сценарии utlbstat/utlestat, то можно будет обнару-кить, что в этом разделе отчета появятся новые строки, тогда как другие строки, воз-ложно, исчезнут. Обратите внимание на то, что для каждой статистики предназначен набор из четырех значений: •             Total. Это значение показывает общее количество событий данного типа, происшедших в течение контролируемого интервала времени. •             Per Transaction. Значения в этом столбце нормализованы в соответствии с количеством…
Оценить
(0 голоса)
Используя в Oracle9i выражение для оценивания частоты успешных обращений к кэшу, представленное ранее в настоящей главе, и информацию, приведенную выше, можно вычислить частоту успешных обращений к кэшу для контролируемого интервала времени: При данной частоте успешных обращений к буферному кэшу, равной 96.5%, частота непопаданий (интенсивность промахов) составляет 3.5% и вероятно могла бы быть уменьшена. Является ли данная частота успешных обращений к буферному кэшу приемлемой? При данной интенсивности физических операций чтения (приблизительно 380 операций в секунду) и записи (приблизительно 520 операций в секунду) средняя интенсивность дисковых операций ввода/вывода составляет 900 операций в секунду. Такая нагрузка вероятно могла бы быть поддержана пятнадцатью дисками…
Оценить
(0 голоса)
Закончим обзор данного раздела файла report.txt рассмотрением нескольких показателей из длинного списка статистических данных, выводимых сценариями utlbstat и utlestat. •             dirty buffers inspected. Этот статистический показатель определяет количество раз, когда теневой процесс находил "грязный" буфер в списке буферов LRU (Least Recently Used - наиболее давний по использованию). Обычно Database Writers (редакторы БД) находят такие "грязные" буферы и перемешают их в связанный список заголовков "грязных" буферов. Если редакторы БД работают эффективно, то этот статистический показатель должен иметь нулевое (и следовательно не отображаться в рассматриваемом отчете) или малое значение. Решить данную проблему помогает добавление дополнительных редакторов БД (их количество устанавливается параметром db_writer_processes…
Оценить
(0 голоса)
Запрашивая представления v$system_event и v$session_event как sysdba, можно динамически просматривать события, регистрируемые в следующем разделе файла отчета report.txt. В приводимом отчете все события ожидания разбиты на две категории: нефоновые (переднего плана) и фоновые процессы, где под вторыми понимаются системные процессы Oracle, такие как PHON, SMON и LGWR. События ожидания отсортировываются в порядке убывания общего времени, затраченного на ожидание; единицей измерения является сотая доля секунды. SQL> column "Event Name" format a32 trunc; SQL> set numwidth 13; SQL> Rem System wide wait events for non-background processes (PHON, SQL> Rem SMON, etc). Times are in hundredths of seconds. Each one of Событие ожидания…
Оценить
(0 голоса)
Каждый блок данных поддерживает ограниченное количество параллельных операций доступа для выполнения обновления или удаления; таблица с большим количеством строк в каждом блоке данных и с высокой конкуренцией за доступ к ней может часто испытывать события buffer busy wait. Параметр INITRANS определяет количество параллельно выполняемых операций доступа (его значение по умолчанию равно 1 для таблиц и 2 для индексов). Если сегмент памяти, идентифицированный в представлении v$session_wait, принадлежит таблице или индексу, можно попытаться увеличить значение параметра INITRANS. Параметр INITRANS может быть установлен только в процессе создания таблицы или индекса, для чего придется сбросить и повторно создать таблицу или индекс. Если таблице свойственно…
Оценить
(0 голоса)
Информация относительно ожидания защелки может быть получена из представления v$latch. Когда защелка недоступна, в некоторых случаях запрашивающий процесс может "растягиваться", потребляя ресурсы ЦП в течение некоторого времени перед повторной попыткой, в зависимости от характера защелки. Если защелка все еще недоступна, процесс будет переходить в состояние "бездействия" и пытаться снова получить доступ при запуске. Следующий раздел файла отчета report.txt относится к защелкам именно такого типа. Аналогичная информация может также быть получена из столбцов name, gets, misses и sleeps в представлении v$latch. Информация в следующем разделе рассматриваемого отчета по защелкам не связана с ожиданием. Процессы, не имеющие возможности получить запрашиваемые защелки таким…
Оценить
(0 голоса)
Первый раздел отчета о защелках относится к защелкам с ожиданием. SQL> column latch_name format al8 trunc; SQL> set numwidth 11; SQL> Rem Latch statistics. Latch contention will show up as a large value for SQL> Rem the latch free event in the wait events above. SQL> Rem Sleeps should be low.The hit_ratio should be high. Защелки без ожидания Остальная часть отчета о защелках относится к защелкам без ожидания. Она сопровождается предложениями по мониторингу защелок. Значения в столбце hit_ratio должны приближаться к 1. Следующий список определяет основные защелки, подлежащие мониторингу: •             cache buffers chains. При поиске в кэше блока данных теневой…
Оценить
(0 голоса)
Приводимая далее статистика является полезной в том случае, когда события ожидания занятых буферов предполагают высокую конкуренцию за эти буферы. Соответствующие проблемы обсуждались ранее в настоящей главе в разделе "Общесистемные события ожидания". По мере выполнения транзакций сегменты отката безудержно увеличиваются в размере. СУБД Oracle периодически востребует это пространство, автоматически устраняя экстенты для того, чтобы возвратить размер сегмента отката к оптимальному значению (установленному с помощью параметра OPTIMAL в предложении STORAGE сегмента отката). Значительное количество уплотнений может свидетельствовать о том, что оптимальный размер сегмента отката слишком мал. Однако следует иметь в виду, что установка слишком большого значения параметра OPTIMAL приводит к расходованию пространства…