Как исправить ошибку «Журнал транзакций для БД заполнен» при свертке базы 1С?

← На главную

При выполнении типовой или нетиповой свертки информационных баз 1С (например, УПП 1.3), работающих под управлением СУБД Microsoft SQL Server, администраторы и разработчики часто сталкиваются с критической ошибкой: «Журнал транзакций для БД заполнен» (The transaction log for database is full). Попытки выполнить стандартное сжатие файла лога (Shrink) через SQL Server Management Studio нередко заканчиваются неудачей, и операция свертки аварийно прерывается.

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

Выясним причины переполнения журнала транзакций

Проанализируем механику работы СУБД. В процессе свертки базы данных 1С удаляется колоссальное количество строк из регистров и документов, а также формируются новые корректирующие документы с остатками. Любая операция удаления или изменения обязательно фиксируется в журнале транзакций (файле с расширением .ldf). Переполнение возникает по нескольким основным причинам:

Модель восстановления Full (Полная): В режиме Full СУБД сохраняет все транзакции до тех пор, пока не будет создана резервная копия самого журнала транзакций (Log Backup). Если резервное копирование лога не настроено с достаточной частотой, файл .ldf непрерывно растет и заполняет всё свободное место на диске.
Длительная единая транзакция платформы: Даже если база переведена в простую модель восстановления, журнал транзакций не может быть усечен (truncated) до тех пор, пока выполняется открытая транзакция. Если обработка свертки удаляет большой массив данных внутри одной непрерывной транзакции без промежуточных фиксаций, СУБД обязана хранить всю цепочку изменений для возможности отката.
Ограничение максимального размера (MAXSIZE) или автороста (Autogrowth): Для файла журнала может быть задан жесткий лимит размера либо неоптимальный шаг прироста (например, слишком мелкий шаг в мегабайтах или процентное соотношение), приводящий к тайм-аутам при попытке расширить файл.
Регистрация изменений для планов обмена: Если конфигурация включена в распределенную информационную базу (РИБ) или используются планы обмена, удаление каждого объекта параллельно порождает записи в служебных таблицах регистрации изменений (_ChangeRec), что удваивает объем записываемых в лог данных.

Диагностика состояния журнала через SQL Server

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


SELECT name, recovery_model_desc, log_reuse_wait_desc 
FROM sys.databases 
WHERE name = 'Имя_Вашей_Базы_1С';

Проанализируем столбец log_reuse_wait_desc в возвращенном результате:

LOG_BACKUP: СУБД ожидает снятия резервной копии журнала. Это характерно для модели Full. Пока бэкап лога не сделан, очистка и сжатие файла невозможны.
ACTIVE_TRANSACTION: Место удерживается незафиксированной пользовательской транзакцией (например, выполняющимся шагом свертки 1С).
REPLICATION или CHANGE_TRACKING: Очистка удерживается службами репликации или механизмами отслеживания изменений.

Основное решение: Перевод в режим Simple и регламент свертки

Разберем по шагам наиболее эффективный алгоритм устранения ошибки при проведении объемной свертки:

Создание полной резервной копии: Перед любыми манипуляциями с базой и моделью восстановления обязательно создаем полный бэкап (Full Backup) средствами SQL Server или через конфигуратор 1С.
Переключение в Simple Recovery Model: В свойствах базы данных переходим на вкладку Options и меняем параметр Recovery model с Full на Simple. В простой модели восстановления завершенные транзакции автоматически усекаются, а место внутри файла .ldf повторно используется для следующих операций.
Сжатие файла журнала: После перевода в режим Simple выполняем сжатие файла журнала: переходим в меню Tasks -> Shrink -> Files, выбираем тип файла Log и освобождаем неиспользуемое пространство.
Настройка автороста: В свойствах базы данных проверяем параметры Autogrowth для лога транзакций. Рекомендуется задать фиксированный шаг расширения (например, 512 МБ или 1024 МБ) и установить максимальный размер в значение Unlimited (при наличии достаточного запаса на диске).
Выполнение свертки: Запускаем обработку свертки в базе 1С.
Возврат к рабочей модели и повторный бэкап: После завершения свертки возвращаем базу в режим Full (если для производственной базы требуется восстановление на определенный момент времени). Критически важно: смена модели разрывает цепочку журналов, поэтому сразу после возврата в Full необходимо повторно создать полный бэкап базы данных, иначе создание инкрементных резервных копий журнала будет невозможным.

Оптимизация процесса свертки на уровне 1С

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

Порционная обработка: Если свертка пишется вручную или модифицируется типовая обработка, удаление документов и движений по регистрам необходимо разбивать на порции (например, пачками по 1000–5000 записей). Каждая порция должна фиксироваться явным вызовом ЗафиксироватьТранзакцию(). В модели Simple это гарантирует циклическое переиспользование журнального файла без его разрастания.
Очистка регистрации изменений: Перед началом свертки рекомендуется временно исключить удаляемые объекты из планов обмена или очистить таблицы регистрации изменений, чтобы не перегружать транзакционный лог лишними метаданными.
Монопольный режим: Свертку следует проводить при полном отключении пользователей и блокировке регламентных заданий (через консоль администрирования кластера 1С), чтобы исключить параллельные блокировки и рост конкурирующих транзакций.

Регламентное обслуживание после свертки

Массовое удаление миллионов записей приводит к колоссальной фрагментации индексов и искажению статистик. После завершения всех этапов свертки и успешного сжатия журнала обязательно выполним процедуры обслуживания:

Реорганизацию или перестроение индексов (Rebuild Index) таблиц базы данных.
Полное обновление статистик (Update Statistics) для оптимизатора запросов СУБД.
При необходимости — однократное сжатие файла данных (.mdf) для возврата неиспользуемого пространства операционной системе с последующим обязательным дефрагментированием индексов.