Глава 10

Давайте перейдем к следующей части отчета:

Misses in library cache during parse: 0 Optimizer goal: CHOOSE Parsing user id: 69

Из этого можно сделать вывод, что выполненный запрос б]л найден в разделяемом пуле (количество не найденных в библиотечном кэше запросов равно 0). То есть, выполнялся мягкий разбор запроса. При самом первом выполнении запроса в этой строке будет значение 1. Если практически у всех выполнявшихся запросов будет значение 1, значит, не используются связываемые переменные (это надо исправить). Операторы SQL не используются повторно.

Вторая строка показывает режим работы оптимизатора при выполнении запроса. Эта информация - для справки; выбранный и использованный план выполнения запроса зависит от этого режима.

Наконец, представлен идентификатор пользователя, разобравшего запрос. По этому идентификатору можно получить имя пользователя:

tkyte@TKYTE816> select * from all users where user id = 69;

USERNAME USER ID CREATED

TKYTE 69 10-MAR-Ol

Как видите, запрос разбирал я. Последний раздел отчета TKPROF для данного запроса - план выполнения. Стандартный план выполнения показан ниже:

Rows Row Source Operation

15 SORT GROUP BY

21792 FILTER

21932 NESTED LOOPS

46 TABLE ACCESS FULL USER$

21976 TABLE ACCESS BY INDEX ROWID OBJ$

21976 INDEX RANGE SCAN (object id 34)

30159 FIXED TABLE FULL X$KZSRO

28971 TABLE ACCESS BY INDEX ROWID OBJAUTH$

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

28973 INDEX RANGE SCAN (object id 101)

631 TABLE ACCESS BY INDEX ROWID IND$

654 INDEX UNIQUE SCAAN (object id 36)

Это реальный план запроса, использованный сервером Oracle при выполнении. Интересно, что показано количество обработаннтх на каждом шаге строк. Можно увидеть, например, что 28971 строка б1ла извлечена из OBJAUTH$. Речь идет о строках, полученных в результате выполнения данного шага плана (после применения всех возможных условий, которым должны соответствовать строки таблицы OBJAUTH$, на следующий шаг плана передана 28971 строка). В Oracle 8.0 и более ранних версиях в]давалось количество строк, просмотренных на данном шаге плана выполнения (количество строк, поступивших на вход этого шага). Например, если рассматривалось 50000 строк в таблице OBJAUTH$, но часть из них была исключена конструкцией WHERE, в отчете TKPROF версии Oracle 8.0 выдано было бы в соответствующей строке плана 50000. По этой информации можно понять, от каких шагов выполнения запроса имеет смысл отказаться либо путем изменения запроса, либо с помощью подсказок оптимизатору, выбирающих более удачный план.

Обратите внимание, что вперемешку используются как имена объектов (например, TABLE ACCESS BY INDEX ROWID INDS), так и идентификаторы (например, INDEX UNIQUE SCAN (object id 36)). Причина в том, что в исходном трассировочном файле для некоторых объектов не записаны имена, а только идентификаторы. Кроме того, по умолчанию утилита TKPROF не подключается к базе данных для преобразования идентификаторов объектов в имена. Получить имя объекта по идентификатору можно с помощью запроса:

tkyte@TKYTE816> select owmer, object type, object name

2 from all objects

3 where object id = 3 6;

OWNER OBJECT TYPE OBJECT NAME

SYS INDEX I IND1

Но можно и добавить параметр EXPLAIN= при вызове утилиты TKPROF следующим образом:

С: \oracle\ADMIN\tkyte816\uduinp>tkprof ora01124.trc x.txt explain=tkyte/tkyte

В результирующем файле мы получим следующее сообщение об ошибке:

error during parse of EXPLAIN PLAN statement

ORA-01039: insufficient privileges on underlying objects of the view

Хотя мы и можем выполнить запрос, базовые таблицы, по которым построено представление, недоступны. Чтобы получить план выполнения запроса, необходимо подключиться от имени учетной записи SYS или другой учетной записи, имеющей доступ к базовым объектам.

Я предпочитаю не использовать параметр EXPLAIN= и вам не советую.

Глава 10

Запрос, передаваемый оператору EXPLAIN PLAN, может принципиально отличаться от используемого при реальном выполнении. Единственный план, которому можно доверять, - это план, сохраненный в самом трассировочном файле. Вот простой пример использования утилиты TKPROF с параметром explain=имя/пароль, демонстрирующий это:

count(object type)

select

from

t where object id

> 0

Misses in library cache during parse: Optimizer goal: CHOOSE Parsing user id: 69 (TKYTE)

Rows

Row Source Operation

1 SORT AGGREGATE

21790 TABLE ACCESS BY INDEX ROWID T

21791 INDEX RANGE SCAN (object id 25291)

Rows

Execution Plan

21790

0 SELECT STATEMENT

1 SORT (AGGREGATE) TABLE ACCESS GOAL:

GOAL: CHOOSE

ANALYZED (FULL) OF T

Очевидно, один из планов - неправильный; в одном указано сканирование диапазона по индексу и доступ к таблице по идентификатору строки, а в другом -полный просмотр. Если не знать, что я проанализировал таблицу после выполнения запроса, но до запуска утилиты TKPROF, это расхождение объяснить нельзя. После анализа таблицы стандартный план выполнения этого запроса изменился. Утилита TKPROF использует предоставляемый Oracle стандартный оператор explain plan. В результате выдается план, который использовался бы при выполнении оператора сейчас, а не использованный фактически. Различие планов в трассировочном файле и в результатах выполнения оператора explain plan может обуславливаться многими факторами. Например, приложение могло использовать хранимые шаблоны запросов (подробнее об этой возможности см. в главе 11). В ходе выполнения план мог базироваться на хранящейся схеме, а план, возвращенный оператором explain plan, может оказаться другим. В общем случае, если при вызове утилиты TKPROF все же используется параметр EXPLAIN=, необходимо пошагово сравнить согласованность двух полученных планов.

Утилита TKPROF имеет много опций командной строки, и если ввести команду tkprof, все они будут выданы: