лицами, без индексов и с полной статистикой стоимостный оптимизатор создаст

новый план выполнения:

PLAN

SELECT STATEMENT HASH JOIN HASH JOIN HASH JOIN TABLE ACCESS FULL 1*EMPL0YEES TABLE ACCESS FULL 2*EMPL0YEES TABLE ACCESS FULL 3*L0CATI0NS TABLE ACCESS FULL 4*L0CATI0NS

Этот план выполнения идентичен предыдущему, но он заменяет соединения слиянием соединениями хэшированием.

Сложные планы выполнения

Существуют и другие свойства планов выполнения, например, индикаторы, указывающие, какие из соединений являются внешними, перечисление шагов сортировки и операторов, обеспечивающих уникальность сортировки, которые удаляют дублирующиеся значения. С ними вы будете встречаться часто, но их назначение интуитивно понятно и они не столь важны для производительности. Однако есть и важные для нас тонкости, с которыми вы также часто будете иметь дело. Они относятся к подзапросам и составным планам вьшолнения. Я продемонстрирую их в одном примере SQL-запроса:

SELECT /*+ RULE */ E.First Name. Е.Nickname. Е.Lastjame.

E.Phone Number. L.Description FROM Employees E. Locations L WHERE (E.First Name=Kathy OR E.Nickname=Kathy) AND E. Locati on ID=L. Locati onJD AND EXISTS (SELECT null

FROM Wage Payments P WHERE P.Employee ID=E.Employee ID AND P.Payment Date > sysdate-31):

Создадим несколько индексов.

EirployGGS(First Nafrie)

Employees(Nickname)

Locations(Location ID)

Wage Payrrients(Efflployee ID)

Теперь мы получим соответствующий план вьшолнения: PLAN

SELECT STATEMENT CONCATENATION FILTER NESTED LOOPS TABLE ACCESS BY INDEX ROWID 1*EMPL0YEES

INDEX RANGE SCAN EMPLOYEEJICKNAME TABLE ACCESS BY INDEX ROWID 2*L0CATI0NS INDEX UNIQUE SCAN L0CATI0N PKEY TABLE ACCESS BY INDEX ROWID 3*WAGE PAYMENTS

INDEX RANGE SCAN WAGE PAYMENT EMPLOYEE ID FILTER NESTED LOOPS TABLE ACCESS BY INDEX ROWID 1*EMPL0YEES

INDEX RANGE SCAN EMPLOYEE FIRST NAME TABLE ACCESS BY INDEX ROWID 2*L0CATI0NS INDEX UNIQUE SCAN L0CATI0N PKEY

Шаг CONCATENATION указывает, что оптимизатор реализовал запрос как неявный оператор UNION для двух различных запросов (это существенно), один из которых получает данные при помощи индекса Fi rst Naine, а второй - при помощи индекса по полю Nickname. После выполнения внешнего запроса шаг FILTER реализует корреляционное соединение по условию P.Emp1oyee ID=E.Emp1oyee ID, переходя при помощи индекса по внешнему ключу из WagePayments в Employees. Шаг FILTER - это в действительности то же самое, что и соединение со вложенными циклами, за исключением того, что он останавливается после появления первой подходящей строки, если она существует. Обратите внимание, что второй шаг FILTER обращается к тому же корреляционному соединению с WagePayments, что и первый шаг Wage Payments. Это особенность сцепленного плана вьшолнения, который повторяет во внешнем запросе шаги соединений, но не шаги корреляционного соединения.

Чтение планов выполнения в DB2

в DB2 применяется несколько подходов к созданию и отображению планов выполнения. SQL-запрос используется для помещения данных в таблицу, после чего данные можно просмотреть несколькими способами. Вот основные методы, которые компания IBM сама описывает в документации.

Visual Explain. Для Visual Explain требуется инсталляция этой утилиты на рабочей станции клиента, и эта возможность доступна не на всех поддерживаемых платформах. Поэтому я никогда не использовал Visual Explain. Я предпочитаю работать с инструментом, который будет доступен всегда и везде.

Утилита db2exfmt. Эту утилиту можно запустить из командной строки в любой среде, в том числе неграфической, поэтому вы всегда можете рассчитывать на нее. Однако я обнаружил, что она сообщает мне гораздо больше, чем я хочу знать, поэтому иногда работать становится слишком трудно и неудобно. Например, она выдала отчет длиной 1216 строк по плану вьшолнения для простого четырехстороннего соединения. Трудно использовать даже ту часть отчета, которая представляет суть плана выполнения. Дерево плана выполнения отображается в символах ASCII с имитацией графического представления структуры дерева, но для его просмотра, кроме случаев простейших планов вьшолнения, требуется намного большая длина строки, чем человек может легко воспринять.

Собственные запросы к таблицам с данными плана. Этот подход для меня является наилучшим, поэтому я подробно опишу его в данном разделе. Если вы уже знаете, как находить ответы на основные вопросы о плане выполнения (то есть порядок соединения, методы соединения и методы доступа к таблицам).

используя другие инструменты, возможно, вам не понадобится этот раздел, и вы сможете прекрасно работать уже знакомыми вам методами.

Подготовка

DB2 помещает данные плана выполнения в семь таблиц.

EXPLAIN INSTANCE

EXPLAIN STREAM

EXPLAIN OBJECT

EXPLAIN ARGUMENT

EXPLAIN OPERATOR

EXPLAIN PREDICATE

EXPLAIN STATEMENT

Чтобы создать эти таблицы, запустите сценарий EXPLAIN. DDL, расположенный в подкаталоге misc каталога sqllib, будучи подключенным к схеме, в которой вам потребуются эти таблицы. В каталоге mi sc подключитесь к серверу баз данных и активизируйте схему, принадлежащую пользователю, под именем которого вы будете создавать планы выполнения. В командной строке Unix выполните команду: db2 -tf EXPLAIN.DDL

Таблицы плана DB2 содержат информацию об иерархии данных для каждого плана выполнения; наверху иерархии находится EXPLAININSTANCE, в которой для каждого плана выполнения существует отдельная строка. Когда вы удаляете строку из EXPLAININSTANCE, происходит каскадное удаление сведений об этом плане вьшолнения из других таблиц. Обычно ваши планы выполнения хранятся в таблицах в схеме, принадлежащей пользователю, под именем которого вы зарегистрированы. Например, вы под1слючились при помощи такой команды: CONNECT ТО ServerNeme USER UserJIame USING SomePds sword:

В этом случае вы, вероятно, выбрали схему, содержащую данные приложения, поэтому можете запускать запросы для получения этих данных: SET SCHEMA Appljchewa:

Однако последнее действие никак не повлияет на то, где создаваемые вами планы вьшолнения утратят силу. Они все тагсже хранятся в ЕХРЕАШ таблицах в схеме User Name.

Процесс, лежащий в основе отображения планов выполнения

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

1. Удалите все строки из таблицы плана выполнения верхнего уровня EXPLAIN INSTANCE в схеме, которую вы используете для хранения планов выпол-