Лучший способ дефрагментировать / сжать базу данных для архивных целей

У нас есть экземпляр SQL Server, который используется для архивирования электронной почты (любезно предоставлен сторонним пакетом архивирования). Время от времени программное обеспечение переносится на новую пустую базу данных. Мы делали это ежеквартально в прошлом, но сейчас мы планируем делать это ежемесячно. Объем архивируемых данных составляет около 15–20 ГБ в месяц, а большая часть данных находится в нескольких таблицах (обычно 2–4).

Когда мы переходим к новой базе данных, старая используется только для чтения. То, что я хотел бы сделать, - это оптимизировать его в красивый, плотный файл данных со всеми смежными таблицами / индексами, имеющими очень высокий коэффициент заполнения и не так много пустого пространства в конце файла данных. Кроме того, мы используем Standard Edition на этом сервере со всеми вытекающими отсюда ограничениями (в противном случае я бы уже использовал сжатие данных).

Несколько вариантов, которые я могу придумать:

1. REBUILD / REORGANIZE индексы, DBCC SHRINKFILE (Хорошо, это не разумный вариант, так как DBCC SHRINKFILE фрагментирует недостаток во всем, к чему он прикасается, но я включил его для полноты).
2. Создайте новую базу данных с отключенной автоматической статистикой. Сценарий и воссоздать все таблицы из исходной базы данных. Используйте bcp для экспорта / импорта данных в новую базу данных в порядке ключей кластера. Сценарий и воссоздать все индексы. Пересчитать всю статистику с полной проверкой.
3. Создайте новую базу данных с отключенной автоматической статистикой. Сценарий и воссоздать все таблицы из исходной базы данных. Используйте SSIS или T-SQL для передачи данных в новую базу данных. Сценарий и воссоздать все индексы. Пересчитать всю статистику с полной проверкой.

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

Какие еще хорошие / лучшие варианты есть для этого? Моя задача - переместить данные таким образом, чтобы сохранить высокий коэффициент заполнения и логически непрерывным образом.

Редактировать:

Следует отметить, что около 75% данных, похоже, хранятся в столбцах изображений (LOB).

Чтобы устранить физическую фрагментацию в файлах, вы можете переместить кластеризованный индекс с удалением в новую файловую группу. Поскольку они будут RO, сделайте их заполняющим фактором на 100%, так как для вставок не требуется места, разрывы страниц вызваны обновлениями.

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

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

Кстати, просто убедитесь, что вы используете самые последние типы данных для своих LOBS. то есть nvarchar (max) или varchar (max) вместо ntext или text, varbinary (max) вместо изображения?

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