SQL Server 2005 нуждается в ежедневной дефрагментации индекса

Question

Наша производственная база данных нуждается в ежедневной дефрагментации индекса на одной из своих таблиц. Таблица имеет несколько индексов, и один из них будет получать 90% фрагментации каждый день.

Индекс находится в двух полях даты (время начала и время окончания).

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

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

В настоящее время таблица содержит 250 000 записей и увеличивается примерно на 500-3000 записей в день.

Есть идеи, почему он так быстро фрагментируется?

Answer 1

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

Значение коэффициента заполнения по умолчанию равно 0, что в основном рассматривается как коэффициент заполнения 100%, т. Е. Для вставки новых записей индекса не зарезервировано дополнительное пространство. Это идеально, если вы добавляете записи индекса только в конце индекса (например, в поле идентификатора), но не если вы вставляете записи в середине.

Например, вы можете установить коэффициент заполнения 80%, который будет резервировать 20% свободного пространства на каждой странице индекса для вставки новых записей индекса.

Answer 2

Мысль:

• Когда вы перестраиваете индексы, вы реорганизуете или перестраиваете? Перестройка лучше выше 25% фрагментации ish

• При использовании DMO / sqlmaint вы должны сказать «10» для коэффициента заполнения 90

• Вы действительно дефрагментируете все индексы? например, ALTER INDEX ALL ON Mytable ...

• Вы не можете получить 90% -ную фрагментацию с этим уровнем записи, если вы не обновляете эти столбцы более чем на 90% строк ...

Answer 3

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

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