1С и SQL Server: как сжать лог файл транзакций

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

Сжать лог можно штатными средствами SQL Server Management Studio или запросом T-SQL, и в большинстве случаев это занимает несколько минут. Однако механическое сжатие без изменения настроек приведёт к тому, что через неделю–месяц проблема вернётся. Поэтому правильный подход состоит из трёх шагов: освободить место, выбрать подходящую модель восстановления и настроить регулярное обслуживание.

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

Почему лог-файл базы 1С растёт и когда это опасно

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

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

Опасность не только в заполнении диска. Когда место заканчивается, транзакции 1С начинают завершаться с ошибками, пользователи не могут провести документы, а база может перейти в состояние, требующее восстановления. Поэтому контроль размера лога — обязательная часть администрирования связки 1С + SQL Server.

Подготовка: что проверить перед сжатием

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

Убедитесь, что у вас есть права: нужна роль sysadmin или db_owner на уровне базы, а также доступ к SQL Server Management Studio (SSMS) или возможность выполнять запросы через sqlcmd. Проверьте текущую модель восстановления: откройте свойства базы, вкладка «Параметры» (Options), поле «Модель восстановления».

Также зафиксируйте текущие размеры файлов, чтобы потом оценить результат. Это можно сделать запросом к системному представлению sys.database_files — он покажет размер файла данных и лога в мегабайтах.

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

Графический способ подходит, когда операция разовая и выполняет её администратор без глубокого знания T-SQL. Последовательность такая:

1. 1
   Откройте свойства базы, вкладка Options, установите Recovery model = Simple, нажмите OK
2. 2
   Кликните правой кнопкой по базе: Tasks → Shrink → Files
3. 3
   В поле File type выберите Log, оставьте действие по умолчанию (Release unused space), нажмите OK
4. 4
   Дождитесь завершения операции и проверьте размер файла на диске
5. 5
   Если требуется Full-модель — верните её и сразу сделайте полный бэкап базы

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

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

Способ 2: сжатие лога скриптом T-SQL

Скрипт удобнее для автоматизации и для случаев, когда баз много. Логическое имя лог-файла можно узнать запросом к sys.database_files (обычно это имя вида «ИмяБазы_log», но лучше проверить).

USE [ИмяБазы1С];
GO
ALTER DATABASE [ИмяБазы1С] SET RECOVERY SIMPLE;
GO
CHECKPOINT;
GO
DBCC SHRINKFILE (N'ИмяБазы1С_log', 1024);
GO
-- при необходимости вернуть полную модель:
-- ALTER DATABASE [ИмяБазы1С] SET RECOVERY FULL;
GO

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

Для нескольких баз скрипт оборачивают в цикл по списку баз или выполняют через msdb.dbo.sp_MSforeachdb с фильтром по имени. В продуктивной среде лучше запускать сжатие в нерабочее время: операция может кратковременно повышать нагрузку на дисковую подсистему.

Почему сжатие может не сработать

Самая частая причина — активный виртуальный лог-файл (VLF) находится в конце физического файла. SQL Server может освободить только неактивное пространство до последнего активного VLF. Помогает последовательность: CHECKPOINT (в Simple-модели), затем повторный SHRINKFILE, иногда два-три раза подряд.

Вторая причина — долгая незавершённая транзакция. Открытая транзакция удерживает журнал от точки своего начала, и сжать пространство до неё невозможно. Найти её можно запросом к sys.dm_tran_database_transactions или через Activity Monitor. Решение — дождаться завершения или, с пониманием рисков, завершить зависший сеанс.

Третья причина — репликация, Always On или log shipping: эти механизмы удерживают записи журнала до их доставки на вторичные узлы. Если в базе 1С они не используются, но когда-то включались, проверьте значение log_reuse_wait_desc в sys.databases — там будет указано, что именно блокирует очистку лога.

Выбор модели восстановления для базы 1С

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

Полная модель (Full) оправдана, когда критично восстановление на произвольный момент времени: например, в базе с непрерывным вводом первичных документов, где потеря даже часа работы недопустима. Но тогда обязательно нужен регулярный бэкап журнала транзакций — например, каждые 15–60 минут, — иначе лог снова разрастётся.

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

Настройте план обслуживания: для Simple-модели достаточно ежедневного полного бэкапа и периодической реиндексации; для Full добавьте бэкап журнала с интервалом 15–60 минут. Бэкап журнала — единственный штатный механизм, который регулярно освобождает место в логе при Full-модели.

Задайте разумные параметры автоприроста файла: фиксированный прирост в мегабайтах (например, 256–1024 МБ) вместо прироста в процентах. Процентный прирост на большом файле приводит к огромным разовым расширениям и паузам в работе 1С.

Контролируйте массовые операции: обмены, перепроведение за длительный период и обновления конфигурации планируйте на нерабочее время и при необходимости временно переводите базу в Simple на время операции. Настройте мониторинг свободного места на диске с данными SQL Server — сигнал о заполнении на 80% даёт время среагировать до остановки работы.

Проверка результата после сжатия

После операции убедитесь, что файл физически уменьшился: откройте каталог данных и сравните размер .ldf с исходным. Затем проверьте состояние базы запросом к sys.databases — поле state_desc должно быть ONLINE, а log_reuse_wait_desc — в значении NOTHING или CHECKPOINT.

Функциональная проверка: войдите в 1С, проведите тестовый документ, выполните типовой отчёт. Если бэкапы настроены, убедитесь, что после возврата Full-модели сделан полный бэкап — без него последующие бэкапы журнала не имеют смысла.

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