DeepEdit!

Поскольку индекс хранится в        а важнейшей целью его использова-

ния является обеспечение быстрого доступа к данным таблицы, совершенно очевидно, что любой просмотр индекса должен осуществляться путем наимень­шего числа операций чтения блоков/узлов (снижение числа операций вво­да/вывода является ключом к использованию индексов). Наиболее релевантным фактором здесь является количество блоков листьев, к которым необходимо обратиться. Чем меньше число листьев в индексе, тем меньше по­требуется операций ввода/вывода и тем скорее можно получить данные из таб­лицы. Говоря так, нельзя забывать, что индексы таблиц, подвергающихся повторяющимся операциям вставки и удаления, сталкиваются с наибольшим риском фрагментации.

Вопрос заключается в том, насколько фрагментированы блоки листьев ин­декса? Есть ли достаточно заметное число листьев, которые после их прочте­ния оказываются пустыми? Таким образом, становится крайне важно определить 

плогт wiжъ листьев для 

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

К примеру, если на сегодняшний день имеется 1 тысяча значений строк и
10 блоков листьев, то плотность блоков листьев составляет 1000/10=100 строк.
Если через неделю число строк станет равным но при 20 блоках, то плот-
ность блоков листьев будет равна 1200/20=60 строк. Грубо говоря, это составит
примерно        рост числа блоков, но        уменьшение плотности бло-

ков листьев. Самое время перестраивать индекс, так как в нем наверняка появи­лись пустые блоки.

Еще одним представлением из словаря данных, в котором предлагается дета­лизированная информация об индексах, является INDEXSTATS. Такое словар­ное представление заполняется при выполнении команды analyze index index_name validate structure. Эта команда применима для любого конкретно­го индекса, дополнительную информацию о котором требуется получить. Кро­ме того, в INDEXSTATS содержится столбец с именем 

Height 

(высота), а в нем числа, начиная с 1 (это часть работы по защите заданий). Так же на основании распределения данных в основной таблице можно наблюдать, что некоторые операции по перестройке не уменьшают высоту индекса. Не пытайтесь бороть­ся с этим феноменом до тех пор, пока не созреет план значительного изменения основополагающей таблицы или конструкции всего приложения. Замечание

При выполнении команды analyze index index_name validate structure к представлению INDEX_STATS добавляется одна заполненная строка, но эта строка не сохраняется в интервале между различными сеансами. Строка представления будет немедленно удалена, как только вы выйдете из сеанса. Если желательно сохранить эту информацию, выберите любую таблицу. Эта особенность, скорее похожая на ошибку, была замечена, начинаясверсииОгас1е7.3.0,ипродолжала существовать даже в Oracle 8.1.7.

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

А когда индексы перестраиваются, эту работу нужно сделать быстро и эф­фективно. Двумя факторами, способными помочь в усилиях по перестройке ин­дексов, являются параллелизм и отказ от генерации журнала обновлений. Чтобы использовать первый фактор, можно включить в команду ALTER index... rebuild фразу

parallel 

Для того чтобы задействовать второй фактор, нужно ука­зать в этой команде фразу 

unrecoverable 

(для версий, предшествующих Oracle 8.0) или фразу 

nologging(njin 

Oracle 8.0 и более поздних версий). Учтите, что еще до попытки проведения каких бы то ни было параллельных операций в файл init.ora необходимо включить параметры, инициализирующие работу паралле­льных запросов (см. главу "Настройка параллельных запросов".

□ alter index U_ORD_ID_STATUS_DATE rebuild parallel (degree 4) nologging tablespace INDX

/* 

You can use the ONLINE clause for the above statement if your database version is 0racle8i or above 

*/;

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

Полезно также сжимать и объединять листья индекса, используя для этого опцию 

coalesce 

оператора 

alter index. 

Эта опция способствует объединению бло­ков листьев и/или уровней индекса, так чтобы можно было повторно использо­вать освободившиеся блоки. Обратите внимание на то, что пустые блоки индекса невозможно использовать повторно до тех пор, пока индекс не будет коалесцирован (объединен) или перестроен. Со временем блоки листьев могут стать фрагментированными благодаря расщеплению блоков. Таким образом, высота индекса является одним из ключей к уменьшению количества операций

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

вставки 

и 

удаления.