MS SQL: Журнал транзакций переполнен из-за LOG_BACKUP (Ошибка 9002)
Симптомы переполнения журнала (Error 9002)
Ошибка 9002: The transaction log for database is full due to 'LOG_BACKUP' возникает, когда файл журнала транзакций (LDF) достигает предела размера на диске (или лимита FileGrowth), а MS SQL Server не может усечь (очистить) виртуальные файлы журнала (VLF), так как ожидает их резервного копирования. Если база данных 1С находится в модели восстановления Полная (Full), любые изменения копятся в LDF до тех пор, пока администратор не сделает бэкап T-Log. Бизнес-риски: полная блокировка всех операций INSERT/UPDATE/DELETE в 1С, пользователи получают ошибку записи в базу.
Анализ причины удержания лога (log_reuse_wait_desc)
| Статус ожидания | О чем говорит СУБД | Путь решения |
|---|---|---|
LOG_BACKUP | Не настроено или сломалось регулярное создание бэкапов журнала транзакций. | Сделать BACKUP LOG или перевести в SIMPLE модель. |
ACTIVE_TRANSACTION | Зависла длинная транзакция (например, перепроведение документов за 3 года). | Найти и завершить (KILL) зависший SPID. |
REPLICATION / AVAILABILITY_REPLICA | Сбой репликации AlwaysOn или Transactional Replication. | Починить репликацию (возобновить синхронизацию узлов). |
Экстренная очистка и шринк журнала транзакций
Сценарий 1: Правильный (Выполнение бэкапа)
Если вам нужна возможность восстановления Point-in-Time, просто сделайте бэкап. Это срежет лог.
-- Проверка статуса (почему лог не усекается)
SELECT name, log_reuse_wait_desc FROM sys.databases WHERE name = 'Base_1C';
-- Выполнение резервного копирования лога (обрежет цепочку и освободит VLF)
BACKUP LOG [Base_1C] TO DISK = 'D:\Backups\Base1C_Log_Emergency.trn';
-- Физическое сжатие (Shrink) файла LDF до разумного размера (например, 5000 MB)
DBCC SHRINKFILE (N'Base_1C_log' , 5000);Сценарий 2: Радикальный (Смена Recovery Model на Simple)
Если логика Point-in-Time вам не нужна (допустима потеря данных с момента ночного Full бэкапа), разорвите цепочку LSN, переведя базу в простую модель.
-- 1. Перевод в Simple (SQL Server мгновенно пометит VLF как неактивные)
ALTER DATABASE [Base_1C] SET RECOVERY SIMPLE;
GO
-- 2. Сжатие лог-файла
DBCC SHRINKFILE (N'Base_1C_log' , 2048);
GO
-- 3. Возврат в Full (ОБЯЗАТЕЛЬНО сделайте Full бэкап после этого!)
ALTER DATABASE [Base_1C] SET RECOVERY FULL;
GO
BACKUP DATABASE [Base_1C] TO DISK = 'D:\Backups\Base1C_Full_NewChain.bak';Типовые ошибки администраторов
- Постоянный DBCC SHRINKFILE в регламентных заданиях: Сжимать лог по расписанию категорически запрещено. Рост лога заново вызывает фрагментацию (слишком много VLF) и тормозит запись (Zero-initialization LDF). Лог должен иметь статический размер, достаточный для суточной работы.
- Забытый бэкап после возврата в Full: Если вы перевели базу Simple -> Full, цепочка логов разорвана. Бэкапы транзакций не будут работать, пока вы не сделаете новый FULL бэкап.
Возможно, разработчики 1С написали код с гигантскими транзакциями, или не работает AlwaysOn. Эксперты ITSTM проведут аудит настроек FileGrowth, VLF и предложат оптимальный план обслуживания (RTO/RPO), при котором диски никогда не переполнятся.
Частые вопросы (FAQ)
Почему лог вырос до 500 ГБ, хотя база всего 50 ГБ?
В модели FULL каждое изменение (даже перестроение индексов, Index Rebuild) записывается в лог. Если вы не делаете BACKUP LOG каждый час, лог будет расти бесконечно, накапливая всю историю изменений.
Можно ли просто удалить файл LDF?
КАТЕГОРИЧЕСКИ НЕТ! LDF — это не текстовый лог, это критическая часть базы данных, содержащая активные транзакции. Его удаление приведет базу в состояние SUSPECT.
Шринк не работает, размер LDF не уменьшается. В чем дело?
Если активные (Active) VLF находятся в конце физического файла, SQL Server не может отрезать пустое место сзади. Сделайте еще один BACKUP LOG, или переведите в SIMPLE, затем снова повторите SHRINKFILE.
Какую модель восстановления выбрать для 1С?
Для Production (рабочих) баз — строго FULL с T-Log бэкапами каждые 15-60 минут. Для тестовых баз, копий и РИБ-узлов — SIMPLE (это сэкономит место и дисковый I/O).