PLAN

SELECT STATEMENT SORT ORDER BY NESTED LOOPS NESTED LOOPS NESTED LOOPS NESTED LOOPS NESTED LOOPS TABLE ACCESS FULL 4*CUST0MERS TABLE ACCESS BY INDEX ROWID 1*0RDERS INDEX RANGE SCAN ORDER CUSTOMER ID TABLE ACCESS BY INDEX ROWID 2*0RDER DETAILS INDEX RANGE SCAN ORDER DETAIL ORDER ID TABLE ACCESS BY INDEX ROWID 5*SHIPMENTS INDEX UNIQUE SCAN SHIPMENT PKEY TABLE ACCESS BY INDEX ROWID 6*ADDRESSES INDEX UNIQUE SCAN ADDRESS PKEY TABLE ACCESS BY INDEX ROWID 3*PR0DUCTS INDEX UNIQUE SCAN PRODUCT PKEY

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

SELECT STATEMENT SORT ORDER BY HASH JOIN TABLE ACCESS FULL 3*PR0DUCTS HASH JOIN HASH JOIN HASH JOIN HASH JOIN TABLE ACCESS FULL 4*CUST0MERS TABLE ACCESS FULL 1*0RDERS TABLE ACCESS FULL 2*0RDER DETAILS TABLE ACCESS FULL 5*SHIPMENTS TABLE ACCESS FULL 6*ADDRESSES

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

Получение плана выполнения в DB2

Поместите SQL-код в файл tmp. sql и запустите следующую команду согласно процессу, описанному в главе 3: cat head.sql tmp.sql tail.sql db2 +c +p -t

Результатом будет ошибка; DB2 сообщает, что видит несовместимые типы столбцов в условии по Phone Number. Оказывается, столбец Phone Number принадлежит типу VARCHAR, который не совместим с числовым типом константы 6505551212.

В отличие от Oracle, DB2 не выполняет неявное преобразование столбцов символьного типа в числовые, когда SQL сравнивает несовместимые типы данные. Это именно такой случай, так как преобразование может деактивировать индекс по Phone Number, если таковой существует. Вполне вероятно, что именно этот факт вызвал плохую производительность запроса в основной среде разработки Oracle.

Ошибку можно исправить самым очевидным способом, поместив константу, обозначающую телефонный номер, в кавычки, чтобы преобразовать ее в символьный тип.

SELECT С.Phone Number. C.Honorific, С.First Name, С.Last Name, C.Suffix, C.Address ID, A.Address ID, A.Street Addr tTnel, A.Street Addr Line2, A.CityJame, A.State Abbreviat1on, ATziP Code, 0D.Deferred Sh1p Date, OD.Item Count. P.Prod Descript1on. S.Sh1pment Date FROM Orders 0, Order Details OD. Products P, Customers C. Shipments S, Addresses A

WHERE OD.Order ID - 0.Order ID AND 0.Customer ID - C.Customer ID AND OO.ProductJD - P.ProdUCtJD AND OD.Shipment ID - S.Shipment ID AND S.AddressJD - A.Address ID AND C.Phone Number - 6505551212 AND D.Business Unit ID - 10

ORDER BY C.CustomerJD. D.Order ID Desc, S.ShipmentJD, OD.Order Detail JD:

Сохранив новый вариант SQL-запроса в файле tmp.sql, следует снова получить

информацию о плане вьшолнения:

$ cat head.sql tmp.sql tail.sql db2 +c +p -t DB20000I The SOL command completed successfully. DB20000I The SQL command completed successfully.

OPERATOR ID TARGET ID OPERATOR TYPE OBJECT NAME COST

20 record(s) selected.

DB20000I The SQL command completed successfully. $

Это похоже на план выполнения, который вы выбрали, анализируя SQL-код сверху вниз. Но есть небольшая проблема - таблица Products обрабатьтается до Shipments. Впрочем, это практически никак не будет влиять на время вьтолнения запроса. Так как несовместимость типов, затрагивающая Phone Number, может потребовать исправления в SQL Server и Oracle, вам нужно немедленно опробовать модифицированный вариант в других базах данных.

Получение плана выполнения в SQL Server

Подозревая, что уже получили решение проблемы производительности этого запроса, вы запускаете SQL Server Query Analyzer и используете showplan text, чтобы посмотреть краткое представление плана выполнения оператора, в котором несовместимость типов была исправлена при помощи С.Phone Number = 6505551212. Щелчок по кнопке Execute-Query в Query Analyzer выдает следующий результат: StmtText

I--Bookmark Lookup(...(...[Products] AS [P])) I--Nested Loopsdnner Join)

--Bookmark LookupC...(...[Addresses] AS [A])) j [--Nested Loopsdnner Join)

I -Sort(ORDER BY:([0].[CustomerJD] ASC. (wrapped line) [0].[OrderJD] DESC.

(wrapped line) [OD].[Shipment ID] ASC. [OD].[Order DetailJD] ASC))

I I I --Bookmark Lookup(...(...[Shipments] AS [S]))

I I I--Nested Loopsdnner Join)

I I I--Bookmark

(wrapped line) Lookup(...(...[Order Details] AS [OD]))

I I I [--Nested Loopsdnner Join)

I I I -Filter(WHERE:([0].[Business UnitJD] =

10))

II II I-Bookmark (wrapped line) Lookup(...(...[Orders] AS [0]))

II II I-Nested

(wrapped line) Loopsdnner Join)

II II I--Bookmark

(wrapped line) Lookup(...(... (wrapped line) [Customers] AS [C]))

II II I I--index

(wrapped line) Seek(...(... (wrapped line) [Customers].[Customer Phone Number] (wrapped line) AS [C]). SEEK:([C].[Phone Number] = ббОБББтг) ORDERED)

II II I-index

(wrapped line) Seek(...(...

(wrapped line) [Orders].[Order CustomerJD] AS [0]).

(wrapped line) SEEK:([0].[CustomerJD] = [C].[Customer ID]) ORDERED)

t I I --Index Seek(...(...

(wrapped line) [Order Details].[Order Detail Order ID] (wrapped line) AS [OD]). SEEK:([OD].[Order ID] = [0].[OrderJD]) ORDERED)

t I I--Index

(wrapped line) Seek(...(...[Shipments].[Shipment PKey]

(wrapped line) AS [S]). SEEK:([S].[ShipmentJD] = [OD].[ShipmentJD]) (wrapped line) ORDERED)

I I --Index Seek(...(...[Addresses].[Address PKey]

(wrapped line) AS [A]). SEEK:([A].[AddressJD] = [S].[AddressJD]) ORDERED)