Безопасно ли включать автоматическое сжатие SQL Server?

Существует множество параметров SQL Server, которые можно включить для баз данных, и один из наиболее неправильно понятых - это автоматическое сжатие. Это безопасно? Если нет, то почему нет?

(Первоначально я задавал как обычный вопрос, но потом узнал правильный метод - спасибо BrentO)

Нет никогда.

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

Автоматическое сжатие - это очень распространенная настройка базы данных, которую нужно включить. Это кажется хорошей идеей - удалить лишнее пространство из базы данных. Существует множество «невольных администраторов баз данных» (например, TFS, SharePoint, BizTalk или просто обычный старый SQL Server), которые могут не знать, что автоматическое сжатие - это зло.

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

Почему автоусадка так плохо?

Скорее всего, база данных снова будет расти, так зачем ее сокращать?

1. Shrink-grow-shrink-grow вызывает фрагментацию на уровне файловой системы и требует много ресурсов.
2. Вы не можете контролировать, когда он вступает в игру (даже если это регулярно)
3. Он использует много ресурсов. Перемещение страниц в базе данных занимает центральный процессор, много ввода-вывода и генерирует большое количество журнала транзакций.
4. Вот реальный момент: сжатие файла данных (независимо от того, авто) или нет) приводит к массовой фрагментации индекса, что приводит к снижению производительности.

Недавно я написал в блоге пример SQL-скрипта, который показывает проблемы, которые он вызывает, и объясняет чуть более подробно. Смотри Автоусадка - выключи! (нет рекламы или подобного барахла в моем блоге). Не путайте это с уменьшением файла журнала, который иногда полезен и необходим.

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

Изменить: я должен добавить это, напомнив второй ответ - существует распространенное заблуждение, что прерывание операции сжатия может привести к повреждению. Нет, не будет. Раньше я владел усадочным кодом в SQL Server - он откатывает текущее перемещение страницы, которое он делает в случае прерывания.

Надеюсь это поможет!

Конечно, Пол прав.

Посмотреть все БД и их настройки автоусадки. Если у вас много баз данных, одна из них проникнет.

sp_msforeachdb  @command1 = 'Select ''[?]'',DATABASEPROPERTYEX(''?'',''IsAutoShrink'')'

Это где-то в DMV .... Интересно.

Это не «небезопасно» - это ничего не повредит.

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

IIRC опция отключена по умолчанию для всех баз данных во всех выпусках MSSQL, кроме Express.

В TechNet имеется технический документ, который более подробно объясняет обслуживание SQL.

http://technet.microsoft.com/en-us/library/cc262731.aspx

Я видел SQL-сервер с включенными Autogrow и Autoshrink. Этот (относительно мощный) сервер был ужасно медленным, потому что все, что он делал весь день, было сжатие и увеличение файлов базы данных. Автоусадка может быть полезной, но я бы порекомендовал две вещи:

1. Выключите автоусадку по умолчанию.
2. Документируйте настройки вашего сервера, чтобы вы знали, где включены Autogrow и Autoshrink, а где нет.

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

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

Также ознакомьтесь с этим видео-учебником ....

Посмотрите, как Пол Рэндал демонстрирует, как сжатие и автоматическое сжатие могут вызвать серьезные проблемы фрагментации для вашей базы данных http://wtv.watchtechvideos.com/topic194.html