Как почистить журнал транзакций 1С в SQL Server

Файл журнала транзакций (LDF) базы 1С на SQL Server иногда разрастается до десятков и сотен гигабайт, заполняет диск и останавливает работу пользователей. Причина почти всегда одна: база работает в полной модели восстановления (Full), а резервные копии журнала не делаются, поэтому SQL Server не может переиспользовать место внутри файла.

Почистить журнал транзакций можно двумя безопасными способами: штатным усечением через резервное копирование журнала с последующим сжатием файла либо переводом базы в простую модель восстановления с усечением. Оба варианта выполняются штатными средствами SQL Server и не требуют остановки сервера 1С надолго, но требуют понимания последствий для восстановления данных.

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

Почему журнал транзакций базы 1С разрастается

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

В модели восстановления Full или Bulk-Logged SQL Server хранит записи журнала до тех пор, пока не будет создана резервная копия журнала. Усекаться (переиспользовать место внутри файла) журнал не может, поэтому файл только растёт. Типовой сценарий: базу развернули из бэкапа, модель осталась Full, а задание бэкапа журнала никто не настроил.

Ускоряют рост массовые операции: свёртка базы, групповое перепроведение, загрузка данных через обмен, обновление конфигурации на большой базе. Одна такая операция способна увеличить журнал на десятки гигабайт за час.

Что проверить перед очисткой

Перед любыми действиями убедитесь, что у вас есть актуальная полная резервная копия базы. Усечение журнала в модели Full разрывает цепочку бэкапов журнала, и без свежей полной копии восстановление на произвольный момент времени станет невозможным.

Проверьте три вещи: модель восстановления базы, причину, по которой журнал не усекается, и реальную заполненность файла. Для этого достаточно трёх запросов в SQL Server Management Studio.

SELECT name, recovery_model_desc, log_reuse_wait_desc FROM sys.databases WHERE name = 'MyBase1C';
SELECT DB_NAME(database_id) AS db, total_log_size_mb, used_log_space_mb, used_log_space_in_percent FROM sys.dm_db_log_space_usage;

Если log_reuse_wait_desc показывает LOG_BACKUP — достаточно сделать бэкап журнала. Если ACTIVE_TRANSACTION или OLDEST_PAGE — есть долгая незавершённая транзакция или проблема с репликацией, и сначала нужно разобраться с ней, иначе усечение не сработает.

Способ 1: усечение через резервную копию журнала

Это правильный способ для баз в модели Full, где важна возможность восстановления на любой момент времени. Он состоит из трёх шагов: полный бэкап (если его давно не было), бэкап журнала, сжатие файла.

Резервная копия журнала освобождает место внутри LDF-файла, но не уменьшает сам файл на диске. Чтобы вернуть место операционной системе, после бэкапа выполняется сжатие через DBCC SHRINKFILE.

BACKUP DATABASE [MyBase1C] TO DISK = 'D:\Backup\MyBase1C_full.bak';
BACKUP LOG [MyBase1C] TO DISK = 'D:\Backup\MyBase1C_log.trn';
USE [MyBase1C];
DBCC SHRINKFILE (N'MyBase1C_log', 1024);

Имя логического файла журнала (в примере MyBase1C_log) посмотрите запросом SELECT name FROM sys.database_files WHERE type_desc = 'LOG'. Целевой размер (в примере 1024 МБ) задайте с запасом под пиковые операции — слишком маленький файл будет постоянно autorow'иться и фрагментироваться.

1. 1
   Убедитесь, что на диске с бэкапами достаточно места
2. 2
   Сделайте полную резервную копию базы (BACKUP DATABASE)
3. 3
   Сделайте резервную копию журнала (BACKUP LOG)
4. 4
   Проверьте долю свободного места в журнале через sys.dm_db_log_space_usage
5. 5
   Сожмите LDF-файл командой DBCC SHRINKFILE до разумного размера
6. 6
   Настройте регулярное задание бэкапа журнала, чтобы проблема не вернулась

Способ 2: перевод базы в простую модель восстановления

Если восстановление на произвольный момент времени для базы не требуется (например, достаточно ежедневных полных бэкапов), проще перевести базу в модель Simple. В ней журнал усекается автоматически после каждой контрольной точки, и его рост ограничен объёмом текущих активных транзакций.

Последовательность такая: перевести базу в Simple, выполнить CHECKPOINT, сжать файл. Все действия занимают несколько минут и не требуют выгона пользователей, хотя на время сжатия возможна нагрузка на дисковую подсистему.

ALTER DATABASE [MyBase1C] SET RECOVERY SIMPLE;
USE [MyBase1C];
CHECKPOINT;
DBCC SHRINKFILE (N'MyBase1C_log', 1024);

Многие организации сознательно держат файловые и клиент-серверные базы 1С в модели Simple: для типовых конфигураций с ежедневным бэкапом потеря данных максимум за сутки считается приемлемой, а обслуживание заметно упрощается. Решение должен принимать владелец данных, а не только администратор.

Как сжать файл и проверить результат

Сжатие выполняется командой DBCC SHRINKFILE с указанием логического имени файла и целевого размера в мегабайтах. Альтернатива — графический интерфейс: в SSMS правый клик по базе → Tasks → Shrink → Files → выбрать тип файла Log.

Учтите: сжать файл можно только до объёма фактически занятых данных плюс служебные структуры. Если журнал не был усечён (нет бэкапа журнала или есть активная транзакция), SHRINKFILE отработает без ошибки, но файл не уменьшится. Это самая частая причина «не работает shrink».

Профилактика: как не допустить повторного роста

Разовая очистка не решает проблему, если не устранить причину. Для модели Full настройте регулярное задание резервного копирования журнала — через план обслуживания (Maintenance Plan) в SSMS или скриптом в SQL Server Agent. Интервал зависит от интенсивности работы: обычно от 15 минут до нескольких часов.

Дополнительные меры: задайте разумный начальный размер LDF-файла и прирост в мегабайтах (а не в процентах), следите за свободным местом на диске мониторингом, а массовые операции (свёртку, перепроведение) планируйте на нерабочее время и при возможности выполняйте порциями.

Частые вопросы