Как почистить лог SQL для базы 1С

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

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

Ниже разобраны рабочие способы уменьшить лог через SQL Server Management Studio и T-SQL, условия выбора модели восстановления, типичные ошибки и профилактика, чтобы ситуация не повторялась.

Почему лог 1С на SQL Server растёт бесконечно

SQL Server поддерживает три модели восстановления: Simple (простая), Full (полная) и Bulk-Logged. В модели Simple журнал автоматически обрезается после контрольных точек, и файл .ldf держится в разумных пределах. В модели Full сервер хранит все транзакции до тех пор, пока не сделана резервная копия журнала — именно это позволяет восстановить базу на любой момент времени.

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

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

Подготовка: что сделать до очистки лога

Перед любыми манипуляциями с журналом сделайте полную резервную копию базы средствами SQL Server. Это единственная страховка, если что-то пойдёт не так: при смене модели восстановления или сбое во время shrink цепочка восстановления может быть нарушена. Бэкап через консоль 1С (выгрузка .dt) не заменяет SQL-бэкап, но как дополнительная копия тоже не помешает.

Проверьте текущее состояние базы. Откройте SQL Server Management Studio, подключитесь к серверу и выполните запрос к системному представлению sys.databases — он покажет модель восстановления и причину, по которой журнал не обрезается. Это займёт минуту, но снимет половину вопросов.

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

Если log_reuse_wait_desc показывает ACTIVE_TRANSACTION, сначала найдите и завершите зависшую транзакцию командой DBCC OPENTRAN и, при необходимости, KILL по номеру сеанса. Пока активная транзакция жива, никакая очистка лога не поможет — обрезать его физически невозможно.

Способ 1: быстрая очистка через модель Simple и сжатие файла

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

1. 1
   Сделайте полный бэкап базы средствами SQL Server
2. 2
   Правой кнопкой по базе → Свойства → Параметры → Модель восстановления → выберите «Простая» (Simple)
3. 3
   Правой кнопкой по базе → Задачи → Сжать → Файлы → выберите тип файла «Журнал» и укажите целевой размер
4. 4
   Нажмите OK и дождитесь завершения сжатия
5. 5
   Проверьте размер файла .ldf на диске и свободное место
6. 6
   Сделайте новый полный бэкап базы после операции

Та же операция через T-SQL выполняется двумя командами: сначала ALTER DATABASE с установкой SIMPLE, затем DBCC SHRINKFILE для логического имени файла журнала. Логическое имя файла смотрите в свойствах базы на вкладке «Файлы» — оно не всегда совпадает с именем файла на диске.

ALTER DATABASE [ИмяБазы1С] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (N'ИмяБазы1С_log', 1024);
GO

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

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

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

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

BACKUP LOG [ИмяБазы1С] TO DISK = 'D:\Backup\ИмяБазы1С_log.trn';
GO
DBCC SHRINKFILE (N'ИмяБазы1С_log', 1024);
GO

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

Для файловых по духу, но серверных по факту баз 1С практика простая: если компания готова потерять данные максимум за день (восстановление из ночного бэкапа), ставьте Simple и забудьте о проблеме лога. Если потери даже часа критичны — Full плюс бэкапы лога каждые 15–60 минут и контроль свободного места под эти бэкапы.

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

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

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

Типичные ошибки при очистке журнала

Отдельно стоит предостеречь от популярного «совета» из форумов — перевода базы в режим AUTO_CLOSE или выполнения shrink по расписанию ежедневно. Постоянные сжатия сильно фрагментируют файлы на диске и внутри базы, что ухудшает производительность. Журнал сжимают один раз до разумного размера, а дальше управляют им через модель восстановления и бэкапы.

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