Действительно ли безопасно включить автоуменьшение SQL Server?

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

Нет, никогда.

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

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

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

Почему автоуменьшение настолько плохо?

База данных, вероятно, просто вырастет снова, итак, почему уменьшение это?

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

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

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

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

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

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

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

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

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

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

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

1. Выключите Автоуменьшение по умолчанию.
2. Зарегистрируйте свои конфигурации сервера, таким образом, Вы знаете, где Авторастут, и Автоуменьшение включены и где они не.

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

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

Конечно, Paul прав.

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

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

Это в dmv's где-нибудь.... Интересно.

Также проверьте это видео учебное руководство....

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