Как очистить логи 1С в SQL Server

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

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

Что именно растёт: журнал транзакций, а не журнал регистрации

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

Именно LDF-файл вызывает проблемы с диском. Каждая проведённая партия документов, перепроведение месяца, обмен данными — всё это пишет в журнал. Пока журнал не усечён, его внутреннее пространство не переиспользуется, и файл растёт даже при стабильном объёме самих данных.

Как определить причину роста и текущее состояние журнала

Перед очисткой выясните, почему журнал не усекается сам. Выполните запрос к системным представлениям и посмотрите модель восстановления и причину ожидания:

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

Значение log_reuse_wait_desc подскажет причину. LOG_BACKUP означает, что база в полной модели восстановления и ни разу не делался бэкап журнала — самая частая ситуация. ACTIVE_TRANSACTION говорит о зависшей длинной транзакции, REPLICATION или AVAILABILITY_REPLICA — о механизмах репликации, которые держат журнал.

Размер и заполненность журнала проверяется командой DBCC SQLPERF(LOGSPACE) — она показывает размер каждого LDF-файла и процент его использования. Если файл большой, а заполнен на несколько процентов, журнал уже усечён и нужно только сжатие. Если заполнен почти полностью — сначала решайте вопрос усечения.

Способ 1: очистка лога при полной модели восстановления

Полная модель (Full) нужна, когда требуется восстановление базы на произвольный момент времени. В ней журнал усекается только резервным копированием журнала транзакций. Команда выполняется в SQL Server Management Studio или через sqlcmd:

BACKUP LOG [ИмяБазы1С]
TO DISK = 'D:\Backups\log_backup.trn';

После успешного бэкапа журнала неактивная часть освобождается, и можно сжать файл до разумного размера. Имя логического файла смотрите в свойствах базы или через sys.database_files:

DBCC SHRINKFILE (N'ИмяЛогическогоФайла_log', 1024);

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

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

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

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

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

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

Для небольших баз с ежедневным полным бэкапом простая модель — рабочий и часто рекомендуемый вариант. Для крупных баз с требованиями к минимальной потере данных оставайтесь на полной модели и настраивайте регулярные бэкапы журнала с интервалом, например, 15–60 минут.

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

BACKUP LOG + SHRINKFILE

Сохраняет возможность восстановления на момент времени; требует места под файл бэкапа лога и регулярного обслуживания

Перевод в Simple + Shrink

Быстро освобождает диск без бэкапа лога, но разрывает цепочку восстановления и подходит только при допустимости потери данных до последнего бэкапа

Только SHRINKFILE

Почти бесполезен: без усечения журнала файл не сожмётся, а после усечения вырастет снова

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

Разовая очистка не решает проблему, если не устранена причина роста. Основные профилактические меры:

• Настройте регулярный бэкап журнала транзакций при полной модели восстановления — через план обслуживания, задание агента SQL Server или скрипт по расписанию.
• Отключите автосжатие базы (AutoShrink) — оно вызывает фрагментацию и лишнюю нагрузку; сжатие должно быть управляемой операцией.
• Задайте адекватное автоприращение файла журнала в мегабайтах, а не в процентах: приращение в процентах на большом файле приводит к огромным разовым выделениям места.
• Планируйте массовые операции (перепроведение, загрузку данных, обновления конфигурации) с учётом роста журнала — при возможности выполняйте их порциями с бэкапом лога между порциями.
• Контролируйте свободное место на диске с LDF-файлом мониторингом, а не по жалобам пользователей.

Типичные ошибки и ограничения

Самая распространённая ошибка — вера в то, что полный бэкап базы усекает журнал. Это не так: только BACKUP LOG освобождает журнал в полной модели. Вторая ошибка — сжатие журнала до минимума «в ноль»: при первой же интенсивной операции файл вырастет снова, а многократные циклы сжатия-роста фрагментируют файл на диске.

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

Как проверить, что очистка прошла успешно

После всех операций убедитесь в результате тремя контрольными точками. Во-первых, размер LDF-файла на диске уменьшился до целевого значения. Во-вторых, DBCC SQLPERF(LOGSPACE) показывает низкий процент заполнения. В-третьих, база остаётся в состоянии ONLINE, а пользователи 1С работают без ошибок.

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

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

Размер LDF на диске

Норма

Соответствует целевому значению после SHRINKFILE

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

Файл не уменьшился — журнал не усечён, смотрите log_reuse_wait_desc

Состояние базы

Норма

ONLINE, запросы выполняются

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

Suspect или Recovery Pending — требуется восстановление

log_reuse_wait_desc

Норма

NOTHING или CHECKPOINT

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

ACTIVE_TRANSACTION, REPLICATION — причина роста не устранена

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

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

Нет. SQL Server не сможет корректно открыть базу без журнала, и она перейдёт в состояние Suspect или Recovery Pending. Существуют аварийные обходные пути с пересозданием журнала, но они ведут к потере незафиксированных транзакций и возможным нарушениям целостности. Используйте только штатные операции: BACKUP LOG, смену модели восстановления и SHRINKFILE.

Как часто нужно делать бэкап журнала транзакций?

Интервал зависит от допустимой потери данных: чем чаще бэкап лога, тем меньше данных будет утеряно при сбое. Типичная практика для рабочих баз 1С — от 15 минут до 1 часа. Заодно частые бэкапы лога не дают журналу разрастаться, решая исходную проблему.

Почему журнал снова вырос через неделю после сжатия?

Сжатие уменьшает файл, но не мешает ему расти заново, если журнал продолжает наполняться быстрее, чем усекается. Проверьте, настроен ли регулярный BACKUP LOG, нет ли длинных транзакций и массовых операций в расписании (перепроведение, обмены, обновления). Устраните причину — и рост прекратится.

Какую модель восстановления выбрать для базы 1С?

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

Опасно ли сжатие журнала для работающих пользователей?

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

Чем очистка лога SQL отличается от сокращения журнала регистрации 1С?

Журнал регистрации 1С сокращается из конфигуратора (Администрирование → Настройка журнала регистрации → Сократить) и влияет только на историю событий платформы. Это никак не освобождает место, занятое LDF-файлом SQL Server. Это две независимые процедуры, и обе имеет смысл выполнять по отдельным регламентам.