580 Глава 10

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %: 100.00 Redo NoWait %: 100.00

Buffer Hit %: 99.08 In-memory Sort %: 99.60

Library Hit %: 99.46 Soft Parse %: 98.99

Execute to Parse %: 45.61 Latch Hit %: 100.00

Parse CPU to Parse Elapsd %: 87.88 % Non-Parse CPU: 100.00

Далее показана эффективность работы экземпляра, Instance Efficiency Percentages.

Утверждается, что по этим показателям надо стремиться к 100 процентам, и это почти правда. Единственным исключением, по моему мнению, является показатель Execute to Parse. Он показывает, сколько раз в среднем выполнялся разобранный оператор. В системе, где оператор разбирается, выполняется один раз и больше никогда не выполняется в том же сеансе, этот показатель будет равен нулю. В представленном примере каждый разобранный оператор выполнялся в среднем 1,8 раза (отношение почти два к одному). Хорошо это или плохо, зависит от особенностей системы. В моей системе для всех приложений используется модуль mod plsql. Создается сеанс, выполняется хранимая процедура, формирующая Web-страницу, и сеанс завершается. Если только в одной хранимой процедуре один и тот же SQL-оператор не выполняется несколько раз, отношение количества выполнений к количеству разборов будет небольшим. С другой стороны, если используется клиент-серверное приложение или подключение к базе данных выполняется с сохранением состояния (например, через интерфейс сервлетов), этот коэффициент (он вычисляется как отношение выполнений без разбора к выполнениям с разбором - прим. научн. ред.) действительно должен быть близок к 100 процентам. Я понимаю, однако, что с учетом используемой архитектуры, существенного повышения этого коэффициента в своей системе я добиться не смогу.

Для меня наиболее важными являются показатели разбора, я сразу обращаю на них внимание. Коэффициент Soft Parse показывает процент мягких разборов по отношению к общему количеству выполненн1х разборов. 99 процентов разборов в моей системе б1ли мягкими (повторно использовались планы выполнения запросов из разделяемого пула). Это хорошо. Если процент мягких разборов - низкий, значит, в системе не используются связываемые переменные. Я считаю, что этот показатель должен быть очень близок к 100 процентам, независимо от использовавшихся для разработки приложений средств и методов. Низкое значение показывает, что напрасно тратятся ресурсы и появляются конфликты доступа. Затем надо обратить внимание на коэффициент Parse CPU to Parse Elapsd. В данном случае он имеет значение около 88 процентов. Это маловато; мне надо над этим поработать. В данном случае на каждую секунду процессорного времени, потраченного на разбор, приходится около 1,13 секунды реального времени. Это означает, что часть времени уходит на ожидание ресурсов. Если бы этот коэффициент имел значение 100 процентов, то реальное время было бы равно процессорному, т.е. при обработке никто бы никого не ждал. Наконец, коэффициент Non-Parse CPU показывает отношение времени, потраченного на реальную работу, к общему времени, включая разбор операторов. В отчете это значение вычисляется как round(100*(l-PARSE CPU/ TOT CPU),2). Если общее время работы, TOT CPU, намного превосходит время разбора, PARSE CPU (как и должно быть), этот коэффициент будет очень близок к 100

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

процентам, как у меня. Это хорошо и показывает, что основное время работы компьютера ушло на вшолнение, а не на разбор запросов.

Подводя итоги по предыдущему разделу, я бы рекомендовал сократить количество жестких разборов. Скорее всего в системе есть еще несколько операторов, не использующих связываемые переменные (каждые шесть секунд появляется новый запрос). Это, в свою очередь, сократит общее количество выполняемых разборов, поскольку при жестком разборе выполняется множество рекурсивных SQL-операторов. Убрав лишь один жесткий разбор, можно сократить также и количество мягких разборов. Все остальные показатели в данном разделе выглядят вполне приемлемыми. Рассмотренная первая часть отчета StatsPack мне нравится больше всего - она дает общее представление об относительном здоровье системы. Теперь переходим к остальной части отчета:

Shared Pool Statistics Begin End

Memory Usage %: 75.03 75.26 % SQL with executions>l: 79.18 78.72 % Memory for SQL w/exec>l: 74.15 73.33

Этот маленький фрагмент дает некоторую информацию об использовании разделяемого пула. Рассмотрим показатели более детально:

Memory Usage. Процент использования разделяемого пула. Со временем это значение должно стабилизироваться в диапазоне от 70 с небольшим до 90 процентов. Если процент использования слишком низкий, значит, память тратится напрасно. Если процент слишком высок, значит, происходит вытеснение компонентов разделяемого пула как устаревших, что приводит к жесткому разбору SQL-операторов при повторном выполнении. При правильно подобранном размере разделяемого пула должно использоваться от 75 до не более чем 90 процентов его пространства.

SQL with executions>1. Этот показатель определяет, сколько SQL-операторов в разделяемом пуле выполнялось больше одного раза. К оценке его значения в системах, работающих циклически, с разными задачами в течение дня (например, задачи класса оперативной обработки транзакций в рабочее время и задачи систем поддержки принятия решений по ночам) надо подходить вдумчиво. За изучаемый период многие SQL-операторы в разделяемом пуле могут не выполниться повторно только потому, что в этот период не выполнялись посылающие их процессы. Только если в системе постоянно выполняются одни и те же SQL-опе-раторы, этот показатель может приблизиться к 100 процентам. В данном случае около 80 процентов SQL-операторов в разделяемом пуле использовалось более одного раза за рассмотренный период продолжительностью 13 минут. Остальные 20 процентов моей системе, вероятно, просто не понадобилось повторно выполнять.

Memory for SQL w/exec>l. Этот показатель определяет, сколько памяти используют часто выполняемые операторы SQL по сравнению с теми, которые выполняются редко. В общем случае его значение будет очень близким к проценту нео-

Глава 10

днократно выполнявшихся операторов SQL, если только нет запросов, требующих слишком много памяти. Этот показатель мне не кажется особенно полезным.

Итак, в общем случае в стабильном состоянии должно использоваться от 75 до 85 процентов разделяемого пула. SQL-операторы, выполнявшиеся более одного раза, должны составлять около 100 процентов, если в отчете StatsPack рассматривается достаточно продолжительный период, охватывающий все циклы работы. На этот показатель как раз влияет продолжительность периода между наблюдениями. Чем больший период рассматривается, тем больше должно быть это значение.

Теперь переходим к следующему разделу:

Тор 5 Wait Events

Wait Events for DB: ORA8I Instance: ora8i Snaps: 1 -3 -> cs - centisecond - 100th of a second -> ms - millisecond - 1000th of a second

-> ordered by wait time desc, waits desc (idle events last)

Вот ваша ближайшая цель: события, замедляющие работу намного больше всего остального. Сначала надо посмотреть на значение Wait Time, чтобы понять, стоит ли время ожидания того, чтобы настраивать систему для его уменьшения. Например, за 13 минут я потратил 8,36 секунд в ожидании данных из удаленной базы (data irom a dblink). Стоил ли тратить время на поиски и устранение причины? В данном случае, я считаю, не стоит: среднее ожидание составило 0,004 секунды. Более того, я знаю, что работает фоновый процесс, выполняющий сложную операцию с удаленной базой данных, так что с учетом всех факторов время ожидания получилось весьма небольшим.

Итак, пусть найдено событие, требующее внимания. Сначала нужно понять, что это за событие. Например, если посмотреть описание события log file sync в руководстве Oracle Reference Manual, то можно узнать, что:

Когда пользовательский сеанс фиксирует транзакцию, информация повторного выполнения должна быть сброшена в файл журнала повторного выполнения. Пользовательский сеанс выдает задание процессу LGWR на запись буфера журнала повторного выполнения в файл журнала. Когда процесс LGWR завершит запись, он уведомляет обэтомпользовательский сеанс.

Wait Time: время ожидания включает время записи буфера журнала и уведомления.

время

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