Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

MSSQL_ERROR_9002 1С:Предприятие и СУБД

MSSQL Error 9002: The transaction log is full — Причины и очистка LDF

Обновлено: 25.08.2026 · Официальная документация ↗

Ошибка 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 );
💡 Практика специалистов: Никогда не оставляйте авторасширение лога в процентах (по умолчанию 10%). Установите фиксированный шаг прироста (512MB, 1024MB или 2048MB), чтобы избежать фрагментации VLF.

Частые вопросы (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 или процентах) критически замедляют старт базы, восстановление из бэкапа и производительность операций записи.

Полезные материалы
Рекомендуем