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

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

Нет никогда.

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

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

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

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

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

1. Сжатие-рост-сжатие-увеличение вызывает фрагментацию на уровне файловой системы и требует много ресурсов.
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. Задокументируйте конфигурации своего сервера, чтобы вы знали, где включены функции автоматического увеличения и сжатия, а где нет.

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

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

Также посмотрите этот видеоурок ....

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