Стратегия обслуживания баз — VLDB Переиндексация таблиц

[unfilled]

Добрый день. Спасибо за труд, возникло несколько вопросов:

1. А почему для перестроения индексов вы используете deprecated DBCC DBREINDEX, а не ALTER INDEX ... REBUILD? Rebuild позволяет указывать online/offline, явно ограничивать степень параллелизма, в относительно новых версиях добавлены всякие приятности, типа resumable операций и wait at low priority. Плюс даёт возможность перестраивать только нужные секции индекса. У вас нет секционированных индексов?

2. Почему для не-HOT таблиц учитывается только "внешняя" фрагментация и не учитывает процент заполненности страниц?

3. Зачем везде fillfactor 90? В т.ч. на [DBA].[ReindexJobLog].

4. Почему, для HOT таблиц не учитывается никакая фрагментация и таблицы принудительно перестраиваются полностью?

5. ЕМНИП, табличку с 5-30% даже из актуальной документации убрали.

[Mbogdanov1984]

1. Я полностью с вами согласен по поводу Alter Index - это современная команда, но я написал статью на основании личного опыта. Когда я использовал Alter Index, он не дал такой же эффект в части производительности, как DBCC DBREINDEX. Сначала я не понял в чем дело и думал, что это связано с уровнем совместимости БД, но это не подтвердилось. Один факт был очевиден: когда я использую DBCC DBREINDEX, БД отлично работает, и наоборот.

   Позже, изучив тему подробнее, я выяснил, что DBCC DBREINDEX не только переиндексирует таблицу, но и удаляет из кэша все планы запросов, которые использовали перестраиваемые индексы. Хотя в некоторых источниках пишут, что Alter Index тоже это делает. В моем случае DBCC DBREINDEX полностью удовлетворяет мои потребности. У меня нет секционированных индексов и нет необходимости в онлайн-переиндексации.

2. Ни разу не акцентировал внимание на проценте заполненности (avg_page_space_used_in_percent) страниц при переиндексации, но это будет полезно, особенно если в системе много операций удаления

3. Очень хороший вопрос. Выбор значения Fillfactor зависит от характера использования системы. В моем случае более 80% операций — это чтение данных, а лишь 20% — обновление и запись новых данных, поэтому я выбрал для себя 90%. Я также проанализировал влияние этого параметра на процесс Page split, и всё работает нормально.

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

[unfilled]

Спасибо за ответ.

1. Меня удивляет отсутвие секций и необходимости online-ребилда в VLDB) но - на нет и суда нет)

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

3. Спасибо

4. Если добавить проверку фрагментации для HOT-Таблиц, то может ведь и оказаться, что вполне хватит UPDATE STATISTICS. И таблицы останутся онлайн, и кэши не вымываются, и в журнал транзакций записи практически нет (реплики говорят спасибо)).

[jobgemws]

Обычно fillfactor ставят 80%.

Это рекомендуют везде: и для ERP-систем, и для CRM-систем и т д и т п.

Т е чтобы было не 80% нужны прям сильные аргументы и честно говоря редко когда приходилось ставить иное значение.