Если у вас есть план выполнения в PLAN TABLE, можно быстро проверить, основан ли он на стоимости, выполнив следующий запрос: SELECT POSITION FROM PLANJABLE WHERE ID-0:

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

Управление синтаксическими планами выполнения в Oracle

Больщинство методов управления синтаксическими планами выполнения - это универсальные приемы управления планами, которые я рассмотрел в первых разделах этой главы. Основной характерный для Oracle способ настройки, когда для optimi2er mode выбрано значение по умолчанию, - синтаксическая оптимизация, достаточно просто В1а1ючить стоимостную оптимизацию, обычно указав необходимый параметр. Например, можно использовать /*+ FIRST ROWS */. Другими словами, вы всегда можете контролировать план при помощи подобных конструкций, и эти управляющие параметры (за исключением /*+ RULE */) в SQL-операторе заставляют Oracle использовать для этого оператора СВО.

Однако если вы не хотите использовать стоимостную оптимизацию, отказываясь от подсказок, остается еще одна техника для RBO. В разделе FROM перечислите таблицы и их псевдонимы в порядке, в точности противоположном желаемому порядку соединения. Обычно это оставляет достаточно свободы для контроля над порядком соединения без использования способов, описанных ранее в разделе Запрещение соединения в неправильном порядке . В частности, допустимые уникальные соединения по первичным ключам производятся в порядке, обратном порядку в разделе FROM, без изменения условий соединения. Например, рассмотрим такой запрос:

SELECT /*+ RULE */ E.F1rst Name, E.Last Name, E.Salary, LE.Description,

M.FirstJame. M.Lastjame. LM.Description FROM Locations LM, Employees M. Locations LE, Employees E WHERE E.Last Name - Johnson

AND E.Manager ID - M.Employee ID

AND E.Location ID - LE.Location ID

AND M.Location ID - LM.Locat1on ID

AND LE.Description - Dallas:

В противоположность предыдущей версии этого запроса в главе 3, где был использован неправильный порядок в разделе FROM, теперь мы получаем правильный порядок соединения. В этом правильном плане вьшолнения Е соединяется с LE перед тем, как М соединяется с LM, что показано в описании плана:

SQL> @ех

PLAN

SELECT STATEMENT NESTED LOOPS NESTED LOOPS NESTED LOOPS TABLE ACCESS BY INDEX RDWID 4*EMPL0YEES INDEX RANGE SCAN EMPLOYEE LAST NAME

TABLE ACCESS BY INDEX ROWID 3*L0CATI0NS INDEX UNIQUE SCAN LOCATION PKEY TABLE ACCESS BY INDEX ROWID 2*EMPLDYEES INDEX UNIQUE SCAN EMPLOYEE PKEY TABLE ACCESS BY INDEX ROWID 1*L0CATI0NS INDEX UNIQUE SCAN L0CATI0N PKEY

Если RBO не может сделать выбор на основе условий и индексов, то он соединяет таблицы справа налево во фразе FROM. Однако сам по себе этот метод оставляет мало пространства для контроля, так как RBO выполняет собственные правила большого пальца перед тем, как выбрать порядок соединения во фразе FROM. Например, если это возможно, RBO всегда выбирает уникальные индексные считывания и соединения перед сканированием диапазонов индекса.

Управление стоимостными планами выполнения в Oracle

Настройка в СВО Oracle состоит из двух основных частей.

Предоставление оптимизатору хорошей статистики по таблицам и индексам, чтобы он смог точно подсчитать стоимость всех вариантов. Это необходимый этап подготовки к ручной настройке в СВО.

Добавление подсказок в запросы, которые СВО не может хорошо оптимизировать, даже имея полную статистику о таблицах и индексах, к которым обращается запрос.

Подготовка к использованию стоимостного оптимизатора

в очередной раз доказывая, что недостаток знания опасен, стоимостные оптимизаторы часто выдают ужасные результаты, если им не предоставлена статистика по всем таблицам и индексам, участвующим в запросе. Таким образом, вам обязательно нужно поддерживать достоверную статистику по таблицам и индексам и, помимо этого, заново генерировать статистику в случае, если существенно изменяется объем таблицы или перестраиваются таблицы или индексы. Самый безопасный способ - периодически заново генерировать статистику, используя для этого отрезки времени, когда нагрузка невелика (например, это может быть ночь или выходные). Для генерации и обновления статистики лучше всего использовать пакет Oracle DBMS STATS, подробное описание которого можно найти в справочниках OracleSi Supplied PL/SQL Packages Reference и Огас1е9г Supplied PL/SQL Packages and Types Reference. Далее приведен простой пример использования пакета DBMS STATS для создания статистики для полной схемы, Appl Prod, с выборкой 10 % данных в больших таблицах и каскадным переходом для сбора статистики в индексах: BEGIN

DBMS STATS.GATHER SCHEMA STATS CApplJrod .10. CASCADE -> TRUE):

END: /

Часто в запросах встречаются условия для сильно асимметричных распределений, например условия по специальным типам, кодам или флагам в случае, когда в этих столбцах присутствует лишь несколько различных значений. Обычно СВО

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

Например, в таблице Orders может быть столбец Status Code с тремя возможными значениями: CL для закрытых (например, выполненных) заказов, СА для отмененных заказов и ОР для открытых заказов. Таким образом, большинство заказов будет выполнено, если приложение проработало несколько месяцев. Значительная часть заказов будет в итоге отменена, поэтому это значение также будет встречаться в большом списке заказов. Однако если бизнес идет хорошо и заказы продолжают поступать, то количество открытых заказов будет оставаться умеренным и стабильным, даже если данные будут накапливаться годами. Достаточно скоро условие Status Code=OP станет достаточно селективным, чтобы оправдать индексированный доступ, если, конечно, у вас есть индекс с таким ведущим столбцом, и важно, чтобы оптимизатор мог понять этот факт. Будет совсем замечательно, если ручная настройка оптимизатору не понадобится. Чтобы СВО мог понять, когда столбец становится селективным, необходимо рассмотреть две причины.

В версиях до Огас1е9г Database в SQL-запросе должно быть указано определенное селективное значение, а не параметр. Использовать параметры удобно, так как SQL-код становится более абстрактным и его удобно разделять между процессами. Однако необходимость явно указывать особенно селективные значения является исключением из этого правила. Если вы укажете Status Code=:l вместо Status Code= OP в версиях сервера до Огас1е9г, то во время разбора кода СВО не сможет ничего узнать о селеетивности условия, поскольку еще неизвестно, будет ли параметру : 1 присвоено распространенное или редко встречающееся значение Status Code. К счастью, в таких случаях обычная причина выбора параметров не имеет значения. Так как у этих специальных кодов есть особенный, важный для бизнеса смысл, маловероятно, что когда-либо потребуется заменить указанное селеюпвное значение каким-нибудь другим.

ПРИМЕЧАНИЕ

В Oracle 9i впервые реализовано предварительное считывание параметра, то есть Oracle проверяет первое значение, назначенное каждому параметру (когда запрос видит его первое упоминание в коде) при выборе плана выполнения. Это устраняет необходимость указывать фиксированные значения вместо параметров, когда все значения, которые потенциально мог>т быть присвоены им, имеют одинаковую селективность. Однако если параметр привязывается и к селективным, и, иногда, к неселективным значениям, вам все же необходимо явно указывать значения в коде, чтобы для различных случаев получать разные планы выполнения.

Вы должны предоставить СВО специальную статистику, которая определяет, насколько редко встречается нераспространенное значение кода, типа или состояния, чтобы СВО мог знать, какие именно значения обладают высокой селективностью.

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