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

28973 INDEX RANGE SCAN (object id 101)

631 TABLE ACCESS BY INDEX ROWID IND$ 654 INDEX UNIQUE SCAN (object id 36)

Утилита TKPROF в]дает массу информации. Давайте рассмотрим ее по частям:

select owner, count(*) from all objects group by owner

Сначала показан исходный запрос в том виде, как он был получен сервером. Так легко можно узнать искомые запросы. В данном случае именно такой запрос я и ввел. Затем идет общая информация о выполнении запроса:

Здесь можно увидеть три основные стадии выполнения запроса.

Стадия PARSE. На этом этапе сервер Oracle находит запрос в разделяемом пуле (мягкий разбор) или создает новый план его выполнения (жесткий разбор).

Стадия EXECUTE. Это действия, выполняемые сервером Oracle при открытии курсора или выполнении запроса. Для операторов SELECT соответствуюшие.стол-бцы часто будут пустыми , тогда как для операторов UPDATE именно на этой стадии все и делается.

Стадия FETCH. Для оператора SELECT именно на этом этапе выполняется основная работа, что и будет отражено в отчете, но для операторов типа UPDATE ничего делаться не будет (при выполнении этого оператора данные не извлекаются).

Заголовки столбцов в этом разделе отчета имеют следующие значения:

CALL. Может иметь одно из значений: PARSE, EXECUTE, FETCH или TOTAL.

Показывает, о какой стадии обработки запроса идет речь.

COUNT. Показывает, сколько раз произошло событие. Это число может оказаться крайне важным. Ниже мы рассмотрим, как интерпретировать значения столбцов.

CPU. Показывает, сколько секунд процессорного времени заняла эта стадия вы-

полнения запроса. Этот столбец заполняется, только если установлен параметр TIMED STATISTICS.

ELAPSED. Показывает, сколько реального времени потребовала эта стадия выполнения запроса. Этот столбец заполняется, только если установлен параметр TIMED STATISTICS.

554 Глава 10

DISK. Показывает, сколько физических операций ввода/вывода с диска потребовалось для выполнения запроса.

QUERY. Показывает, сколько блоков обработал запрос в режиме согласованного чтения. Сюда входят блоки, прочитанные из сегмента отката для получения предыдущего состояния блока.

CURRENT. Показывает, сколько блоков было прочитано в режиме CURRENT*. Блоки в режиме CURRENT читаются в том виде, как они есть на момент чтения, а не в режиме согласованного чтения. Обычно блоки для запроса получаются в том виде, как они были на момент начала запроса. В текущем режиме блоки извлекаются в том виде, как они существуют на момент их чтения, а не какими они б1ли ранее. В ходе выполнения оператора SELECT можно увидеть извлечения в режиме CURRENT, связанные с чтением словаря данных в поисках следующего экстента таблицы при полном просмотре (необходима текущая информация об этом, а не согласованное чтение). В ходе изменения мы будем также обращаться к блокам в режиме CURRENT.

ROWS. Показывает, сколько строк было затронуто на данной стадии обработки.

При выполнении оператора SELECT строки будут обрабатываться на стадии FETCH. При выполнении оператора UPDATE количество обработанных строк будет показано на стадии EXECUTE.

В этом разделе отчета надо обратить внимание на следующие особенности.

Значительн1й процент (около 100) разборов по отношению к в1полнениям, если количество в1полнений - более одного. Берем количество разборов оператора и делим на количество выполнений. Если получаем в результате 1, значит, запрос разбирался при каждом выполнении, и это надо исправить. Желательно, чтобы это отношение стремилось к нулю. В идеале разбор должен быть один, а выполнений - более одного. Если наблюдается значительное количество разборов, значит, выполняется многократный мягкий разбор запроса. Как было показано в предыдущем разделе, это может существенно снизить масштабируемость и производительность даже единственного пользовательского сеанса. Необходимо обеспечить однократный разбор и многократное выполнение запроса в сеансе; от разбора SQL-оператора при каждом выполнении надо избавляться.

Одно в1полнение для всех или почти всех операторов SQL. Если в отчете TKPROF указано, что все операторы SQL выполняются только один раз, скорее всего, не используются связываемые переменные (выполняются похожие запросы, которые отличаются лишь используемыми константами). В трассировочных файлах реальных приложений уникальных операторов SQL обычно немного; одни и те же SQL-операторы выполняются многократно. Слишком большое количество уникальных SQL-операторов обычно означает, что недостаточно используются связываемые переменные.

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

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

ния. Это ожидание может быть вызвано несколькими причинами. Например, на выполнение изменения, заблокированного другим сеансом, уйдет намного больше реального времени, чем процессорного. SQL-запрос, выполняющий большой объем физического ввода/вывода с диска, может долго ждать завершения ввода/вывода.

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

Большая величина отношения (FETCH СОUNT)/(количество извлеченн1х строк). Для ее вычисления берем количество действий типа FETCH (в нашем примере - два) и делим на количество извлеченных строк (в нашем примере - 15). Если полученный результат близок к одному и извлечено более одной строки, приложение не выполняет множественные извлечения. Любой язык или функциональный интерфейс позволяет это делать - извлекать несколько строк одним вызовом. Если возможность множественного извлечения не используется, на пересылки информации с клиента на сервер и обратно уйдет намного больше времени. Этот постоянный обмен информацией, помимо того, что чрезвычайно загружает сеть, выполняется намного медленнее, чем получение нескольких строк одним вызовом. Как организовать множественное извлечение данных в приложении, зависит от используемого языка и/или функционального интерфейса. Например, при использовании Рго*С необходимо выполнять перекомпиляцию с параметром prefetch=NN, в Java/JDBC необходимо вызвать метод SETROWPREFETCH, в PL/ SQL необходимо использовать конструкцию BULK COLLECT в операторах SELECT INTO и т.д. Представленный ранее пример показывает, что утилита SQL*Plus (использованный нами клиент) вызвала FETCH дважды для извлечения 15 строк. Это показывает, что утилита SQL*Plus использовала при выборке массив не менее чем из восьми строк. На самом деле стандартным для SQL*Plus является использование массивов из 15 строк; вторая операция извлечения вернула ноль строк - она получила признак конца результирующего множества.

Слишком большое количество физических обращений к диску. Простое правило для этого параметра придумать сложнее, но если DISK COUNT = QUERY + CURRENT MODE BLOCK COUNT, значит, все блоки читались с диска. Будем надеяться, что при следующем выполнении этого запроса часть блока будет найдена в области SGA. Большое количество обращений к диску - предупреждающий сигнал о том, что необходимо провести дополнительное исследование. Возможно, надо увеличить размер буферного кэша в SGA или придумать другой запрос, требующий чтения меньшего количества блоков.

Слишком большое количество обработанн1х блоков (QUERY или CURRENT). Это

показывает, что запрос обрабатывает большой объем информации. Проблема это или нет - судить вам. Некоторым запросам действительно необходимо обработать много данных, как в представленном ранее примере. Часто выполняемый запрос, однако, должен обрабатывать сравнительно немного блоков. Если сложить значения QUERY и CURRENT количества обработанных блоков и поделить на значение столбца count в строке EXECUTE, должно получаться небольшое число.