Під час роботи з базами даних SQL Server, особливо на етапі розробки та тестування, файли бази даних MDF (файл даних) і LDF (файл журналу транзакцій) можуть дуже швидко збільшуватися в розмірі. Це відбувається через часті зміни структури БД, масові вставки та видалення даних, а також через особливості роботи журналу транзакцій.

Для зменшення розміру цих файлів у SQL Server використовується команда DBCC SHRINKFILE.

Що робить DBCC SHRINKFILE

Команда DBCC SHRINKFILE дозволяє:

• зменшити розмір окремого файлу даних або файлу журналу транзакцій;

• звільнити невикористовуваний простір у файлі;

• у випадку файлів даних — перемістити сторінки даних в інші файли тієї ж файлової групи, що дозволяє в подальшому видалити файл з бази даних.

Файл можна стиснути до розміру, який буде меншим за початковий розмір, заданий під час створення. У такому випадку буде встановлено нове мінімальне значення розміру файлу.

Обов’язкові аргументи команди

Команда DBCC SHRINKFILE приймає такі основні аргументи:

• file_name — логічне ім’я файлу, який необхідно стиснути;

• target_size — бажаний розмір файлу в мегабайтах (ціле число).

Якщо параметр target_size не вказаний, SQL Server намагатиметься зменшити файл до його мінімального розміру, який був заданий під час створення файлу.

Приклад використання

DBCC SHRINKFILE (dbMyDataBase_log, 1);

У цьому прикладі файл журналу транзакцій буде зменшено до 1 МБ (наскільки це можливо).

Як дізнатися логічне ім’я файлу

Логічне ім’я файлу не завжди співпадає з фізичною назвою файлу в файловій системі. Щоб дізнатися логічні імена файлів бази даних, виконайте запит:

SELECT * FROM sysfiles;

⚠️ Важливо: перед виконанням цього запиту необхідно, щоб була активна потрібна база даних, наприклад dbMyDataBase.

Важливі зауваження та рекомендації

1. Не використовуйте SHRINK регулярно на продуктивних БД

Часте використання DBCC SHRINKFILE:

• призводить до фрагментації індексів;

• може негативно впливати на продуктивність;

• часто є лише тимчасовим рішенням, оскільки файли знову починають зростати.

👉 На бойових (production) серверах shrink варто виконувати лише у виняткових випадках.

2. Особливості роботи з LDF (журналом транзакцій)

Розмір LDF-файлу напряму залежить від моделі відновлення (Recovery Model):

• FULL — журнал не очищається без резервного копіювання;

• SIMPLE — журнал очищається автоматично;

• BULK_LOGGED — проміжний варіант.

Якщо база даних у режимі FULL, перед shrink обов’язково потрібно зробити резервну копію журналу транзакцій:

BACKUP LOG dbMyDataBase TO DISK = 'C:\Backup\dbMyDataBase_log.bak';

Без цього shrink може не дати очікуваного результату.

3. Краще правильне планування, ніж shrink

Найкраща практика — це:

• коректно планувати початкові розміри MDF та LDF;

• налаштовувати адекватний autogrowth;

• регулярно виконувати резервне копіювання.

Shrink — це інструмент для виправлення ситуації, а не для щоденного використання.