К вопросу о реорганизации индексов

dbstalker, 03 июня

Рассмотрим индексы, хранящиеся в В*-дереве. Главная цель использования индекса - обеспечение быстрого доступа к данным таблицы. Отсюда следует, что любой просмотр индекса должен быть организован путем как можно меньшего числа операций чтения блоков. То есть количество листовых блоков, к которым необходимо обратиться при выполнении запроса, должно быть минимальным. Значит, нужно стремиться к тому, чтобы листовых блоков в индексе вообще было мало.

Но дело в том, что индекс на протяжении всей своей жизни может только увеличиваться в объеме, то есть число листовых блоков постоянно растет. Приложения интенсивно обновляют данные в таблице: удаление, добавление и обновление записей. Со временем блоки листьев могут стать фрагментированными из-за расщепления блоков: появляються пустые блоки, незначительно заполненные. К тому же Oracle не уплотняет (coalesce) листовые блоки. То есть при удалении записей из таблицы Oracle не освобождают соответствующие индексные блоки. Это называется естественной деградацией. Пустые блоки индекса невозможно использовать повторно до тех пор, пока индекс не будет коалесцирован (объединен) или перестроен.

К нашему счастью оракл работает так, что преобладающее большинство индексов даже при массовых изменениях в таблице имеют устойчивое состояние. Однако некоторые индексы таблиц, систематически подвергающихся повторяющимся операциям вставки и удаления, все ж таки поддаются серьезному риску фрагментации, приносящей ущерб производительности. Не может не сказаться на производительности приложения то, что в индексе достаточно заметное число листьев после их прочтения оказываются пустыми или почти пустыми. Становится крайне важно определить плотность листьев для индекса. С некоторой натяжкой можно сказать, что чем плотнее упаковано содержимое листьев, тем эффективнее индекс. Принято считать, что индекс является стабильным и сбалансированным, если имеет 70% - 75% плотности. Это означает, что в среднем каждый листовой блок заполнен на 70% - 75% от всего доступного пространства. И все же нужно учитывать, что это как со средней температурой по больнице: индекс может иметь несколько блоков с коэффициэнтом 100%, или, например, - 10%.

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

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

Поэтому перед тем как принять решение по вопросу перестройки индекса, стоит провести серьезный анализ состояния индекса; процессов, где этот индекс используется; имеющихся ресурсов и времени! А, главное, что вы получите в результате перестройки индекса?

Почитайте на досуге еще немного об индексах

Немного полезностей об индексах и их реорганизации К вопросу о реорганизации индексов. Несколько простых советов К вопросу о реорганизации индексов Индексы на основе B* - дерева Как найти листовой индексный блок для конкретной записи таблицы? sys_op_lbid

Тэги: индексы

ОднаКнопка

6 комментариев

Прокоментировать

wudu
6 июня 2010 г. в 03:33

"Пустые блоки индекса невозможно использовать повторно до тех пор, пока индекс не будет коалесцирован (объединен) или перестроен." Это не так. Пустой блок индекса попадает в список свободных блоков и может использоваться повторно.

dbstalker
7 июня 2010 г. в 17:01

На самом деле верны и ваше утверждение, и мое. И вот почему.

Если мы в таблицу, имеющую столбец А, поместили записи со значением в этом столбце от 0 до, например, 1 000 000. Индекс организован по столбцу А.

Затем удалили все записи кратные, скажем, 5. После этой операции индексные блоки у вас стали дырявыми. И эти дырочки будут заполнены только тогда, когда вы вставите записи с соответствующим значением столбца А кратным 5. Или выполните coalesce.

Но если вы удалите все записи у которых столбец А> 500000, то все освободившиеся блоки индекса попадут в список свободных блоков.

wurdu
13 июня 2010 г. в 02:34

Не согласен. Если мы удалим записи кратные 5, то можем вставить записи от 0 до 1000000, например, кратные 6 и они заполнят "дырочки". Совпадение значения совсем не обязательно.

dbstalker
14 июня 2010 г. в 09:04

И тем не менее, бОльшая вероятность того, что вставляться в таблицу будут "неподходящие" для "дырочек" записи. А посему "дырочки" так и останутся.
А не могли бы вы дать источник вашей информации? Я, например, беру в данном случае утверджение Тома Кайта. А вы?

wurdu
13 июня 2010 г. в 03:09

В дополнение. Ели пользоваться более конкретной терминологией, по под "индексные блоки у вас стали дырявыми" надо понимать то, что index entries при удалении на самом деле просто помечаются как удаленные. Но если в дальнейшем в этот блок произойдет вставка - все помеченные как удаленные index entries этого блока очищаются

wurdu
14 июня 2010 г. в 09:22

Ну это легко проверить. Могу также посоветовать блог Richard Foote, в частности серию про Deleted Index Entries. К примеру, http://richardfoote.wordpress.com/2008/06/18/deleted-index-entries-part-ii-v-2-schneider/

 

Новый комментарий

Я не спамер: введите суму 5+7



 

От авторов блога

О Блоге - прочитай перед началом.

Задать вопрос и получить ответ - уже решено 94 вопросов

Глоссарий - список терминов и сокращений


 
 

Бизнес форум

Последние темы:

Шины бу
26 апреля, 2 ответа
Потрібна порада
25 апреля, 2 ответа
Посоветуйте адвоката
25 апреля, 1 ответа