Как очистить журнал транзакций 1С

Журнал транзакций (файл с расширением .ldf) — это служебный файл базы данных SQL Server, в котором фиксируются все изменения данных. В клиент-серверных базах 1С он растёт постоянно, и при модели восстановления Full может занять десятки и сотни гигабайт, переполнить диск и остановить работу пользователей. Очистка журнала — штатная операция администрирования, но выполнять её нужно в правильной последовательности, иначе можно потерять возможность восстановления базы на произвольный момент времени.

Важно понимать: сам по себе большой .ldf-файл — не ошибка 1С, а следствие настроек SQL Server. Если база работает в полной модели восстановления (Full), журнал не усечётся автоматически, пока не выполнено резервное копирование журнала. Поэтому «очистка» всегда состоит из двух задач: освободить место внутри файла (усечение логических записей) и при необходимости уменьшить сам файл на диске (shrink).

Ниже описаны безопасные способы: через SQL Server Management Studio (SSMS), командами T-SQL, а также профилактические настройки, которые не дают журналу разрастаться снова. Все действия подходят для типовых конфигураций 1С (Бухгалтерия, Управление торговлей, ERP, ЗУП), работающих на MS SQL Server.

Когда журнал транзакций действительно нужно чистить

Тревожный признак — быстрый рост файла .ldf и сообщения об ошибках: «Недостаточно места на диске», «журнал транзакций для базы данных заполнен» (ошибка SQL Server 9002). Проверить размер можно в свойствах базы в SSMS (раздел «Файлы») или запросом к sys.database_files. Если лог-файл в разы превышает размер файла данных .mdf — это явный сигнал, что журнал никогда не усекался.

При этом небольшой запас журнала — норма. Файл, занимающий 10–20% от размера данных при активной работе пользователей, трогать не нужно. Частые принудительные сжатия вредны: они вызывают фрагментацию и заставляют сервер снова наращивать файл, что замедляет работу.

Подготовка: что сделать до очистки

Первое и обязательное действие — полная резервная копия базы данных штатными средствами SQL Server. Не путайте её с выгрузкой .dt из конфигуратора: для сжатия журнала нужен именно SQL-бэкап. Без него при сбое в процессе вы рискуете потерять данные за весь период с последнего архива.

Второй шаг — выяснить текущую модель восстановления: SSMS → свойства базы → «Параметры» → «Модель восстановления». От этого зависит сценарий: при Simple журнал усекается автоматически после контрольных точек, при Full — только после резервного копирования журнала. Также проверьте состояние ожидания усечения запросом: SELECT name, recovery_model_desc, log_reuse_wait_desc FROM sys.databases.

Третий момент — выберите время с минимальной нагрузкой. Сжатие файла (shrink) блокирует часть операций и на больших базах может занять продолжительное время. Идеально — вечер, ночь или выходной, когда пользователи не работают в 1С.

Способ 1: очистка через SQL Server Management Studio

Это самый наглядный путь для администратора, который редко работает с T-SQL. Откройте SSMS, подключитесь к серверу, найдите базу 1С в списке «Базы данных».

Если база в модели Full и бэкапы журнала не настроены, переведите её в Simple: правой кнопкой по базе → «Свойства» → «Параметры» → «Модель восстановления» → «Простая» → OK. После этого SQL Server сможет освобождать место внутри журнала автоматически.

Затем выполните сжатие файла: правой кнопкой по базе → «Задачи» → «Сжать» → «Файлы». В поле «Тип файла» выберите «Журнал», оставьте действие «Освободить неиспользуемое пространство» и нажмите OK. После завершения проверьте размер .ldf на диске — он должен уменьшиться до минимального.

1. 1
   Сделать полную резервную копию базы средствами SQL Server
2. 2
   Перевести базу в модель восстановления Simple
3. 3
   Выполнить Задачи → Сжать → Файлы → тип «Журнал»
4. 4
   Проверить размер .ldf на диске
5. 5
   Вернуть модель Full (если требуется) и сразу сделать полный бэкап

Способ 2: очистка командами T-SQL

Для автоматизации и работы на серверах без графической оболочки удобнее скрипт. Логическое имя журнала смотрите в свойствах базы или запросом к sys.database_files — обычно оно совпадает с именем базы с суффиксом _log.

ALTER DATABASE [MyBase1C] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (N'MyBase1C_log', 1024);
GO
ALTER DATABASE [MyBase1C] SET RECOVERY FULL;
GO

Вторая строка сжимает журнал примерно до 1024 МБ — размер можно изменить под свою базу. Важно: если возвращаете модель Full, сразу после этого выполните полное резервное копирование, иначе цепочка восстановления журнала будет разорвана и база фактически останется без защиты до первого бэкапа.

SELECT name, recovery_model_desc, log_reuse_wait_desc FROM sys.databases WHERE name = 'MyBase1C';

Способ 3: если нужна модель Full — резервное копирование журнала

Модель Full нужна там, где требуется восстановление базы на произвольный момент времени (point-in-time recovery) — например, в крупных ERP-системах с высокой ценой потери данных. В этом случае правильная «очистка» журнала — не смена модели, а регулярное резервное копирование журнала транзакций: BACKUP LOG [MyBase1C] TO DISK = 'D:\Backup\log.trn'.

После успешного бэкапа журнала место внутри файла освобождается автоматически, и сжимать файл нужно только если он уже сильно разросся. Настройте задание (maintenance plan или скрипт через SQL Server Agent) с копированием журнала, например, каждые 15–60 минут — периодичность зависит от интенсивности работы пользователей.

Профилактика: как не допустить повторного роста

Выберите модель восстановления осознанно. Для большинства файловых по нагрузке баз 1С среднего размера достаточно Simple плюс ежедневный полный бэкап (и при возможности разностный днём). Full без настроенных копий журнала — гарантированный путь к переполнению диска.

Дополнительно ограничьте максимальный размер лог-файла в свойствах базы (автоувеличение с разумным шагом и верхним пределом) и настройте мониторинг свободного места на диске. Учтите, что массовые операции в 1С — перепроведение документов, свёртка базы, загрузка данных — резко наращивают журнал даже в модели Simple, поэтому запас свободного места на диске должен быть всегда.

Типичные ошибки при очистке журнала

Отдельная ошибка — пытаться очистить журнал во время активной работы пользователей. Длинные открытые транзакции блокируют усечение: shrink завершится «успешно», но файл не уменьшится. Проверить активные транзакции можно запросом DBCC OPENTRAN — если есть старая открытая транзакция, сначала завершите сеанс, который её держит.

Как проверить результат

Финальный контроль — понаблюдать за ростом журнала несколько дней. Если при модели Simple файл снова быстро растёт, ищите источник: массовые загрузки, обмены данными, длительные регламентные операции. Возможно, стоит увеличить исходный размер файла и шаг авторасширения, чтобы сервер не тратил ресурсы на постоянное наращивание.

Частые вопросы