DeepEdit!

Под планом действий (ПД) Oracle мы никоим образом не подразумеваем пла­ны действий корпорации Oracle. То, о чем говорится далее, - это ПД выполне­ния операторов SQL. Операцию Explain Plan можно сравнить с нормальным вопросом, который задается в повседневной жизни, когда мы не совсем увере­ны в планах и программе дня другого лица: каков ваш ПД? Точно так же и для Oracle.

Одним из способов его получения (наверное, самый легкий) является специ­фикация опции 

explain=userid/passwordi 

командной строке утилиты tkprof. Сде­лав это, запрашиваете Explain Plan для операторов SQL, которые вы трассируете, чтобы можно было проверить, выполняет ли Oracle операторы SQL так, как это требуется в смысле производительности. Затем информация команды Explain Plan появляется в выходных данных трассировки для каждого оператора SQL (за исключением рекурсивных SQL и SQL DDL, которые не под­даются объяснению). Если поступил такой запрос, tkprof для хранения плана выполнения, а позже и для создания отчетов по ним использует таблицу из схемы пользователя.

Ниже дается пример команды Explain Plan:

□        select A. Id,  A. Name,   B.Name

from AUTHOR A,  BOOK В

;

where A.Author_Id = B.Book_Author_Id

and A,Author_Id = 101 order by B.Name; Query Plan

1.0  SELECT STATEMENT Statement Cost  =  148 2.1 SORT ORDER RY   (7th) 3.1   FILTER   (6th)

4.1 NESTED LOOPS   (5th)

5.1        TARLE ACCESS RY ROWID AUTHOR   (2nd)

6.1        INDEX UNIQUE SCAN AUTH0R_Id UNIQUE   (1st)

5.2        TABLE ACCESS  BY ROWID  BOOK   (4th)

6.2        INDEX RANGE SCAN BOOK_AUTH_ID NON-UNIQUE   (3rd)

Другой метод - предложить SQL команду Explain Plan:

Q explain plan for

select A. Id, A.Name, B.Name

from AUTHOR A, BOOK В where A.Authored = B.Book_Author_Id

and A.Authored = 101 order by B.Name;

Затем можно выполнить следующую команду для выборки Explain Plan из таблицы Plan_TABLE:

□        select lpadC ', 

2*

(Level -1))| |Operation11' ' 11

decode(ld, 0,  'Cost = '||position) "Operation"", Options, Object_Name from PLAN_TABLE start with Id = 0 connect by prior Id = Parentjd

order by Id;

Не забывайте часто сбрасывать (обнулять) PLAN_TABLE, чтобы защититься от непроизводительных расходов памяти в базе данных (особенно это справедливо для инструментальных средств настройки от третьих фирм).

У нас есть план, может ли кто-нибудь помочь его прочесть?

Описанную в предыдущем разделе команду 

explainplan 

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

уникалыюе, скани­рование 

индекса AUTHOR_II) для просмотра данных из таблицы AUTHOR. Резуль­таты шага 6,1 пересылаются обратно на родительский уровень - 5.1.

Теперь проверим, есть ли на уровне 5 какие-либо другие "братья и сестры", и в данном случае находим один такой - 5.2. У уровня 5.2 есть дочерний уровень -6.2, который является второй выполняемой операцией: RANGE SCAN по индексу BOOK_AUTH_ID (помните, что это 

неуникальный 

индекс) для просмотра дан­ных из таблицы BOOK. Результаты выполнения 6.2 передаются обратно на ро­дительский уровень 5.2.

Другие "дети" уровня 5 отсутствуют, так что объединение результатов 5.1 и 5.2 посылаются обратно их родителям на уровень . 1 (на котором выполняются операции 

вложенных циклов). 

Результаты шага 4.1 пересылаются в 3.1 родителю, которым является 

фильтр (для значения 

101). Затем результаты 3.1 отсылаются наверх в 2.1, где производятся действия ORDER BY, а после этого результаты шага посылаются родителям на самый высокий (1.0) уровень, откуда данные от­правляются в приложение.

Не закладывайте душу за фразу типа Cost=X, потому что в определенные случаях она просто может не иметь смысла. Эта фраза является мерой количества операций ввода/вывода, которые собирается выполнить оператор SQL. Конечно, можно со 100%-ной уверенностью сказать, что Cost= 1000000 - это более дорогой план выполнения (а, значит, для его выполнения потребуется намного больше времени), чем Cost=4567. Но нельзя это отнести ко всем случаям. Так, например, мы наблюдали операторы SQL со стоимостью, скажем, Cost=4500, которые не

обязательно работали быстрее, чем операторы со стоимостью

Cost=4567. Встречается немало случаев, когда более высокие стоимости исполнения для операторов SQL на самом деле срабатывают быстрее. Кроме того, иногда удается отметить прогресс в производительности, когда в оператор SQL включается подсказка/*+HINT*/i и это не так уж плохо.