Файл .ldf виріс до сотень ГБ: як безпечно зменшити лог і стабілізувати базу

Зростання файлу транзакцій (.ldf) до десятків або сотень гігабайтів означає, що SQL Server не очищає журнал транзакцій. Це створює прямий ризик:

• повного заповнення диска,

• зупинки роботи програми,

• переходу бази даних у стани Recovery Pending або Suspect.

У практиці технічної підтримки зафіксовані випадки, коли .ldf зростав до 190+ ГБ.

Коли виникає проблема

Ситуація характерна для баз, які:

• працюють тривалий час без регламентного обслуговування,

• мають активні журнали дій і змін документів,

• використовують SQL Server Express без регулярного контролю дискового простору.

Причина

Файл .ldf зберігає записи транзакцій, доки SQL Server не може звільнити (truncate) журнал. Якщо:

• журнал не очищається,

• немає регулярних сервісних процедур,

• на диску бракує вільного місця,
  лог може рости без обмежень, навіть якщо сама база (.mdf) майже не змінюється.

Окремий випадок — модель відновлення Full: у цьому режимі журнал не звільняється автоматично, і для його очищення потрібне резервне копіювання журналу транзакцій. Модель Full дозволяє відновлення до конкретного моменту часу, тоді як Simple — лише відновлення з резервної копії. Перехід у Simple призводить до автоматичного звільнення журналу та зменшення обсягу .ldf (в ньому залишаються записи, потрібні для поточних операцій).

Рішення (безпечний алгоритм)

Крок 1. Внутрішнє очищення даних

Перед фізичним стисканням логу необхідно зменшити обсяг інформації, яку SQL Server вважає актуальною.

Рекомендується:

• очистити «Протокол дій користувачів» за старі періоди,

• очистити «Журнал змін документів», залишивши лише актуальні дані (наприклад, 2–3 місяці),

• виконати сервісну операцію
  «Видалення статистик закритих періодів» (код 006) — вона фізично видаляє старі документи та зменшує навантаження на журнал транзакцій.

Причинно-наслідковий зв’язок:
чим менше історичних даних → тим менше активних транзакцій → тим ефективніше стискається .ldf.

Крок 2. Стискання лог-файлу (Shrink)

Після внутрішнього очищення виконується фізичне зменшення файлу:

1. Підключіться до SQL Server через SQL Server Management Studio (SSMS).

2. Оберіть потрібну базу (зазвичай TorgSoftDB).

3. Правою кнопкою → Tasks → Shrink → Files.

4. Тип файлу: Log.

5. Запустіть процедуру стискання.

Результат:
SQL Server звільняє зайнятий простір на диску без пошкодження даних.

Особливості для SQL Server Express

У безкоштовній редакції:

• .mdf має жорстке обмеження:

• 10 ГБ — SQL Server 2008 R2 і новіше.

• 4 ГБ — SQL Server 2005.

• .ldf не має формального ліміту, але:

• при заповненні диска SQL Server не може працювати,

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

Якщо база вже в стані Suspect

Якщо база перейшла у Suspect або Recovery Pending:

• стандартний Shrink не спрацює,

• необхідно спочатку вивести базу з аварійного стану спеціальними SQL-командами,

• лише після цього можливе стискання логу.

У такому випадку самостійні дії без досвіду небажані.

Аварійне відновлення при втраті або пошкодженні .ldf (ризик втрати даних)

Застосовується лише тоді, коли:

• база не запускається,

• відсутній файл .ldf або він пошкоджений,

• відновлення стандартними методами неможливе,

• наявні актуальні резервні копії або прийнято рішення про можливу втрату частини даних.

Послідовність дій:

1. Зупинити службу SQL Server.

2. Видалити файл журналу транзакцій (.ldf).

3. Запустити SQL Server.

4. У SQL Server Management Studio виконати:

USE master

GO

sp_configure 'allow updates', 1

RECONFIGURE WITH OVERRIDE

GO

ALTER DATABASE <db_name> SET EMERGENCY, SINGLE_USER

DBCC CHECKDB ('<db_name>', REPAIR_ALLOW_DATA_LOSS)

ALTER DATABASE <db_name> SET ONLINE, MULTI_USER

USE master

GO

sp_configure 'allow updates', 0

GO

Примітки:

• Параметр REPAIR_ALLOW_DATA_LOSS допускає втрату частини даних.

• Метод не використовується для планового зменшення .ldf.

• Після відновлення необхідно перевірити цілісність бази та виконати повне резервне копіювання.

Профілактика (рекомендовано)

Щоб лог не зростав повторно:

• регулярно виконувати:
  «Відновити та реорганізувати індекси та оновити статистики»,

• контролювати вільне місце на системному диску,

• уникати роботи «впритул» до заповнення диска,

• увімкнути резервне копіювання:
  «Безпека даних: архів у хмарі» (код 057).

• зверніть увагу на автоматичне розширення (Autogrowth). У налаштуваннях бази в SSMS краще встановити обмеження на ріст файлу логу (наприклад, до 5–10 ГБ), щоб він фізично не зміг «з'їсти» весь дисковий простір і не призвів до краху операційної системи.

Підсумок

Зростання .ldf — це симптом, а не помилка.
Правильна послідовність:

1. очищення внутрішніх журналів,

2. видалення застарілих статистик,

3. фізичне стискання логу,

4. регулярна профілактика.

Такий підхід дозволяє стабілізувати систему без ризику втрати даних і повторення проблеми.