DeepEdit!

Этот раздел явился прямым итогом интереснейших дискуссий с одним из от­раслевых экспертов по настройке производительности Oracle Кэри Миллсоп. Перспективы, о которых говорила Кэри, кажутся просто завораживающими. Она пояснила, что оптимизатор, основанный на системе правил, был просто списком приоритетов операторов, а не списком того, насколько быстры планы выполнения операторов в Oracle. Кроме того, она добавила, что когда поняла, что список оптимизатора, основанного на системе правил, совпадает со спис­ком приоритетов операций, приведенным в книге Кернигана и Риччи по про­граммированию на языке С, она шагнула на следующую ступень понимания

оптимизации SQL. Она поделилась с нами следующей аналогией: "возведение в

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

Конкретно, имеется три правила приоритетов:

•        Правило     8   Составной индекс, все ключи перечислены во фразе

where (полный ключ).

•        Правило № 9   Слияние roAND-EQUALS (одиночный индекс или

слияние индексов).

•        Правило № 10   Составной индекс, префикс ключей, перечисленных во фразе where (поиск по ограниченному диапазону индексных столбцов, включая префикс ключа).

Правило № 9 никогда не бывает быстрее правила № но, тем не менее, все­гда выполняется с большим приоритетом. Это здорово вредит заказчикам, кото­рые используют модуль главной книги, входящий в состав Oracle Apps, и

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

where Segment" 1= : vl and Segment2=:v2 and Segment3=:v3 and Segment4=:v4 and Segment5=:v5;

Допустим, у вас имеется индекс, который структурирован следующим обра­зом: glcc_nl(Segment3, Segment 1, Segment2, Segment4, Segment5) ./* Good */. Тогда оптимизатор, основанный на системе правил, воспользуется им для вы­полнения приведенного выше запроса. При этом для выполнения запроса по­требуется меньше полудюжины логических операций ввода/вывода, и его результаты практически мгновенно появятся на экранах большинства систем.

Однако, если вы присоедините к этому индексу столбец Code_Combinati-Hon_Id (как это показано ниже), чтобы устранить доступ к блокам данных, вы тем самым мотивируете слияние AND- EQUALS (Правило ь9), и это приведет ктому, что для выполнения запроса потребуется уже несколько секунд даже для самых быстрых систем: glcc_nl(Segment3, Segmentl, Segment2, Segment4, Segment5, Code_Combination_Id) /* Bad */. Это классический пример сценария, где но­мер правила лучше (более низкий номер правила, но более высокий приоритет, Правило № 9), но производительность была бы лучше при росте номера прави­ла (с более высоким номером правила, но с более низким порядком приоритета,

Правило № 10).