Стиснення файлів завжди ведеться з кінця. Наприклад, якщо є файл розміром 5 ГБ і при цьому в якості значення аргументу target_size інструкції DBCC SHRINKFILE задано 4 ГБ, компонент Database Engine звільнить максимальний обсяг дискового простору з останнього гігабайти файлу. Якщо в звільняється частини файлу є зайняті сторінки, компонент Database Engine спочатку перемістить їх в зберігається частина. Стиснути базу даних можна тільки до тієї міри, поки в ній не залишиться вільного місця. Наприклад, якщо база даних розміром 5 ГБ містить 4 ГБ даних, а в якості значення аргументу target_size інструкції DBCC SHRINKFILE задано 3 ГБ, буде звільнений тільки 1 ГБ.
Якщо параметр бази даних AUTO_SHRINK встановлений в значення ON, компонент Database Engine автоматично стискає бази даних, в яких є вільне місце. Цей параметр налаштовується за допомогою інструкції ALTER DATABASE. За замовчуванням цей параметр має значення OFF. Компонент Database Engine періодично перевіряє використання дискового простору в кожній базі даних. Якщо параметру AUTO_SHRINK в базі даних присвоєно значення ON, компонент Database Engine зменшує розмір файлів цієї бази даних. Ця операція виконується в фоновому режимі і не впливає на дії користувача в базі даних.
Завдання режиму автоматичного стиснення бази даних
Базу даних або її файли можна стискати вручну за допомогою інструкції DBCC SHRINKDATABASE або DBCC SHRINKFILE. Якщо інструкція DBCC SHRINKDATABASE або DBCC SHRINKFILE не може зарезервувати все заданий дисковий простір у файлі журналу, має бути видано інформаційне повідомлення із зазначенням того дії, яке слід виконати для забезпечення можливості звільнення дискового простору. Додаткові відомості про стиснення файлів журналу см. В розділі Стиснення журналу транзакцій.
Операції DBCC SHRINKDATABASE і DBCC SHRINKFILE можуть бути зупинені на будь-якому етапі процесу, при цьому вся виконана робота зберігається.
За допомогою інструкції DBCC SHRINKDATABASE не можна стискати всю базу даних до розміру, який менше вихідного. Тому, якщо база даних була створена з розміром 10 МБ і потім збільшилася до 100 МБ, її можна стиснути тільки до 10 МБ, навіть якщо всі дані видалені з бази даних.
Однак за допомогою інструкції DBCC SHRINKFILE можна стискати окремі файли бази даних до розміру, який менше початкового. При цьому кожен файл слід стискати окремо.
Не можна стискати базу даних або журнал транзакцій при їх резервування. З іншого боку, не можна створити резервну копію бази даних або журналу транзакцій при їх стисненні.
Стиснення бази даних
Стиснення файлу даних або файлу журналу
Передбачені фіксовані крайні значення, до яких можна стискати файл журналу транзакцій. Розмір віртуальних файлів журналу в журналі визначає межі стиснення. Тому файл журналу не можна стиснути до розміру, меншого, ніж розмір віртуального файлу журналу. Крім того, зменшувати обсяг файлу журналу можна тільки з кроком, рівним розміру віртуального файлу журналу. Наприклад, файл журналу транзакцій розміром 1 ГБ може складатися з п'яти віртуальних файлів журналу по 200 МБ кожен. При стисненні файлу журналу транзакцій невикористовувані віртуальні файли журналу видаляються, проте має залишитися як мінімум два таких файлу. Оскільки кожен віртуальний файл журналу в даному прикладі займає 200 МБ, журнал транзакцій можна стиснути не менше ніж до 400 МБ з кроком в 200 МБ. Щоб мати можливість сильніше стиснути файл журналу транзакцій, слід створити невеличкий журнал і задати автоматичний режим збільшення його розміру замість того, щоб відразу створювати об'ємний файл журналу транзакцій.
рекомендації
При плануванні стиснення бази даних або файлу слід враховувати наступні міркування.
- Найбільший ефект від операції стиснення досягається в тому випадку, якщо вона виконується після операції, що створює багато невикористаного місця (усічення або видалення таблиці).
- Більшості баз даних для виконання звичайних щоденних операцій потрібно певний обсяг вільного місця. Якщо стиснення бази даних проводиться регулярно, але вона знову збільшується в розмірах, це означає, що звільнене при стисненні місце потрібно для регулярних операцій. У таких випадках повторне стиснення бази даних безглуздо.
- Операція стиснення бази даних не позбавляє від фрагментації індексів, а навіть навпаки, зазвичай ще більш збільшує її. Наприклад, не слід стискати базу даних або файл після перебудови індексів. Це ще одна причина відмовитися від повторного стиснення бази даних.
- Не слід встановлювати параметр бази даних AUTO_SHRINK в значення ON без достатніх на те підстав.
Можливо блокування операцій стиснення транзакцією, яка виконується з рівнем ізоляції на основі управління версіями рядків. Наприклад, якщо при виконанні масштабної операції видалення з рівнем ізоляції на основі версій рядків виконати інструкцію DBCC SHRINK DATABASE, то, перш ніж приступити до стискання файлів, вона буде чекати завершення операції видалення. У цьому випадку операції DBCC SHRINKFILE і DBCC SHRINKDATABASE виводять в журнал помилок SQL Server інформаційне повідомлення (5202 для SHRINKDATABASE і 5203 для SHRINKFILE), роблячи це кожні 5 хвилин протягом першої години, а потім по одному повідомленню щогодини. Додаткові відомості див. У розділі DBCC SHRINKDATABASE (Transact-SQL).