DeepEdit!

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

настраиваемого приложения и действий по настройке SQL.

Многсчлет назад, еще до появления версии 7.0, в стране Оракландии у опти­мизатора Oracle не было гибких опций оптимизации операторов SQL. Он тру­дился, используя набор жестко фиксированных внутренних правил. Ну, сейчас нам даже не стоит знать, что это были за правила, но если вы знаете, как он ра­ботал, вы должны оценить некоторые ограничения этого оптимизатора. Ниже мы приводим некоторые из этих правил:

•        Правило № 1  ROWID для одиночной строки. Это правило для

приложений, которые использовали во фразе 

where 

действительные номера строк (ROW1D). О, как же дорого Им приходилось платить в случаях реорганизации табдиц(ы). Или еще того хуже, когда нужно было переводить базу данных в формат Огас1е8, где был принят другой формат ROWID. Как неприятно!

Правило № 8 Доступ по составному индексу (индексу, в который входило более одного столбца).

Правило № 9 Доступ по одностолбцовому индексу.

Правило № 15   Сканирование полной таблицы.

Теперь вы знаете, как он получил название "оптимизатор, основанный на си-
стеме правил". В основном, когда оптимизатор получает для обработки опера-
тор SQL, он начинает работу с самого низа списка, в нашем случае, с правила

№ 

15, и работает, прокладывая себе путь наверх. Если оптимизатор находит ин-
декс (на основании условий во фразе        он выбирает его в качестве индек-
са (в зависимости от его вида), квалифицируемого по правилу № 8 или № 9.
Учитывая, что правила № 8 или № 9 имеют более высокий приоритет, чем пра-
вило № 15 (это связано с тем, что у них меньший номер, чем у правила № 15),
он выполняет запрос в соответствии с ними в предположении, что не нашлось

больше правил, которые можно было бы квалифицировать как позволяющие

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

Ну, а где давал слабину наш оптимизатор? Он не мог определить "самый деше­вый метод", так же, как не имел возможности использовать любые виды функ­ций стоимости и статистики. Например, он оптимизировал операторы SQL на предмет использования индекса или выполнения сканирования полной 

табли­цы 

только на основании наличия одного или нескольких индексов и совокупно­сти правил. Тем самым работа оптимизатора сводилась к действиям машины,
которая вслепую (но во многих случаях удачно) реализовывала набор правил не-
зависимо от того, имело ли смысл их реализовывать. Именно недостаток гибко-
сти и адаптируемости были,        самыми серьезными недостатками
оптимизатора, основанного на системе правил. Существенно отметить, что сто-
имостный оптимизатор (речь о котором пойдет ниже) первоначально был
сконструирован для баз данных с онлайновой обработкой транзакций (OLTP,
online transaction processing). Все дело в том, что во времена оптимизатора,
основанного на системе правил, хранилищ информации еще просто не существовало.

На чем сказывалась негибкость оптимизатора, основанного на системе правил?

Единственным способом обойти негибкость оптимизатора был такой: умышленно        и проделать не слишком сложные действия. Например, во фразе 

where 

оператора SQL ввести какую-либо функцию для
ведущего индексного столбца (типа 

иррег{Ьг&1_пгтё), mund(pnce)

и т. п.), чтобы
добиться принудительного сканирования полной" таблицы. Показанные ниже

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

О  select Lastjiame.   Hire.Pate.  Salary from EMP where Mgr_Id = 123;

По умолчанию этот запрос будет выполняться с использованием индекса (по-
тому что имеется индекс для столбца Mgr_Id с именем Mgr_Id_Idx). Со време-
нем, если менеджеру с учетным номером 123 подчиняется значительное
количество служащих из таблицы        а сканирование индекса не обеспечива-

ет требующейся производительности, запрос переписывается так, как это пока-
зано ниже (чтобы избежать применения индекса MGR_Id_Idx). Мы делаем это
потому, что, если количество блоков, к которым были обращения во время вы-
полнения запроса, начинает превосходить число блоков,        при
сканировании полной               индекс перестает выполнять свои функции.

□ select Last.Name, Hire_Date, Salary

from EMP

where round(Mgr_Id) = 123;

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

Мы принимали подобные меры для обслуживания изменяющихся время от
времени требований к производительности оператора SQL. В конечном счете
это приводило к плохому использованию структуры памяти области коллектив-
ного пула (о чем мы подробно поговорим в главе "Настройка экземпляра - об-
ласть коллективного пула"). Дело в том, что при этом приходится хранить в
памяти несколько версий аналогичных операторов SQL и        их, хотя с функциональной точки зрения они выполняют одни и те же действия.