it-swarm-ru.tech

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

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

44
Paul Randal

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

Нет никогда.

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

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

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

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

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

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

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

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

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

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

71
Paul Randal

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

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

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

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

4
Sam

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

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

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

2
David Spillett

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

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

1
Jeremy Thake

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

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

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

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

1
SuperCoolMoss

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

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

1
Sakthivel Chidambaram