Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 57

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 51 52 53 54 55 56 < 57 > 58 59 60 61 62 63 .. 161 >> Следующая


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

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

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

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

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

В очередной раз доказывая, что недостаток знания опасен, стоимостные оптимизаторы часто выдают ужасные результаты, если им не предоставлена статистика по всем таблицам и индексам, участвующим в запросе. Таким образом, вам обязательно нужно поддерживать достоверную статистику по таблицам и индексам и, помимо этого, заново генерировать статистику в случае, если существенно изменяется объем таблицы или перестраиваются таблицы или индексы. Самый безопасный способ — периодически заново генерировать статистику, используя для этого отрезки времени, когда нагрузка невелика (например, это может быть ночь или выходные). Для генерации и обновления статистики лучше всего использовать пакет Oracle DBMS_STATS, подробное описание которого можно найти в справочниках Огас1е8г Supplied PL/SQL Packages Reference и Oracle9i Supplied PL/SQL Packages and Types Reference. Далее приведен простой пример использования пакета DBMS_STATS для создания статистики для полной схемы, Appl_Prod, с выборкой 10 % данных в больших таблицах и каскадным переходом для сбора статистики в индексах:

BEGIN

DBMS_STATS.GATHER_SCHEMA_STATS ('ApplJrod' .10.

CASCADE -> TRUE):

END:

/

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

4. Управление планами выполнения

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

Например, в таблице Orders может быть столбец Status_Code с тремя возможными значениями: 'CL' для закрытых (например, выполненных) заказов, 'CA' для отмененных заказов и 'OP' для открытых заказов. Таким образом, большинство заказов будет выполнено, если приложение проработало несколько месяцев. Значительная часть заказов будет в итоге отменена, поэтому это значение также будет встречаться в большом списке заказов. Однако если бизнес идет хорошо и заказы продолжают поступать, то количество открытых заказов будет оставаться умеренным и стабильным, даже если данные будут накапливаться годами. Достаточно скоро условие Status_Code='0P' станет достаточно селективным, чтобы оправдать индексированный доступ, если, конечно, у вас есть индекс с таким ведущим столбцом, и важно, чтобы оптимизатор мог понять этот факт. Будет совсем замечательно, если ручная настройка оптимизатору не понадобится. Чтобы CBO мог понять, когда столбец становится селективным, необходимо рассмотреть две причины.

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

ПРИМЕЧАНИЕ------------------------------------------------------------------------

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

¦ Вы должны предоставить CBO специальную статистику, которая определяет, насколько редко встречается нераспространенное значение кода, типа или состояния, чтобы CBO мог знать, какие именно значения обладают высокой селективностью.
Предыдущая << 1 .. 51 52 53 54 55 56 < 57 > 58 59 60 61 62 63 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100