Как уменьшить LDF-файл SQL Server: лог, backup и shrink

LDF-файл SQL Server — это журнал транзакций базы данных. Он нужен не «для мусора», а для восстановления, отката операций и надежности базы. Поэтому уменьшать LDF нужно аккуратно: сначала понять, почему он вырос, затем сделать правильный backup log или изменить модель восстановления, и только потом выполнять shrink

Если речь про базу 1С, ситуация особенно частая: база работает годами, полная модель восстановления включена, бэкапы журнала не настроены, LDF растет до десятков или сотен гигабайт. В таком случае проблема не в самом LDF, а в отсутствии нормальной схемы обслуживания

Содержание

Почему растет LDF
Правильный путь для модели FULL
Если точное восстановление не нужно
Как найти логическое имя LDF
Мини-практика
Частые ошибки
Что почитать дальше по SQL

Почему растет LDF

Основные причины:

база в модели восстановления FULL, но backup log не выполняется
идут большие загрузки, обновления или регламентные операции
долго открытая транзакция не дает очистить журнал
репликация, зеркалирование или Always On задерживают усечение лога
для базы 1С нет регулярного плана обслуживания

Проверить модель восстановления можно так:

SELECT
    name,
    recovery_model_desc,
    log_reuse_wait_desc
FROM sys.databases
WHERE name = 'Accounting_1C';

Поле log_reuse_wait_desc подсказывает, почему журнал не переиспользуется. Если там LOG_BACKUP, значит SQL Server ждет резервную копию журнала транзакций

Правильный путь для модели FULL

Если база должна быть в модели FULL, сначала делайте backup log:

BACKUP LOG Accounting_1C
TO DISK = 'D:\Backup\Accounting_1C_log.trn'
WITH INIT, COMPRESSION;

После этого можно посмотреть логические имена файлов:

USE Accounting_1C;
GO

SELECT name, type_desc, size
FROM sys.database_files;

И только затем выполнить shrink конкретного файла журнала:

DBCC SHRINKFILE (Accounting_1C_log, 2048);

Число 2048 означает целевой размер в мегабайтах. Не сжимайте лог до нуля и не делайте shrink каждый день по расписанию. Лог снова вырастет, а постоянное сжатие и рост будут только мешать работе

Если точное восстановление не нужно

Для тестовой или учебной базы иногда можно перейти на SIMPLE:

ALTER DATABASE Accounting_1C SET RECOVERY SIMPLE;
GO

DBCC SHRINKFILE (Accounting_1C_log, 1024);
GO

Но для рабочей базы 1С такой шаг нужно согласовывать с требованиями к восстановлению. SIMPLE-модель проще, но она не дает восстановиться на конкретный момент времени между полными бэкапами

Как найти логическое имя LDF

Имя файла в Windows и логическое имя внутри SQL Server могут отличаться. Именно логическое имя нужно передавать в DBCC SHRINKFILE

SELECT
    name AS logical_name,
    physical_name,
    type_desc,
    size * 8 / 1024 AS size_mb
FROM sys.master_files
WHERE database_id = DB_ID('Accounting_1C');

Пример результата:

В этом примере shrink нужно выполнять для Accounting_1C_log, а не для имени файла на диске

Мини-практика

На тестовой базе проверьте модель восстановления, найдите логическое имя журнала и выполните shrink до разумного размера. Не делайте эту практику на рабочей базе без бэкапа

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
WHERE name = 'DemoLog';

USE DemoLog;
GO

SELECT name, type_desc
FROM sys.database_files;

Цель практики — научиться читать состояние лога, а не просто копировать DBCC SHRINKFILE вслепую