Я унаследовал несколько систем SQL Server 2005 и 2008 (все работают в режиме простого восстановления), каждая из которых в настоящее время каждую ночь выполняет следующие действия из задачи агента SQL:
Я остановил сжатие, так как это, вероятно, вызовет больше проблем, чем решит. (Использование сервера заключается в хранении постоянного объема информации на скользящей 5-дневной основе, поэтому пространство из удаленных строк будет снова использовано для свежей информации без особого увеличения).
Однако я не знаю, следует ли мне также останавливать задание ночной переиндексации. Это было необходимо, когда сжатие было активным из-за массивной фрагментации индекса, вызванной сжатием. Я не могу найти в Интернете много информации о том, когда может быть целесообразно еженощное переиндексирование. Должен ли я тоже отключить это?
Если информация накатывается, это указывает на то, что большая часть, примерно 20%, от общей базы данных вставляется каждый день. Это указывает на то, что ваша статистика и ваши индексы ошибочны на 20%.
Похоже, это именно те условия, для которых вам следует переиндексировать.
По сути, сжатие и переиндексирование просто отменяли друг друга (таблицы фрагментов сжатия для восстановления пространства, затем переиндексирование использует дополнительное пространство для дефрагментации таблиц).
Итак, поскольку вы удалили усадку, вы наверное также может удалить ночной переиндекс. (В большинстве случаев все же, вероятно, рекомендуется проводить полную переиндексацию еженедельно.)
Но, учитывая текущие 5-дневные данные, вы можете согласиться с БЕЗ РЕИНДЕКСОВ вообще в этих скользящих таблицах (в зависимости от того, как именно настроен кластерный индекс). Вот что я имею в виду:
Если вы делаете только вставки (без обновлений), а кластеризованный индекс - это либо дата / время, либо просто постоянно увеличивающееся числовое значение, внутренняя структура таблицы может выглядеть примерно так:
[ Day 1 ][ Day 2 ][ Day 3 ][ Day 4 ][ Day 5 ][ Empty ]
В день 6 вы удаляете данные из дня 1 и вставляете данные из дня 6:
[ Empty ][ Day 2 ][ Day 3 ][ Day 4 ][ Day 5 ][ Day 6 ]
И тот же шаблон продолжается, повторно используя недавно освобожденное пространство:
[ Empty ][ Day 2 ][ Day 3 ][ Day 4 ][ Day 5 ][ Day 6 ]
[ Day 7 ][ Empty ][ Day 3 ][ Day 4 ][ Day 5 ][ Day 6 ]
[ Day 7 ][ Day 8 ][ Empty ][ Day 4 ][ Day 5 ][ Day 6 ]
[ Day 7 ][ Day 8 ][ Day 9 ][ Empty ][ Day 5 ][ Day 6 ]
Чтобы точно знать, что происходит, я бы использовал запросы фрагментации таблиц SQL (dm_db_index_physical_stats) после окончательного переиндексации, а затем отключил переиндексацию на несколько дней. Если числа фрагментации очень низкие, то, вероятно, это и происходит. Если они высокие, то это, вероятно, неточная картина, и вам может потребоваться восстановить свои переиндексы.