Почему разрастается журнал транзакций LDF базы 1С в MS SQL Server и как правильно уменьшить его размер?

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

Причины разрастания файла журнала транзакций при обновлении 1С

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

1. Создает временные служебные таблицы для модифицируемых объектов.
2. Переносит в них существующие данные.
3. Пересоздает исходные таблицы с новой структурой колонок и типов.
4. Возвращает данные из временных таблиц в новые и перестраивает индексы.

Если для базы данных в MS SQL Server установлена полная модель восстановления (FULL), каждая из перечисленных операций в полном объеме протоколируется в журнал транзакций. В результате даже небольшое обновление может увеличить файл .ldf на несколько гигабайтов. Аналогичный эффект вызывают операции перестроения индексов (Rebuild Index), которые также генерируют объем записей в журнале, сопоставимый с объемом самих таблиц.

Почему размер резервной копии (.bak) постоянно увеличивается

Выясним причину, по которой файл бэкапа может постоянно расти в размерах при регулярном создании копий. В графическом интерфейсе SQL Server Management Studio (SSMS) при настройке резервного копирования доступен выбор режима записи в файл:

1. Добавление в существующий набор носителей (Append / WITH NOINIT): в этом режиме каждая новая резервная копия дописывается в конец указанного файла .bak. В результате размер файла бэкапа непрерывно суммируется с каждым запуском задачи.
2. Перезапись всех существующих резервных наборов (Overwrite / WITH INIT): в этом режиме предыдущее содержимое файла полностью стирается, и записывается только текущая копия.

Чтобы избежать бесконечного роста файла бэкапа, необходимо либо включать флаг перезаписи (WITH INIT), либо настраивать динамическое формирование имени файла с текущей датой и временем (например, через планы обслуживания Maintenance Plans или скрипты SQL Server Agent).

Как уменьшить размер журнала транзакций (Shrink) без потери данных

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

Разберем по шагам, как выполнить сжатие через SQL Server Management Studio (SSMS):

1. Открываем SSMS и подключаемся к экземпляру SQL Server.
2. В дереве Обозревателя объектов раскрываем ветку Базы данных.
3. Нажимаем правой кнопкой мыши по нужной базе 1С и переходим в меню Задачи (Tasks) → Сжать (Shrink) → Файлы (Files).
4. В открывшемся окне в поле Тип файла (File type) обязательно выбираем значение Журнал (Log).
5. В блоке Операция сжатия (Shrink action) выбираем Освободить неиспользуемое место (Release unused space) или указываем желаемый целевой размер.
6. Нажимаем кнопку ОК для запуска процедуры.

Почему сжатие лога может не сработать и как это исправить

Иногда после выполнения операции Shrink размер файла .ldf не уменьшается. Проанализируем основные причины такого поведения:

1. Отсутствие резервных копий журнала в полной модели восстановления: в модели FULL виртуальные файлы журнала (VLF) не могут быть усечены до тех пор, пока не будет выполнен бэкап журнала транзакций (BACKUP LOG). Без бэкапа лога все записи считаются активными.
2. Слишком редкий бэкап транзакций: интервал резервного копирования логов в 2 часа для активно работающей базы 1С слишком велик. За это время накапливается значительный объем транзакций.
3. Активная незавершенная транзакция в 1С: зависший сеанс пользователя или длительное регламентное фоновое задание удерживают журнал от усечения. Пока транзакция не зафиксирована (COMMIT) или не отменена (ROLLBACK), место перед ней не освободится.
4. Расположение активного VLF: если активная область журнала находится в физическом конце файла, SQL Server не может отрезать неиспользуемый хвост.

Чтобы выяснить точную причину блокировки очистки лога, выполним запрос к системному представлению:

SELECT name, recovery_model_desc, log_reuse_wait_desc 
FROM sys.databases 
WHERE name = 'ИмяБазы1С';

Если в поле log_reuse_wait_desc указано LOG_BACKUP, необходимо выполнить резервное копирование журнала транзакций. Если указано ACTIVE_TRANSACTION — следует найти и завершить долгую транзакцию в 1С или на стороне SQL Server.

Рекомендации по обслуживанию базы 1С на MS SQL Server

Рассмотрим правила корректной настройки базы данных для стабильной производительности 1С:

1. Выбор модели восстановления: если для информационной базы не требуется восстановление на произвольную секунду времени (Point-in-Time Recovery), переведите базу в простую модель восстановления (SIMPLE). В этом режиме журнал транзакций автоматически усекается после каждой контрольной точки (CHECKPOINT) и не требует постоянного сжатия.
2. Периодичность бэкапов в модели FULL: если используется полная модель восстановления, бэкап журнала транзакций необходимо делать каждые 10–15 минут. Это удерживает размер файла .ldf в компактном состоянии.
3. Регламент обновлений: перед установкой тяжелых релизов конфигураций 1С с масштабной реструктуризацией целесообразно перевести базу в режим SIMPLE, применить обновление, затем вернуть модель FULL и сразу сделать полную резервную копию.
4. Настройка автороста (Autogrowth): отключите прирост файлов в процентах. Задайте фиксированный шаг автороста для лога (например, 512 МБ или 1024 МБ), чтобы избежать сильной фрагментации виртуальных файлов журнала (VLF).
5. Запрет на Auto-Shrink: никогда не включайте параметр автоматического сжатия (AUTO_SHRINK) на уровне базы данных. Постоянные циклы расширения и сжатия файлов вызывают критическую фрагментацию диска и резкое падение скорости работы 1С. Сжатие файлов следует выполнять только вручную и по мере разовой необходимости.