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

 

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

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

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


¦ В SQL должно быть указано определенное селективное значение, а не параметр. Использовать параметры удобно, так как SQL-код становится более аб-
122

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

страктным и его можно разделять между процессами. Однако необходимость явно указывать особенно селективные значения — исключение из этого правила. Если вы укажете Status_Code=? вместо Status_Code=‘OP', то во время разбора кода CBO не сможет узнать о селективности условия, поскольку еще неизвестно, будет ли параметру ? присвоено распространенное или редко встречающееся значение Status_Code. К счастью, в таких случаях обычная причина использования параметров не имеет значения. Так как у этих специальных кодов есть особенный, важный для бизнеса смысл, маловероятно, что когда-либо потребуется заменить указанное селективное значение каким-нибудь другим.

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

Если вы запрашиваете специальную статистику по распределению, DB2 также

сохраняет ее. Например, чтобы создать статистику по распределению данных, имея

индекс с именем Order_Stts_Code и схему, владельцем которой является Appl Prod,

используйте следующую команду:

RUNSTATS ON TABLE ApplProd.Orders WITH DISTRIBUTION FOR INDEX ApplProd.Order_Stts Code:

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

Выбор уровня оптимизации

DB2 предлагает несколько уровней оптимизации. Уровень оптимизации — это, грубо говоря, потолок, определяющий, насколько умным пытается быть оптимизатор при рассмотрении набора возможных планов выполнения. На уровне оптимизации О DB2 выбирает план с наименьшей стоимостью в пределах поднабора планов, которые он рассматривает на уровне I. На уровне 1 он рассматривает только поднабор планов, относящихся к уровню 2 и так далее. Считается, что на самом высоком уровне оптимизации мы должны всегда получать наилучший план, так как в этом случае выбирается план с наименьшей стоимостью среди самого широкого диапазона вариантов. Однако планы, полученные на высочайших уровнях оптимизации, обычно являются менее надежными. В противоположность расчетам оптимизатора, эти менее надежные планы часто выполняются дольше, чем наилучший надежный план, который можно получить при оптимизации нижнего уровня. Высокие уровни оптимизации также требуют больше времени на разбор, так как оптимизатору необходимо изучать дополнительные степени свободы. В идеальном случае каждый оператор разбирается на самом низком уровне среди тех, на которых можно найти наилучший план выполнения для данного запроса.

В DB2 предусмотрено семь уровней оптимизации: 0,1,2,3,5,7 и 9*. Обычно по умолчанию устанавливается уровень 5, хотя администратор базы данных может переопределить это значение. Мне никогда не требовался уровень оптимизации

1 Уровни 4,6 и 8 недоступны — возможно, по каким-либо историческим причинам, хотя я никогда не встречал упоминания об этом в документации.
Управление планами в DB2

123

выше 5; уровни 7 и 9 предназначены скорее для экзотических преобразований запросов, необходимость в которых возникает редко. Однако я часто получал отличные результаты на низшем уровне оптимизации, уровне 0, в то время как уровень 5 выдавал плохой план. Перед выполнением запроса (или проверкой плана выполнения) установите уровень 0 при помощи следующего оператора SQL:

SET CURRENT QUERY OPTIMIZATION 0:

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

Изменение запроса

В основном при ручной настройке в DB2 применяются изменения в SQL, описанные ранее в разделе «Универсальные техники управления планами». Однако одна техника заслуживает отдельного упоминания, поскольку ее использование в DB2 намного эффективнее, чем в Oracle или SQL Server. DB2 хранит записи индекса даже для значений null индексированных столбцов и обрабатывает null так же, как и любое другое индексированное значение.

Если в DB2 не хватает специальной статистики по распределению (см. «Подготовка к оптимизации в DB2»), она считает, что селективность условия Индексиро-ванный_столбец IS NULL в точности равна селективности Индексированный_столбец = 198487573 или для любого другого не равного null значения. Поэтому старые версии DB2 часто работают на выглядящем селективным условии IS NULL по индексированным столбцам. Иногда все получается прекрасно. Ho по моему опыту, селективность условия IS NULL очень редко приближается к селективности среднего не равного нулю значения, и индексированный доступ по условиям IS NULL - это практически всегда ошибка.
Предыдущая << 1 .. 56 57 58 59 60 61 < 62 > 63 64 65 66 67 68 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100