MSSQL Error 9002: The transaction log is full — Причины и очистка LDF
Ошибка 9002 возникает, когда файл журнала транзакций (LDF) исчерпал выделенный дисковый лимит (MAXSIZE), на диске закончилось свободное пространство или журнал не может быть усечен из-за активных блокирующих факторов.
- Сообщение:
The transaction log for database '%.*ls' is full due to '%ls'(Severity 17, State 1 to 9). - База данных 1С:Предприятие переходит в режим
Read-Onlyдля операций модификации, проведение документов полностью блокируется. - Файл
.LDFразрастается до сотен гигабайт или занимает 100% дискового раздела. - Фоновые задания и репликация Always On / CDC аварийно завершаются.
1. Определение причины удержания журнала транзакций
SELECT
name,
recovery_model_desc,
log_reuse_wait,
log_reuse_wait_desc
FROM sys.databases
WHERE name = 'YourDatabaseName';2. Анализ свободного места внутри LDF файла
USE [YourDatabaseName];
GO
DBCC SQLPERF(LOGSPACE);
GO
SELECT
name,
size * 8 / 1024 AS CurrentSizeMB,
max_size,
growth
FROM sys.database_files
WHERE type_desc = 'LOG';3. Решение в зависимости от log_reuse_wait_desc
Сценарий А: `LOG_BACKUP` (Модель FULL без регулярных бэкапов лога)
-- Выполните резервное копирование журнала транзакций
BACKUP LOG [YourDatabaseName]
TO DISK = 'D:\Backups\YourDB_Log.trn'
WITH COMPRESSION;
-- Физическое сжатие файла LDF до разумного размера (например, 10 ГБ)
USE [YourDatabaseName];
GO
DBCC SHRINKFILE (N'YourDatabaseName_log', 10240);Сценарий Б: `ACTIVE_TRANSACTION` (Длинная незафиксированная транзакция в 1С)
-- Поиск самой старой активной транзакции
DBCC OPENTRAN('YourDatabaseName');
-- Поиск блокирующего процесса
SELECT
st.session_id,
r.blocking_session_id,
r.status,
r.command,
t.text AS [SQL_Text]
FROM sys.dm_exec_requests r
JOIN sys.dm_exec_sessions st ON r.session_id = st.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t;Сценарий В: `REPLICATION` / `AVAILABILITY_GROUP`
Проверьте синхронизацию вторичных реплик Always On или удалите зависшие публикации репликации через sp_removedbreplication.
4. Корректировка параметров Autogrowth
ALTER DATABASE [YourDatabaseName]
MODIFY FILE ( NAME = N'YourDatabaseName_log', MAXSIZE = UNLIMITED, FILEGROWTH = 1024MB ); Частые вопросы (FAQ)
Почему переключение в SIMPLE и обратно в FULL временно решает проблему?
В модели SIMPLE чекпоинт автоматически усекает неактивную часть лога. Однако это разрывает цепочку LSN (Log Sequence Number) и делает невозможным point-in-time восстановление до создания нового Full Backup.
Почему shrink не уменьшает размер файла LDF?
Сжатие невозможно, если в конце файла находится активный виртуальный журнал (VLF). Выполните бэкап лога еще раз, инициируйте контрольную точку (CHECKPOINT) и повторите команду DBCC SHRINKFILE.
Как часто нужно делать бэкап лога транзакций для 1С в режиме FULL?
В production-средах оптимальный интервал составляет от 5 до 15 минут в зависимости от требований RPO (Recovery Point Objective).
Чем опасен чрезмерный рост количества VLF (Virtual Log Files)?
Тысячи мелких VLF (из-за шага авторасширения в 1MB или процентах) критически замедляют старт базы, восстановление из бэкапа и производительность операций записи.