database_name | database_id | 0
Ім'я або ідентифікатор бази даних, яка повинна бути стиснута. Якщо вказано 0, використовується поточна база даних.
Відсоток вільного простору, яке повинно залишитися в базі даних після стиснення.
Стискає дані в файлах за допомогою переміщення розподілених сторінок з кінця файлу на місце нерозподілених сторінок на початку файлу. Аргумент target_percent є необов'язковим.
Вільне місце в кінці файлу операційної системі не повертається, і фізичний розмір файлу не змінюється. Отже, якщо зазначений аргумент NOTRUNCATE, стиснення файлів даних незначно.
Аргумент NOTRUNCATE застосуємо тільки до файлів даних. На файли журналу він не впливає.
Виділяє весь вільний простір в кінці файлу операційній системі, але не переміщує сторінок всередині файлу. Файл даних буде стиснутий тільки до останнього розподіленого екстента. Аргумент target_percent пропускається, якщо він зазначений з аргументом TRUNCATEONLY.
Аргумент TRUNCATEONLY застосуємо тільки до файлів даних. На файли журналу він не впливає.
Пригнічує всі інформаційні повідомлення з ступенями серйозності від 0 до 10.
Щоб стиснути всі файли даних і журналів зазначеної бази даних, виконайте команду DBCC SHRINKDATABASE. Щоб стиснути один файл даних або файл журналу в зазначеній базі даних, виконайте команду DBCC SHRINKFILE.
Операції DBCC SHRINKDATABASE можуть бути зупинені на будь-якому етапі процесу, при цьому вся виконана робота зберігається.
Розмір цієї бази даних не може бути менше мінімального розміру бази даних. Мінімальний розмір - це розмір, зазначений при створенні бази даних, або останній розмір, явно встановлений операцією зміни розміру файлу, такий як DBCC SHRINKFILE або ALTER DATABASE. Наприклад, якщо база даних була створена з розміром 10 МБ, а потім збільшилася до 100 МБ, її можна стиснути тільки до 10 МБ, навіть якщо видалити з неї всі дані.
Рятувальна операція DBCC SHRINKDATABASE без вказівки параметра NOTRUNCATE або TRUNCATEONLY рівносильно виконання операції DBCC SHRINKDATABASE з параметром NOTRUNCATE після виконання операції DBCC SHRINKDATABASE з параметром TRUNCATEONLY.
Стислива база даних не повинна перебувати в режимі одного. Інші користувачі можуть працювати з базою даних при її стисненні. Це стосується системних баз даних.
Неможливо стиснути базу даних під час створення її резервної копії. І навпаки, не можна створити резервну копію бази даних під час операції стиснення.
Робота команди DBCC SHRINKDATABASE
Інструкція DBCC SHRINKDATABASE стискає файли даних по одному, а файли журналу так, як ніби всі вони представляють один безперервний пул журналу. Стиснення файлів завжди ведеться з кінця.
Припустимо, що існує база даних з ім'ям mydb. має один файл даних і два файли журналу. Кожен файл даних і журналу має розмір 10 МБ, а файл даних містить 6 МБ даних.
Припустимо, що файл даних бази даних mydb містить 7 МБ даних. При вказівці аргументу target_percent зі значенням 30 допускається стиснення даного файлу для звільнення 30 відсотків простору. Однак при вказівці аргументу target_percent зі значенням 40 файл даних стиснутий не буде, тому що компонент Database Engine не може стиснути файл до меншого розміру, ніж поточний розмір займаних даних. Дану ситуацію можна уявити і іншим способом: 40 відсотків бажаного вільного простору + 70 відсотків від повного файлу даних (7 МБ з 10 МБ) більше, ніж 100 відсотків. Так як сума бажаного вивільняється відсотка і поточного відсотка, займаного файлом даних, перевищує 100 (на 10 відсотків), будь-яке значення target_percent. яке більше 30, не призведе до стиснення файлу даних.
Для файлу журналу компонент Database Engine використовує аргумент target_percent для обчислення цільового розміру всього журналу. Тому аргумент target_percent є кількістю вільного простору в журналі після операції стиснення. Цільовий розмір всього журналу потім перераховується в цільової розмір кожного файлу журналу.
Інструкція DBCC SHRINKDATABASE намагається негайно стиснути кожен фізичний файл журналу до його цільового розміру. Якщо жодна частина логічного журналу не розміщується в віртуальних файлах журналу, розмір яких перевищує цільовий розмір файлу журналу, то файл буде успішно усічений і інструкція DBCC SHRINKDATABASE завершиться без будь-яких повідомлень. Однак якщо частина логічного журналу зберігається в віртуальних журналах за межами заданого розміру, то компонент Database Engine звільняє якомога більше місця, а потім формує інформаційне повідомлення. Повідомлення описує дії, які необхідно зробити, щоб перемістити логічний журнал з віртуальних журналів в кінець файлу. Після виконання всіх дій інструкція DBCC SHRINKDATABASE може бути використана для звільнення простору, що залишилося. Додаткові відомості див. У розділі Стиснення журналу транзакцій.
Так як файл журналу може бути стиснутий тільки до кордону віртуального файлу журналу, стиснення файлу журналу до розміру меншого, ніж розмір віртуального файлу журналу, неможливо, навіть якщо він не використовується. Розмір віртуального файлу журналу динамічно вибирається компонентом Database Engine при створенні або розширенні файлів журналу. Додаткові відомості про файли віртуального журналу см. В розділі Фізична архітектура журналу транзакцій.
Найбільш оптимальні методи
Зверніть увагу на такі відомості при плануванні стиснення бази даних.
- найбільший ефект від операції стиснення досягається при її застосуванні після операції, що створює багато невикористаного простору, наприклад після усічення або видалення таблиці;
- більшості баз даних потрібен якийсь вільний простір для виконання звичайних щоденних операцій. Якщо стиснення бази даних проводиться регулярно, але вона знову збільшується в розмірах, це означає, що звільнене при стисненні місце потрібно для регулярних операцій. В цьому випадку регулярне стиснення бази даних не принесе результату;
- операція стиснення не зберігається стан фрагментації індексів в базі даних і, як правило, призводить до більшої фрагментації. Це ще одна причина, чому не варто робити стиснення бази даних регулярно;
- не слід встановлювати параметр бази даних AUTO_SHRINK в значення ON без достатніх на те підстав.
Усунення несправностей
Операції стиснення можуть бути блоковані транзакцією, запущеної з рівнем ізоляції, заснованому на управлінні версіями рядків. Наприклад, якщо в процесі тривалої операції видалення, запущеної з рівнем ізоляції, заснованому на управлінні версіями рядків, запущена операція DBCC SHRINK DATABASE, операція стиснення буде чекати завершення роботи операції видалення. У цьому випадку операції DBCC SHRINKFILE і DBCC SHRINKDATABASE виводять інформаційне повідомлення (5202 для SHRINKDATABASE і 5203 для SHRINKFILE) в журналі помилок SQL Server кожні 5 хвилин протягом першої години, а потім по одному повідомленню щогодини. Наприклад, журнал помилок містить наступне повідомлення про помилку:
Це означає, що операція стиснення блокується транзакціями моментального знімка, які мають тимчасові мітки старше, ніж мітка 109, що представляє останню транзакцію, завершальну операцію стиснення. Це також показує, що стовпці transaction_sequence_num або first_snapshot_sequence_num в динамічному адміністративному поданні sys.dm_tran_active_snapshot_database_transactions містять число 15. Якщо стовпці transaction_sequence_num або first_snapshot_sequence_num в поданні містять число, менше, ніж остання транзакція, виконана операцією стиснення (109), то операція стиснення буде чекати завершення цих транзакцій.
Вирішити цю проблему можна, виконавши такі дії:
- Перервіть виконання транзакції, яка блокує операцію стиснення.
- Перервіть операцію стиснення. Вся завершена робота буде збережена.
- Поки операція стиснення очікує завершення блокуючих транзакцій, нічого робити не потрібно.