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

 

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

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

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

120

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

Пример

Приведу пример подсказок, при помощи которых можно добиться полного контроля над планом выполнения. Я принудительно выберу порядок соединения, метод доступа к каждой таблице и метод соединения для каждой таблицы. Рассмотрим ранее встречавшийся нам пример, настроенный для RBO и показанный в конце раздела «Управление синтаксическими планами выполнения в Oracles». Чтобы полностью контролировать план выполнения и при этом заменить первое соединение со вложенными циклами на соединение хэшированием, а местоположение сотрудников считывать через индекс по Description, используйте такой запрос:

SELECT /*+ ORDERED USE_NL(M LM) USE_HASHCLE) INDEX(E Employee_Last_Name)

INDEXCLE Location_Description) INDEX(M Employee_Pkey)

INDEX(LM Loeation_Pkey) */

E.First_Name. E.Last_Name, E.Salary, LE.Description.

M.First_Name. M.Last_Name, LM.Deseription FRDM Employees E. Locations LE, Employees M. Locations LM WHERE E.Last_Name = 'Johnson'

AND E.Manager_ID = M.Employee_ID AND E.Loeation_ID = LE.Location_ID AND M.Loeation_ID = LM.Location_ID AND LE.Deseription = 'Dallas'

Будет получен следующий план выполнения:

SQL> @ех

PLAN

SELECT STATEMENT NESTED LOOPS NESTED LOOPS HASH JOIN

TABLE ACCESS BY INDEX ROWID 1*EMPL0YEES INDEX RANGE SCAN EMPLOYEE_LAST_NAME TABLE ACCESS BY INDEX ROWID 2*LDCATIDNS INDEX RANGE SCAN LOCATION_DESCRIPTION TABLE ACCESS BY INDEX ROWID 3*EMPLDYEES INDEX UNIQUE SCAN EMPLOYEE_PKEY TABLE ACCESS BY INDEX ROWID 4*L0CATI0NS INDEX UNIQUE SCAN LOCATIDN_PKEY

Управление планами в DB2

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

1. Предоставить оптимизатору хорошую статистику по таблицам и индексам, чтобы он мог точно подсчитать стоимость различных вариантов.

2. Выбрать уровень оптимизации, который DB2 будет применять к запросу.

3. Изменить запрос, чтобы запретить нежелательные планы выполнения, используя, в основном, методы, описанные ранее в разделе «Универсальные техники управления планами».
Управление планами в DB2

121

Подготовка к оптимизации в DB2

В очередной раз доказывая, что недостаток знания опасен, стоимостные оптимизаторы часто выдают ужасные результаты, если им не предоставлена статистика по всем таблицам и индексам, участвующим в запросе. Таким образом, вам обязательно нужно поддерживать достоверную статистику по таблицам и индексам и, помимо этого, заново генерировать статистику в случае, если объем таблицы существенно изменяется или перестраиваются таблицы или индексы. Самый безопасный способ — периодически заново генерировать статистику, используя для этого отрезки времени, когда нагрузка невелика, например, это может быть ночь или выходные. Из строки приглашения Unix отредактируйте файл runstats_schema. sql и введите следующие команды, заменяя параметр <Имя_схемы> именем схемы, содержащей объекты, для которых вы хотите собрать статистику:

-- File called runstats_schema.sq1

SELECT 'RUNSTATS ON TABLE <Имя_схемы>.' || TABNAME || 1 AND INDEXES ALL:'

FROM SYSCAT.TABLES

WHERE TABSCHEMA = '<Имя_схемы>':

Чтобы выполнить этот сценарий, зарегистрируйтесь в утилите db2, выйдите в командную строку оболочки командой quit : и выполните две команды:

db2 +р -t < runstats_schema. sql > tmp_runstats.sql grep RUNSTATS tmp_runstats.sql | db2 +p -t > tmp_anal.out

Можно настроить расписание, чтобы эти две команды выполнялись автоматически. Проверяйте содержимое файла tmp_anal. out на тот случай, если при проведении анализа произойдет ошибка.

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

Например, в таблице Orders может быть столбец Status_Code с тремя возможными значениями: 'CL' для закрытых (например, выполненных)заказов, 'CA' для отмененных заказов и ' OP' для открытых заказов. Таким образом, большинство заказов будет выполнено. Поэтому, если приложение проработало несколько месяцев, вы ожидаете, что ' CL' встречается в большой и постоянно увеличивающейся части заказов. Значительная часть заказов будет в итоге отменена, поэтому значение ' CA' также будет встречаться в большом списке заказов. Однако если бизнес идет хорошо и заказы продолжают поступать, то количество открытых заказов будет оставаться умеренным и стабильным, даже если данные будут накапливаться годами. Достаточно скоро условие Status_Code=' OP' станет достаточно селективным, чтобы оправдать индексированный доступ, если, конечно, у вас есть индекс с таким ведущим столбцом. Важно, чтобы оптимизатор мог понять этот факт, причем лучше всего, если для этого не потребуется ручная настройка. Чтобы CBO мог понять, когда столбец становится селективным, необходимо выполнение двух условий.
Предыдущая << 1 .. 55 56 57 58 59 60 < 61 > 62 63 64 65 66 67 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100