Как уменьшить файл LDF журнала транзакций SQL Server для базы 1С

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

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

Ниже разобраны причины роста журнала, оба способа уменьшения с пошаговыми командами, проверка результата и профилактика, чтобы ситуация не повторилась. Все действия выполняются в среде SQL Server Management Studio (SSMS) или через запросы T-SQL и одинаково применимы к базам 1С:Предприятие любых конфигураций.

Почему файл LDF разрастается в базах 1С

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

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

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

Проверка модели восстановления и состояния журнала

Прежде чем сжимать файл, определите, в какой модели работает база и что мешает усечению журнала. Это делается одним запросом:

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

Если recovery_model_desc равен FULL, а log_reuse_wait_desc — LOG_BACKUP, значит журнал ждёт резервного копирования, и без него shrink не даст эффекта. Если указано NOTHING — журнал можно усечь сразу. Значение ACTIVE_TRANSACTION говорит о зависшей транзакции: сначала нужно найти и завершить её, иначе сжатие пройдёт частично или не пройдёт вовсе.

Также посмотрите фактическое заполнение файла журнала командой DBCC SQLPERF(LOGSPACE): она показывает размер каждого журнала и процент использования. Если LDF занимает 100 ГБ, но использовано 2%, после усечения файл сожмётся почти полностью. Если использовано 90% — сначала нужно разобраться, что удерживает журнал.

Способ 1: безопасное уменьшение через бэкап журнала (модель Full)

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

Порядок команд:

-- 1. Резервная копия журнала (усекает журнал)
BACKUP LOG [ИмяБазы1С]
TO DISK = 'D:\Backup\ИмяБазы1С_log.trn';

-- 2. Сжатие файла журнала до заданного размера (например, 1024 МБ)
USE [ИмяБазы1С];
DBCC SHRINKFILE (N'ИмяЛогическогоФайлаЖурнала', 1024);

Логическое имя файла журнала узнаётся запросом SELECT name FROM sys.database_files WHERE type_desc = 'LOG' — оно не всегда совпадает с именем файла на диске. Второй параметр SHRINKFILE — целевой размер в мегабайтах, до которого нужно сжать файл.

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

1. 1
   Сделайте полную резервную копию базы на случай сбоя
2. 2
   Выполните BACKUP LOG для усечения журнала
3. 3
   Узнайте логическое имя файла журнала через sys.database_files
4. 4
   Выполните DBCC SHRINKFILE с целевым размером
5. 5
   При неполном сжатии повторите BACKUP LOG и SHRINKFILE
6. 6
   Настройте регулярное расписание бэкапов журнала, чтобы проблема не повторилась

Способ 2: быстрое уменьшение через простую модель восстановления

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

-- 1. Перевод базы в простую модель восстановления
ALTER DATABASE [ИмяБазы1С] SET RECOVERY SIMPLE;

-- 2. Сжатие файла журнала
USE [ИмяБазы1С];
DBCC SHRINKFILE (N'ИмяЛогическогоФайлаЖурнала', 1024);

После перевода в Simple выполните команду CHECKPOINT, чтобы ускорить усечение журнала, и только затем сжимайте файл. Если базу нужно вернуть в модель Full, сделайте это после shrink и сразу создайте полную резервную копию — именно с неё начнётся новая цепочка восстановления.

Альтернатива: уменьшение через графический интерфейс SSMS

Те же операции доступны без написания запросов. Модель восстановления меняется в свойствах базы: правый клик по базе — «Свойства» — вкладка «Параметры» — поле «Модель восстановления». После смены на «Простая» журнал будет усечён при ближайшей контрольной точке.

Сжатие выполняется через контекстное меню базы: «Задачи» — «Сжать» — «Файлы». В диалоге выберите тип файла «Журнал», укажите действие «Освободить неиспользуемое пространство» или «Реорганизовать страницы» с целевым размером и подтвердите. Результат идентичен команде DBCC SHRINKFILE.

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

Сравнение подходов

Бэкап журнала + shrink (модель Full)

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

Перевод в Simple + shrink

Быстро и просто, журнал дальше не растёт без контроля. Подходит большинству баз 1С. Минус — восстановление только на момент последнего полного бэкапа.

Shrink через SSMS

Тот же результат без написания кода. Удобно для разовой операции, неудобно для регулярного обслуживания нескольких баз.

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

Самая частая причина неудачного сжатия — журнал не был усечён перед shrink. Команда DBCC SHRINKFILE умеет уменьшать только свободную часть файла; если внутри журнала есть активные записи до самого конца файла, физический размер не изменится, хотя команда выполнится без ошибок.

Вторая причина — зависшая длинная транзакция. Незакрытый сеанс 1С, прерванное обновление конфигурации или забытый BEGIN TRAN в открытом окне запросов удерживают журнал от усечения. Найдите виновника запросом к sys.dm_tran_session_transactions и завершите сеанс командой KILL с номером SPID — предварительно убедившись, что это не активная рабочая операция.

Третья причина — включённая репликация, Always On или захват изменений (CDC): эти механизмы удерживают журнал до доставки записей подписчикам. Проверьте log_reuse_wait_desc — значения REPLICATION, AVAILABILITY_REPLICA или LOG_SCAN указывают именно на эту проблему, и решать её нужно на стороне соответствующего механизма, а не повторными попытками shrink.

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

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

Если нужна модель Full, настройте задание агента SQL Server на резервное копирование журнала каждые 15–60 минут. Это одновременно решает задачу усечения и даёт возможность восстановления на произвольный момент времени. Без регулярных BACKUP LOG модель Full для базы 1С практически гарантирует переполнение диска.

Дополнительные меры: установите разумное начальное значение и фиксированный шаг автоприращения файла журнала (например, 512–1024 МБ вместо 10% — процентное приращение на больших файлах создаёт огромные паузы), следите за свободным местом на диске мониторингом и планируйте массовые операции (перепроведения, обновления) на нерабочее время с контролем размера журнала.

Контрольные точки

Как проверить результат

Физический размер LDF на диске

Норма

Файл уменьшился до целевого размера после shrink

Тревожный признак

Размер не изменился — журнал не усечён или есть зависшая транзакция

DBCC SQLPERF(LOGSPACE)

Норма

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

Тревожный признак

Использование снова быстро растёт — нет бэкапов журнала при модели Full

log_reuse_wait_desc в sys.databases

Норма

NOTHING или CHECKPOINT

Тревожный признак

LOG_BACKUP, ACTIVE_TRANSACTION или REPLICATION — усечение заблокировано

Работа пользователей 1С

Норма

База доступна, документы проводятся без ошибок

Тревожный признак

Ошибки доступа к базе — проверьте состояние базы в sys.databases

Итоговая последовательность для типовой базы 1С проста: полный бэкап, перевод в модель Simple (или бэкап журнала для Full), CHECKPOINT, DBCC SHRINKFILE, настройка профилактики. Вся операция на базе среднего размера занимает минуты, но требует дисциплины: сначала резервная копия, потом всё остальное.

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

Можно ли просто удалить файл LDF, если он занял весь диск?

Нет. Удаление или переименование LDF в обход SQL Server переводит базу в состояние SUSPECT, и подключить её обратно штатными средствами может не получиться. Даже аварийный режим EMERGENCY с перестроением журнала — крайняя мера с риском потери данных. Правильный путь — усечение журнала и shrink через SQL Server.

Насколько сильно можно сжать файл журнала?

До размера активной части журнала — команда DBCC SHRINKFILE не удалит данные незавершённых транзакций. На практике после усечения файл обычно сжимается до нескольких сотен мегабайт. Задавать целевой размер меньше реальной рабочей нагрузки бессмысленно: файл просто вырастет обратно при ближайшей тяжёлой операции.

Нужно ли останавливать работу пользователей 1С на время сжатия?

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

Файл LDF снова вырос через неделю после сжатия. Что не так?

Значит, не устранена причина. Проверьте модель восстановления: если база в Full и бэкапы журнала не настроены, рост неизбежен. Либо в базе регулярно выполняются тяжёлые операции (перепроведения, обмены), и нужно либо смириться с рабочим размером журнала, либо перевести базу в Simple.

Влияет ли сжатие журнала на данные в базе 1С?

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

Какой размер LDF считать нормальным для базы 1С?

Универсальной нормы нет: размер определяется пиковой транзакционной нагрузкой. Ориентир — размер журнала после усечения плюс запас на самую тяжёлую регламентную операцию. Если при модели Simple журнал стабильно держится в пределах 5–15% от размера MDF, это нормальная рабочая ситуация.