Чи безпечно ввімкнути автоматичне скорочення SQL Server?

Існує багато варіантів SQL Server, які можна ввімкнути для баз даних, і один з найбільш неправильно зрозумілих - це автоматичне скорочення. Це безпечно? Якщо ні, то чому б і ні?

(Спочатку я задавався як звичайне запитання, але потім з'ясував правильний метод - дякую BrentO)

Ні ніколи.

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

Автоматичне зменшення - це дуже поширена установка бази даних, яку було включено. Це здається гарною ідеєю - видалити зайвий простір із бази даних. Там є безліч «мимовільних DBA» (думаю, 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. Документуйте конфігурації вашого сервера, щоб ви знали, де включено функцію Autogrow та Autoshrink, а де їх немає.

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

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

Також перегляньте цей відеоурок ...

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