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

Журнал транзакций в 1С быстро разрастается и начинает занимать десятки гигабайт на диске, замедлять работу базы и мешать резервному копированию. При этом под «журналом транзакций» понимают две разные вещи: файл 1Cv7.mlg в файловых базах 1С:Предприятие 7.7 и журнал транзакций (transaction log) базы данных SQL Server, на котором работают клиент-серверные версии 1С 8.x. Подход к очистке в каждом случае свой, и путать их нельзя.

Очистка журнала — операция потенциально опасная для данных. Неправильное усечение лога SQL Server может нарушить цепочку резервных копий и лишить возможности восстановить базу на конкретный момент времени, а удаление файла .mlg без резервной копии приведёт к потере истории изменений. Поэтому любые действия начинаются с создания актуальной резервной копии базы.

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

Определяем, какой журнал транзакций разросся

Прежде чем что-то чистить, нужно понять, с чем вы имеете дело. Если база работает в файловом режиме 1С:Предприятие 7.7, в каталоге базы лежит файл 1Cv7.mlg — именно он накапливает записи о транзакциях и изменениях. Если его размер исчисляется гигабайтами, а диск заполнен — проблема в нём.

Если 1С работает в клиент-серверном режиме на Microsoft SQL Server, то у каждой базы есть файл журнала транзакций с расширением .ldf. Узнать его размер можно в SQL Server Management Studio (SSMS): правый клик по базе → «Свойства» → «Файлы», либо запросом к системным представлениям. Типичный признак проблемы — файл .ldf в разы больше файла данных .mdf.

Для файловых баз 1С 8.x (файл 1Cv8.1CD) отдельного журнала транзакций нет — там есть только журнал регистрации, который очищается другими способами (через настройку срока хранения в конфигураторе). Не путайте эти сущности.

Подготовка: резервная копия и завершение сеансов

Любая очистка журнала начинается с полной резервной копии. Для файловой базы достаточно скопировать весь каталог базы (как минимум файлы 1Cv7.DD, 1Cv7.DBA/1Cv7.md и словарь данных) на отдельный носитель. Для SQL-базы выполните полное резервное копирование средствами SSMS: правый клик по базе → «Задачи» → «Создать резервную копию», тип — «Полная».

Второе обязательное условие — все пользователи должны выйти из базы, а фоновые задания и агенты интеграции — остановлены. В 1С 7.7 активные сеансы можно посмотреть через монитор пользователей; на SQL Server — через «Монитор активности» в SSMS. Усечение журнала при активных транзакциях либо не выполнится, либо приведёт к ошибкам.

Очистка журнала транзакций в 1С 7.7 (файл 1Cv7.mlg)

В 1С:Предприятие 7.7 штатного инструмента «очистить журнал» нет — файл 1Cv7.mlg пересоздаётся. Стандартная процедура выглядит так: завершите все сеансы, сделайте копию каталога базы, затем запустите конфигуратор в монопольном режиме и выполните «Администрирование» → «Тестирование и исправление ИБ» либо просто откройте и сохраните конфигурацию — при старте конфигуратор может пересоздать журнал, если старый удалён.

Практический способ, который используют администраторы: при остановленной базе удалить (или переименовать) файл 1Cv7.mlg в каталоге базы, затем зайти в конфигуратор в монопольном режиме. 1С создаст новый пустой журнал. Старый файл храните отдельно до тех пор, пока не убедитесь, что база работает корректно и резервная копия на месте.

Учтите: в 1Cv7.mlg хранится история изменений, которую используют механизмы распределённых баз (УРБД/УРИБ). Если база входит в распределённую систему, удалять журнал без выгрузки данных в узлы нельзя — синхронизация нарушится, и потребуется повторная инициализация узлов.

1. 1
   Выгнать всех пользователей и остановить обмены
2. 2
   Скопировать каталог базы в резервное хранилище
3. 3
   Переименовать 1Cv7.mlg (например, в 1Cv7.mlg.old)
4. 4
   Запустить конфигуратор в монопольном режиме — журнал пересоздастся
5. 5
   Проверить вход в базу и работу документов
6. 6
   Удалить старый файл только после проверки и наличия копии

Усечение журнала транзакций на SQL Server

Для клиент-серверной 1С 8.x основной сценарий — усечение файла .ldf средствами SQL Server. Причина разрастания почти всегда одна: база работает в полной модели восстановления (Full), а резервное копирование журнала транзакций не настроено, поэтому лог только растёт.

Если вам не требуется восстановление базы на произвольный момент времени (для большинства баз 1С это допустимо при регулярных полных копиях), самый простой путь — перевести базу в простую модель восстановления и сжать файл журнала. В SSMS: правый клик по базе → «Свойства» → «Параметры» → «Модель восстановления» → «Простая». Затем правый клик по базе → «Задачи» → «Сжать» → «Файлы», выберите тип файла «Журнал» и выполните сжатие.

Те же действия можно выполнить скриптом T-SQL:

ALTER DATABASE [ИмяБазы] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (N'ИмяЛогическогоФайлаЖурнала', 1024);
GO

Имя логического файла журнала смотрите в свойствах базы на вкладке «Файлы». Второй параметр SHRINKFILE — целевой размер в мегабайтах; не ставьте его слишком маленьким, журнал всё равно нужен для работы, и постоянное автоматическое увеличение файла снижает производительность.

ALTER DATABASE [MyBase] SET RECOVERY SIMPLE; DBCC SHRINKFILE (N'MyBase_log', 1024);

Если нужна полная модель восстановления

Когда требуется восстановление на точный момент времени, модель восстановления менять нельзя. Вместо этого настройте регулярное резервное копирование журнала транзакций (например, каждые 15–60 минут через план обслуживания): после каждой успешной копии журнала SQL Server помечает пространство как свободное, и файл перестаёт расти. Разовое усечение при этом делается связкой: резервная копия журнала → DBCC SHRINKFILE.

Настройка профилактики, чтобы журнал не разрастался снова

Разовая очистка решает симптом, но не причину. Для SQL-баз определитесь с моделью восстановления осознанно: простая модель + регулярные полные (и при желании разностные) копии подходят большинству баз 1С; полная модель оправдана только при настроенном резервном копировании журнала и реальной потребности в восстановлении на момент времени.

Настройте автоматический план обслуживания в SQL Server: полная копия ежедневно, разностная — несколько раз в день, копии журнала — по расписанию при полной модели. Следите и за начальным размером файла журнала и шагом автоприращения: приращение маленькими порциями в процентах приводит к фрагментации файла и лишним паузам при росте.

Для 1С 7.7 профилактика — периодическая загрузка-выгрузка данных через конфигуратор (она пересоздаёт файлы базы) и контроль размера каталога базы. Также проверьте, не копятся ли в каталоге старые архивы и временные файлы.

Проверка результата и типичные ошибки

После очистки убедитесь, что база работает: войдите в 1С под обычным пользователем, откройте несколько документов и отчётов, проведите тестовый документ. На SQL Server проверьте размер файла журнала и убедитесь, что резервное копирование после операций выполняется без ошибок — особенно если вы меняли модель восстановления: после перехода в полную модель нужно сразу сделать полную копию, иначе журнал снова начнёт расти, а цепочка восстановления не начнётся.

Самые частые ошибки: удаление .ldf-файла напрямую из файловой системы (база переходит в состояние suspect и перестаёт открываться), усечение журнала без резервной копии, удаление 1Cv7.mlg в распределённой базе до синхронизации узлов и сжатие файла данных вместо файла журнала. Ещё одна распространённая ситуация — администратор сжимает журнал, но не настраивает копии, и через месяц файл снова занимает весь диск.

Часто задаваемые вопросы