Как уменьшить файл лога в 1С и не допустить его повторного роста

Файл лога в 1С чаще всего означает одно из двух: журнал транзакций базы данных MS SQL Server (файл с расширением .ldf) или журнал регистрации 1С, который хранит историю действий пользователей. Оба файла имеют свойство разрастаться до десятков и сотен гигабайт, заполняя диск и замедляя работу базы. Симптомы типичны: заканчивается место на диске, 1С начинает «тормозить», а при полном заполнении диска работа базы останавливается с ошибками записи.

Причина почти всегда одна — лог растёт, но не очищается. В MS SQL журнал транзакций в полной модели восстановления накапливает все изменения и усекается только после резервного копирования журнала. Журнал регистрации 1С по умолчанию вообще не имеет ограничения по сроку хранения. Простое удаление файла или его «обрезка» вручную недопустимы: это приводит к повреждению базы.

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

Определяем, какой именно лог вырос

Прежде чем что-то сжимать, нужно понять, какой файл занимает место. Откройте каталог данных SQL Server (обычно что-то вроде C:\Program Files\Microsoft SQL Server\MSSQL…\DATA) и посмотрите размеры файлов вашей базы. Файл с расширением .ldf — это журнал транзакций, .mdf — сами данные. Если вырос именно .ldf, проблема в журнале транзакций SQL Server.

Журнал регистрации 1С в клиент-серверном варианте хранится в каталоге srvinfo в папке reg_1541 (или с другим портом) в виде файлов с расширением .lgp и служебных файлов. В файловом варианте базы журнал регистрации лежит внутри каталога базы. Его рост не влияет на размер .ldf, но тоже может съесть диск.

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

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

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

Важно понимать: сжатие файла (shrink) не решает причину. Если после сжатия не настроить усечение журнала, через неделю или месяц файл вернётся к прежнему размеру.

Сжатие журнала транзакций MS SQL

Самый предсказуемый способ для баз 1С, где не требуется восстановление на произвольный момент времени, — перевести базу в простую модель восстановления (Simple), усечь журнал и сжать файл. В модели Simple журнал усекается автоматически после checkpoint, и его рост ограничивается размером самой крупной текущей транзакции.

Операции выполняются в SQL Server Management Studio (SSMS) под учётной записью с правами администратора сервера. Во время сжатия база остаётся доступной, но производительность может проседать, поэтому лучше делать это в нерабочее время.

1. 1
   Сделайте полную резервную копию базы: правый клик по базе → Tasks → Back Up → Full
2. 2
   Переведите базу в модель Simple: правый клик → Properties → Options → Recovery model → Simple
3. 3
   Выполните сжатие: Tasks → Shrink → Files → тип файла Log, действие «Release unused space» или «Reorganize pages» с указанием целевого размера
4. 4
   Дождитесь завершения операции и проверьте размер .ldf на диске
5. 5
   Настройте регулярные полные бэкапы базы, чтобы журнал не рос повторно

Тот же результат достигается скриптом T-SQL, что удобно для автоматизации:

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

Здесь MyBase — имя вашей базы, MyBase_log — логическое имя файла журнала (его можно посмотреть в свойствах базы на вкладке Files), 1024 — целевой размер в мегабайтах. Не ставьте целевой размер слишком маленьким: при активной работе журналу нужен запас, иначе он будет постоянно авторостить, что снижает производительность.

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

Если требуется восстановление базы на любой момент времени (например, по требованиям к сохранности учётных данных), модель Full менять нельзя. В этом случае журнал уменьшается иначе: сначала делается резервная копия журнала транзакций (Backup → Transaction Log), которая усекает неактивную часть, и только после этого выполняется Shrink файла. Без бэкапа журнала сжатие почти ничего не даст — файл физически не уменьшится, потому что вся его область считается активной.

Сокращение журнала регистрации 1С

Журнал регистрации фиксирует действия пользователей, ошибки, изменения данных. За годы работы он может занимать заметный объём и замедлять открытие журнала в конфигураторе. Штатный способ его уменьшить — сокращение через конфигуратор.

Откройте конфигуратор с правами администратора, перейдите в меню «Администрирование → Настройка журнала регистрации» и нажмите кнопку «Сократить». Укажите дату, до которой удалять события, и обязательно задайте каталог для сохранения выгрузки удаляемой части в файл — это позволит восстановить историю, если она понадобится для расследования инцидента. Для выполнения сокращения требуется монопольный доступ к базе: все пользователи должны завершить сеансы.

В том же окне настройте ограничение на будущее: установите переключатель «Регистрировать события за период» или настройте расписание автоматического сокращения, если ваша версия платформы это поддерживает. Также имеет смысл снизить детализацию: отключите регистрацию второстепенных событий, если журнал растёт слишком быстро.

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

Разовое сжатие решает симптом. Чтобы лог не вырос снова, нужны три настройки: модель восстановления, соответствующая вашим требованиям; регулярные резервные копии (полные — ежедневно, журнала — несколько раз в день при модели Full); контроль размера файлов и свободного места на диске.

Ограничьте максимальный размер файла журнала разумным значением, чтобы при аномальной нагрузке получить ошибку и разобраться с причиной, а не переполненный диск. Но будьте осторожны: при достижении лимита транзакции будут откатываться с ошибкой 9002, поэтому лимит должен быть с запасом относительно обычного объёма.

Массовые операции — перепроведение, загрузки, свёртку базы — планируйте на нерабочее время и при возможности дробите на порции, чтобы размер одной транзакции был умеренным. После таких операций проверяйте размер .ldf и при необходимости выполняйте плановое сжатие.

Проверка результата

После сжатия убедитесь, что цель достигнута и ничего не сломано. Проверьте физический размер .ldf на диске — он должен соответствовать заданному целевому. Откройте свойства базы и убедитесь, что модель восстановления соответствует запланированной. Выполните тестовое подключение из клиента 1С и проверьте типовые операции: открытие документов, проведение, формирование отчёта.

Для журнала регистрации откройте его в конфигураторе и убедитесь, что события старше установленной даты удалены, а свежие — на месте. Проверьте, что файл выгрузки сокращённой части создан и открывается.

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