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

 

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

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

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 148 149 150 151 152 153 < 154 > 155 156 157 158 159 160 .. 161 >> Следующая


6) Методом вложенных циклов присоединить Products через индекс по первичному ключу Product_ID.

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

Проверка планов выполнения

Для этого примера предположим, что разработка базы проводится в Oracle, а затем она тестируется, чтобы проверить, что тот же SQL-код правильно работает и в DB2, и в SQL Server. Вы узнали об этом SQL-коде, так как в Oracle он выполнялся медленнее, чем ожидалось, поэтому уже подозреваете, что он выдает плохой план выполнения, по крайней мере, в этом сервере баз данных. Вам будет необходимо проверить планы выполнения и в других базах данных, которые еще не были протестированы.

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

Поместите SQL в файл с именем tmp. sql и запустите сценарий ex. sql, как описано в главе 3. Вы получите следующий результат:
316

Приложение Б. Полный и непрерывный процесс

PLAN

SELECT STATEMENT SORT ORDER BV 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*PRODUCTS 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.
Проверка планов выполнения

317

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

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

SELECT C.Phone_Number, С.Honorif1с, С. First Jame, С. Last Jame, С.Suffix,

C.AddressJD, A.AddressJD, A.Street_Addr_LTnel, A.Street_Addr_Line2,

A. City Jame. A.State_Abbrev1at1on, A.ZIP_Code, 0D.Deferred_Sh1p_Date,

OD.Iteni_Count. P. Prod Jescrl pt1 on. S. ShipmentJate

FROM Orders 0, Orderjetails OD. Products P, Customers C. Shipments S,

Addresses A

WHERE 0D.0rder_ID - 0.OrderJD AND 0.CustomerJD - C.CustomerJD AND 0D.ProductJD - P.ProductJD AND GD.ShIpmentJD - S.ShIpmentJD AND S.AddressJD - A.AddressJD AND C.PhoneJumber - '6505551212'

AND D.BusinessJnItJD - 10

ORDER BY C.CustomerJD. D.OrderJD Desc, S.ShipmentJD. 0D.OrderJetall JD:

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

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

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

DB20000I The SQL command completed successfully.

OPERATORJD TARGETJD OPERATORJYPE DBJECTJAME CDST

I - RETURN - 260
2 I NLJOIN - 260
3 2 NLJOIN - 235
4 3 NLJOIN - 210
5 4 TBSCAN - 1B5
6 5 SORT - 185
7 6 NLJOIN - 185
B 7 NLJOIN - 135
9 8 FETCH CUSTOMERS 75
10 9 IXSCAN CUST PH NUMBER 50
11 8 FETCH ORDERS 70
12 11 IXSCAN ORDER CUST ID 50
13 7 FETCH ORDER DETAILS 75
14 13 IXSCAN ORDER DTL ORD ID 50
15 4 FETCH PRODUCTS 50
16 15 IXSCAN PRODUCT PKEY 25
17 3 FETCH SHIPMENTS 75
18 17 IXSCAN SHIPMENT PKEY 50
19 2 FETCH ADDRESSES 75
20 19 IXSCAN ADDRESS PKEY 50

20 record(s) selected.

DB20000I The SQL command completed successfully. $
318

Приложение Б. Полный и непрерывный процесс
Предыдущая << 1 .. 148 149 150 151 152 153 < 154 > 155 156 157 158 159 160 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100