Журнал транзакций 1С разросся: почему и что делать

Иван Недомолков · Dərc edilib: 25 июля 2026 г. · Yenilənib: 3 сентября 2026 г.

Диск под базой 1С забился, а виноват не файл данных, а журнал транзакций - файл .ldf раздулся до сотен гигабайт. Классический сценарий: администратор делает шринк, место освобождается, а через неделю всё повторяется. Значит, лечили симптом, а не причину.

Ниже - что такое журнал транзакций, почему он растёт, как за минуту определить точную причину по log_reuse_wait_desc, и как лечить правильно. Отдельно - почему совет “просто переключите базу в SIMPLE” может стоить вам возможности восстановления, и когда он всё-таки уместен. Материал для ИТ-специалиста или администратора SQL Server.

Что такое журнал транзакций и почему он растёт

Журнал транзакций (.ldf) - не “лог для чтения человеком”, а служебный механизм СУБД. В него записывается каждое изменение данных до того, как оно попадёт в файл данных. Это гарантирует, что незавершённую транзакцию можно откатить, а после сбоя - восстановить согласованное состояние базы. Без журнала транзакций не работает ни одна операция записи.

Проблема не в том, что журнал существует, а в том, что место в нём не переиспользуется. Логически журнал - это кольцо из “виртуальных лог-файлов” (VLF). Когда участок журнала больше не нужен, SQL Server помечает его свободным и пишет по кругу поверх. Файл растёт только тогда, когда свободного места в кольце не осталось, а записать новое изменение надо. Значит, что-то мешает освобождать уже записанные участки.

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

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

Колонка log_reuse_wait_desc - это диагноз. Самые частые значения под 1С:

Значение	Что означает	Что делать
`LOG_BACKUP`	Модель FULL или BULK_LOGGED, журнал ждёт очередной резервной копии журнала. Если он при этом растёт, копии не делаются или идут слишком редко	Проверить расписание бэкапов лога: настроить их или сменить модель (см. ниже)
`ACTIVE_TRANSACTION`	Есть долгая или зависшая открытая транзакция	Найти и завершить транзакцию
`NOTHING`	Освобождению ничего не мешает	Рост объясняется штатной нагрузкой; проверить autogrowth
`CHECKPOINT`	С последнего усечения журнала ещё не было контрольной точки	Разовое; обычно саморазрешается
`AVAILABILITY_REPLICA`	Вторичная реплика группы доступности AlwaysOn ещё применяет записи журнала этой базы	Разбирать на стороне реплики

В подавляющем большинстве обращений “журнал 1С разросся” в этой колонке стоит LOG_BACKUP - и это ключ к пониманию. Если журнал уже упёрся в потолок и запись в базу встала, порядок действий по минутам собран на странице ошибки “Журнал транзакций переполнен”.

Причина №1: модель FULL без бэкапов журнала

По умолчанию многие базы 1С работают в модели восстановления FULL. В этой модели SQL Server обязан хранить все записи журнала до тех пор, пока они не попадут в резервную копию журнала транзакций. Логика простая: FULL обещает восстановление на точный момент времени, а это возможно только при непрерывной цепочке бэкапов лога.

Если модель FULL включена, а бэкапы журнала (именно журнала, не только полные бэкапы базы) не настроены - журнал не освобождается никогда. Он растёт линейно вместе со всей записью в базу, пока не забьёт диск. При этом полный бэкап базы раз в сутки не помогает: он не разрывает цепочку журнала.

Это и есть состояние log_reuse_wait_desc = LOG_BACKUP: “жду резервную копию журнала, чтобы освободить место”. Очень распространённая ситуация: базу перевели в FULL “чтобы было надёжнее”, а план бэкапов лога так и не создали - получили худшее из двух миров: и место течёт, и восстановления на момент времени нет, потому что цепочки бэкапов не существует.

Почему шринк помогает только на неделю

Шринк журнала (DBCC SHRINKFILE по .ldf) физически уменьшает файл, возвращая место операционной системе. Но он не устраняет причину. Если модель осталась FULL, а бэкапы лога не появились, журнал снова начнёт расти с той же скоростью и за те же несколько дней вернётся к прежнему размеру. Вы получаете цикл “раздулся → шринк → раздулся”, в котором шринк - это регулярная ручная работа вместо решения.

Хуже того, у постоянного шринка есть цена. Файл журнала растёт обратно порциями (autogrowth), и если приращение задано мелким, журнал набивается тысячами VLF - это замедляет и запись, и восстановление, и старт базы. Шринк уместен ровно один раз: как разовое действие после того, как настоящая причина устранена, чтобы вернуть диск в норму. Не как регламент.

Показательная цифра: в проекте свертки базы крупной сети ломбардов Казахстана журнал транзакций сократился со 119 до 8 ГБ - но это дал не шринк сам по себе, а приведение в порядок модели восстановления и расписания бэкапов. После этого журнал перестал распухать обратно.

Журнал транзакций постоянно переполняется: два разных сценария

“Переполняется раз за разом” звучит как одна беда, а это две, и лечатся они по-разному. Различить их можно до всякой диагностики, по одному признаку: с какой регулярностью приходит беда.

Переполняется предсказуемо, примерно с одним и тем же шагом - раз в неделю, раз в десять дней, всегда после одного и того же объёма работы. Это настройка, а не авария: модель FULL без бэкапов журнала. Журнал набирает ровно столько, сколько вы записали в базу, и упирается в потолок тем быстрее, чем активнее месяц. Шринк тут работает как будильник с отложенным звонком: вы двигаете дату следующего отказа, но не убираете его.

Переполняется внезапно и в разное время - вчера всё было в порядке, сегодня встало посреди дня. Это авария: кто-то держит длинную транзакцию, и журнал не может очиститься, пока она жива. Размер файла и свободное место на диске здесь ни при чём, добавите места - получите тот же отказ позже и на большем объёме.

Проверяется одним запросом, тем самым log_reuse_wait_desc из начала статьи: LOG_BACKUP это первый сценарий, ACTIVE_TRANSACTION - второй. Если у вас второй, и особенно если в тексте ошибки фигурирует tempdb с кодом 9002, дальше читать не здесь: поиск держателя транзакции по шагам разобран в статье про ошибку 9002 и переполнение tempdb.

Как лечить правильно

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

Вариант А. Оставить FULL и настроить бэкапы журнала

Подходит, если базе нужна возможность восстановиться на любой момент (потеря даже часа данных недопустима - например, активная касса или расчёты в реальном времени).

Что сделать:

Настроить регулярные резервные копии журнала транзакций - типично каждые 15-60 минут, в зависимости от допустимой потери данных.
Убедиться, что полный бэкап базы делается (он открывает цепочку) и бэкапы лога идут после него без разрывов.
Один раз выполнить шринк журнала до разумного размера.
Задать вменяемый autogrowth журнала (фиксированными мегабайтами/гигабайтами, а не процентами), чтобы не плодить VLF.

После этого место в журнале будет освобождаться после каждого бэкапа лога, и файл стабилизируется.

Вариант Б. Перейти на SIMPLE - но осознанно

В модели SIMPLE журнал освобождается автоматически на контрольных точках, бэкапы лога не нужны, и файл .ldf перестаёт бесконтрольно расти сам собой. Звучит как простое решение - и именно поэтому “просто поставьте SIMPLE” так часто советуют. Но у этого решения есть цена, о которой советчики умалчивают.

Что вы теряете, переключившись в SIMPLE:

Восстановление только на момент последнего полного (или разностного) бэкапа. Всё, что введено между бэкапами, при аварии теряется. Если полный бэкап ночью, а диск умер вечером - потерян весь рабочий день.
Несовместимость с некоторыми сценариями высокой доступности (log shipping, часть конфигураций AlwaysOn требуют FULL).
Переключение разрывает существующую цепочку бэкапов лога - после возврата в FULL цепочку придётся начинать заново с полного бэкапа.

SIMPLE - законный и часто правильный выбор для баз, где допустима потеря данных за период между полными бэкапами: тестовые базы, базы-архивы, отчётные копии, а иногда и рабочие базы, если бизнес сознательно согласен на суточное окно потерь и делает частые полные/разностные бэкапы. Но это решение принимается вместе с владельцем данных и после ответа на вопрос “сколько данных мы готовы потерять при аварии”, а не потому, что “так журнал перестанет расти”.

Никогда не переключайте боевую базу в SIMPLE молча, “чтобы освободить диск”. Сначала - согласование допустимой потери данных и проверка, что схема бэкапов ей соответствует.

Причина №2: зависшие и долгие транзакции

Если log_reuse_wait_desc показывает ACTIVE_TRANSACTION, дело не в модели восстановления, а в открытой транзакции, которая держит журнал. Пока транзакция не завершена (commit или rollback), SQL Server обязан хранить весь журнал с её начала - даже бэкапы лога не освободят это место.

Под 1С такое бывает, когда:

зависший или аварийно оборванный сеанс оставил “осиротевшую” транзакцию, которая часами держит блокировки и журнал;
тяжёлая операция (проведение гигантского документа, массовая обработка, платформенное удаление при свертке) выполняется одной длинной транзакцией;
регламентное задание упало в середине, не откатив транзакцию.

Найти виновника помогают DBCC OPENTRAN (покажет самую старую активную транзакцию) и представления sys.dm_tran_active_transactions, sys.dm_exec_sessions. Дальше - разобраться, живой это процесс или зависший, и завершить корректно. В наших проектах зависшие сеансы регулярно оставляли транзакции, часами удерживавшие десятки тысяч блокировок и мешавшие плановому обслуживанию, - поэтому в стандарт обслуживания входит авто-сторож зависаний, который их вылавливает.

Тот же эффект даёт массовый DELETE при переносе данных между базами: удаление регистра сведений на 106 миллионов строк раздуло журнал за 22 ГБ даже в SIMPLE и завесило сервер на росте файла - замер и лечение в статье про отставшую от прода тестовую базу.

Отдельный случай - распухание журнала при массовых операциях свертки терабайтных баз: там журнал раздувается закономерно, и лечится это не моделью восстановления, а архитектурой процедур (посекционные операции с контролем, table swap вместо построчного удаления). Это тема отдельного класса задач - см. “как уменьшить базу 1С”.

Причина №3: реструктуризация конфигурации

Есть специфичный для 1С сценарий, который застаёт врасплох: обновление или доработка конфигурации с изменением структуры метаданных. Когда платформа реструктуризирует таблицы (добавление реквизита, смена типа, изменение состава измерений регистра), она пересоздаёт и перезаписывает крупные таблицы целиком. В модели FULL каждая такая операция полностью протоколируется в журнале - и файл .ldf может за одно обновление вырасти в разы, даже если сама база невелика.

Это нормальное разовое поведение, а не поломка. Практический вывод: перед крупным обновлением конфигурации на большой базе имеет смысл заранее оценить свободное место под журнал, а после обновления - вернуть журнал к рабочему размеру одним шринком и продолжить штатное расписание бэкапов. Если обновления частые, а окно узкое, иногда конфигурацию временно переводят в SIMPLE на время реструктуризации и возвращают в FULL после - но, как и в любом переключении модели, это разрывает цепочку бэкапов лога и требует нового полного бэкапа сразу после возврата.

Как отслеживать журнал, а не тушить пожар

Разросшийся .ldf до потолка диска - всегда следствие того, что за журналом не следили. Чтобы не возвращаться к ручному шринку раз в неделю, стоит поставить наблюдение:

Размер и заполнение журнала. Команда DBCC SQLPERF(LOGSPACE) показывает по каждой базе размер журнала и процент использования. Регулярный съём этой метрики ловит рост до того, как он забьёт диск.
log_reuse_wait_desc в динамике. Если значение подолгу держится на LOG_BACKUP - бэкапы лога не идут или идут реже, чем нужно; на ACTIVE_TRANSACTION - где-то висит транзакция.
Число VLF. Тысячи виртуальных лог-файлов замедляют старт базы и восстановление; это сигнал, что autogrowth задан слишком мелкими порциями.
Оповещения об аварии. В наших проектах критичные события (переполнение, зависшие обмены, аварии заданий) уходят в Telegram-оповещения - проблему видно в момент возникновения, а не когда встала работа.

Мониторинг размеров, ожиданий и зависаний - часть услуги “обслуживание баз 1С”: журнал перестаёт быть источником внезапных ЧП и становится управляемой метрикой.

Чек-лист: журнал транзакций разросся

Посмотрел recovery_model_desc и log_reuse_wait_desc для базы.
LOG_BACKUP → решил вопрос модели: FULL с бэкапами лога или осознанный SIMPLE (с согласованием потери данных).
ACTIVE_TRANSACTION → нашёл (DBCC OPENTRAN) и корректно завершил зависшую/долгую транзакцию.
Настроил вменяемый autogrowth журнала (фиксированный размер, не проценты).
Шринк журнала сделал один раз после устранения причины, а не как регламент.
Проверил число VLF после стабилизации.
Задокументировал решение по модели восстановления и допустимой потере данных.

Итог

Разросшийся файл .ldf - почти всегда не проблема журнала, а проблема настройки. Чаще всего это модель FULL без бэкапов журнала (log_reuse_wait_desc = LOG_BACKUP), реже - зависшая транзакция. Шринк лечит симптом на неделю; настоящее решение - либо FULL с регулярными бэкапами лога, либо осознанный переход в SIMPLE с согласованной потерей данных. Выбор между ними - это вопрос “сколько данных бизнес готов потерять при аварии”, а не вопрос свободного места на диске.

Отдельный случай - когда переполняется не журнал вашей базы, а tempdb, и сеанс падает с ошибкой 9002. Причины там другие: не бэкапы лога, а длинная транзакция, рост version store при RCSI или отложенное освобождение страниц. Разбор с диагностикой по шагам - в статье “tempdb is full”: ошибка 9002 в 1С.

Проверить разом все настройки, из-за которых журнал ведёт себя не так (модель восстановления, размер и autogrowth лога, доля занятого пространства, длинные транзакции), можно чек-апом СУБД под 1С - там эти пункты идут с вердиктом по каждому, а не отдельными запросами.

Отдельная беда - когда всё это надо выяснить прямо сейчас, учёт стоит, а доступа к SQL Server у вас нет. DBCC OPENTRAN из предыдущего абзаца требует прав, которых у программиста 1С обычно не бывает. На этот случай мы собрали обработку “Диагностика журнала транзакций”: она читает log_reuse_wait_desc, называет держателя транзакции по имени пользователя и компьютеру (длительность берёт из журнала регистрации, а не из СУБД) и печатает готовый скрипт администратору. К базе обработка не подключается и ничего в ней не меняет.

Настройка модели восстановления, расписания бэкапов, autogrowth и авто-сторожа зависаний входит в услугу “обслуживание баз 1С на SQL Server”. Если хотите сначала понять, что именно раздувает вашу базу и журнал, начните с бесплатного экспресс-аудита - по его итогам вы получите диагноз и план, не покупая работы вслепую.

INFOSTART TECH EVENT 2026: конференция для 1с-специалистов. если собираетесь, регистрируйтесь по нашей ссылке. Регистрация →