Как сжать логи 1С в SQL Server и не допустить разрастания журнала транзакций

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

Ключевой момент: размер LDF-файла определяется не объёмом данных, а моделью восстановления базы и наличием регулярных резервных копий журнала. В модели Full журнал не очищается сам — SQL Server хранит все транзакции до тех пор, пока не будет сделан бэкап лога. В модели Simple неактивная часть журнала освобождается автоматически после контрольной точки.

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

Почему лог транзакций базы 1С разрастается

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

Основные причины неконтролируемого роста LDF-файла:

• база работает в модели восстановления Full, но резервные копии журнала не делаются — неактивная часть лога никогда не освобождается;
• регламентные операции (пересчёт итогов, реиндексация, обновление конфигурации) выполняются одной большой транзакцией;
• настроен лог-шиппинг или репликация, которые удерживают журнал, пока записи не будут переданы;
• долгие открытые транзакции — зависший сеанс 1С блокирует освобождение журнала.

Как проверить состояние базы перед сжатием

Прежде чем что-либо сжимать, выясните три вещи: текущую модель восстановления, фактическое заполнение журнала и причину, по которой он не освобождается. Это делается тремя простыми запросами в SQL Server Management Studio (SSMS).

SELECT name, recovery_model_desc, log_reuse_wait_desc FROM sys.databases WHERE name = 'ИмяБазы1С';
DBCC SQLPERF(LOGSPACE);
DBCC LOGINFO('ИмяБазы1С');

Первый запрос покажет модель восстановления и причину удержания журнала. Если в поле log_reuse_wait_desc стоит LOG_BACKUP — журнал ждёт резервной копии. Если ACTIVE_TRANSACTION — есть незавершённая транзакция, и сжатие пока бесполезно. DBCC SQLPERF покажет, какой процент файла журнала реально занят: если использовано 2–3 %, файл можно сжать почти полностью.

Способ 1: смена модели восстановления на Simple

Самый быстрый и распространённый вариант для баз 1С, где не требуется восстановление на произвольный момент времени. В модели Simple SQL Server сам освобождает неактивную часть журнала, и файл перестаёт расти бесконечно.

Порядок действий:

1. Убедитесь, что есть свежая полная резервная копия базы.
2. В SSMS откройте свойства базы → Параметры (Options) → установите модель восстановления «Простая» (Simple).
3. Выполните сжатие файла журнала (способы ниже).
4. Сделайте новую полную резервную копию после завершения.

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

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

Способ 2: сжатие журнала в модели Full через бэкап лога

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

BACKUP LOG [ИмяБазы1С] TO DISK = N'D:\Backup\log_backup.trn';
GO
DBCC SHRINKFILE (N'ИмяЛогическогоФайлаЖурнала', 1024);
GO

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

После сжатия обязательно настройте регулярное резервное копирование журнала — например, каждые 15–60 минут через план обслуживания (Maintenance Plan) или задание SQL Server Agent. Это единственный способ удерживать размер LDF под контролем в модели Full.

Как выполнить сжатие через интерфейс SSMS

Тем, кто не привык к SQL-запросам, тот же результат доступен через графический интерфейс Management Studio.

1. 1
   Подключитесь к серверу и раскройте список баз
2. 2
   Щёлкните правой кнопкой по базе 1С → Задачи (Tasks) → Сжать (Shrink) → Файлы (Files)
3. 3
   В поле «Тип файла» выберите «Журнал» (Log)
4. 4
   Выберите действие «Освободить неиспользуемое пространство» или укажите целевой размер
5. 5
   Нажмите OK и дождитесь завершения операции
6. 6
   Проверьте размер LDF-файла на диске

Имя логического файла журнала (оно нужно для DBCC SHRINKFILE) смотрите в свойствах базы на вкладке «Файлы» (Files) — колонка «Логическое имя». Обычно это что-то вроде имябазы_log, но при переносах базы имя может отличаться.

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

Сжатие — разовая операция. Если не устранить причину, через неделю или месяц файл вырастет снова, а регулярные циклы «разросся — сжали» вредны: они приводят к фрагментации файла журнала и снижают производительность дисковой подсистемы.

Дополнительные профилактические меры:

• настройте разумный прирост файла журнала — фиксированное значение в мегабайтах (например, 256–512 МБ), а не 10 %, которые на большом файле дают гигантские шаги роста;
• следите за свободным местом на диске с LDF — переполнение диска останавливает всю базу;
• массовые операции (загрузки, перепроведение) по возможности выполняйте порциями, а не одной транзакцией;
• периодически контролируйте размер журналов всех баз запросом DBCC SQLPERF(LOGSPACE).

Как проверить результат и границы самостоятельной работы

Самостоятельно безопасно выполнять: смену модели восстановления на тестовой базе, сжатие журнала при наличии свежей полной резервной копии, настройку бэкапов журнала через план обслуживания. К администратору или специалисту по SQL Server стоит обращаться, если база участвует в репликации или Always On, если журнал не сжимается после всех операций, или если база перешла в состояние suspect после некорректных действий с файлами.

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