DeepEdit!

Для построения оптимальных индексов могут оказаться полезными ответы на вопросы:

1.        Сколько блоков ввода/вывода нужно выполнить при индексном поиске
в противоположность сканированию полной таблицы?

Ответ: Если их число известно, то понятно, имеет ли смысл строить и использовать индекс.

2.        Какой набор комбинаций столбцов является наиболее часто
используемым для доступа к данным из той или иной таблицы?

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

проанализируйте операторы SQL. Найдите в V$SQLAREA те из них, которые используются наиболее часто (самое большое число 

executions), 

и затем определите, какие столбцы перечисляются во фразах 

where 

этих операторов.

3.        Какова избирательность любого заданного набора столбцов, для
которого намечено создать индекс?

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

передним краем индекса. Упорядочьте столбцы, выбранные для

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

4.        Все ли столбцы, перечисленные во фразе 

where, 

нуждаются

в индексации?

Ответ:   Не обязательно, если у столбца очень плохое кардинальное число и/или он может принимать значение null. Необходимо сознательно удалить такие столбцы из списка индексирования. Присутствие в индексе таких столбцов не приведет ни к чему хорошему для запроса.

5.        Может ли таблица, для которой создается индекс, использоваться для
транзакций или же к ней возможны только запросы?

Ответ:   Если таблица является транзакционной, необходимо определить возможное отрицательное влияние наличия этого дополнительного индекса на время выполнения транзакций. Каков компромисс между улучшением производительности запросов и отрицательным влиянием на время выполнения транзакций? Если же эта таблица предназначена преимущественно для запросов, то нет ничего страшного в том, чтобы создавать индекс, но следует быть готовым к проблемам с памятью в табличном(ых) пространстве (ах) INDX.

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

транзакционные изменения (много пользователей и мало больших обновлений)?

Ответ:   Если ответ        потратьте время на его нахождение.

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

7.        Нужно ли сохранять индекс для пакетных процессов или можно от него
отказаться либо сделать его

Ответ: Если это неизвестно, обязательно найдите ответ.

8.        Каковы потребности в памяти при создании нового индекса (число
разделов, если они имеются), размеры табличных пространств,
использование памяти и

■

Ответ:   При планировании новых индексов не забывайте о возможностях своего бюджета в отношении большей памяти.

9.        Какие ограничения по времени простоя налагает на приложение
использование индекса?

Ответ:  Если планируется глобальный индекс с префиксом для

секционированной таблицы и требуется частое онлайновое

администрирование, имейте в виду, что такой индекс будет 

неприменим в

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

10. Насколько длительным может оказаться простой, связанный с перестройкой индексов? (Вопрос отпадает сам собой для пользователей Oracle8i, где индексы можно создавать в онлайновом режиме, но для всех остальных он, конечно, остается актуальным.)

Ответ: Если имеются индексы по столбцам, которые заполняются последовательностями Oracle, при проектировании можно заложить монотонное увеличение значений этого столбца, а также и индекса. Все новые значения будут храниться в правой части 

Ъ*-дерева 

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

' Начиная с Oracle8, если входы в блоки индекса совершаются _ для монотонно возрастающих значений (вставок)у блоки заполняются на 100%, а не на 50, как в более ранних версиях. Кроме того, для обеспечения лучшего случайного доступа рассмотрите применение индексов с обратным ключом. Остерегайтесь использовать индексы с обратным ключом для сканирования по интервалу, всегда имеется риск получить намного больше операций ввода/вывода, чем для обычного индекса.

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

на ответах к вопросам 1 и 2.