Ошибка СУБД в 1С: The transaction log for database is full due to LOG_BACKUP

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

Проблема

В тех нологическом журнале и окне ошибки была строка:

The transaction log for database 'Base_Name' is full due to 'LOG_BACKUP'

Это ошибка SQL Server 9002. Пока журнал заполнен, база может открываться, но операции записи и проведения завершаются ошибкой.

Причина

База работала в модели восстановления FULL, однако резервные копии журнала транзакций давно не выполнялись. SQL Server не мог повторно использовать занятую часть файла журнала. Когда файл дошёл до установленного максимального размера, новые транзакции 1С перестали записываться.

Как я проверил причину

В SQL Server Management Studio выполнил запрос, подставив имя своей базы:

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

В моём случае столбец log_reuse_wait_desc показывал LOG_BACKUP. Дополнительно я проверил свободное место на диске, свойства файла журнала, автоприрост и ограничение MaxSize.

Решение

Сначала сделал резервную копию журнала в каталог, который уже был включён в резервное копирование SQL Server:

BACKUP LOG [Base_Name]
TO DISK = N'D:\SQLBackup\Base_Name_log.trn'
WITH COMPRESSION, CHECKSUM;

Если журнал этой базы раньше ни разу не копировался, Microsoft рекомендует выполнить две последовательные резервные копии журнала, чтобы усечение стало возможным до точки последней копии. После этого я снова проверил log_reuse_wait_desc, свободное место внутри файла и проведение документа в 1С.

Затем настроил регулярное резервное копирование журнала. Для базы в модели FULL одних ночных полных копий недостаточно: без копий журнала та же ошибка появится снова.

Что я не стал делать

Я не удалял файл .ldf, не отсоединял базу и не запускал уменьшение журнала вслепую. Shrink уменьшает физический файл, но сам по себе не устраняет причину LOG_BACKUP. Переключать рабочую базу в модель SIMPLE только ради освобождения места тоже нельзя без согласования сх емы восстановления.

Результат

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

Если у вас в ошибке указано не LOG_BACKUP, а ACTIVE_TRANSACTION, AVAILABILITY_REPLICA или другая причина, действия будут другими. Напишите точный текст в комментариях — разберём отдельно.