Как очистить лог-файл SQL базы 1С

Лог-файл журнала транзакций (LDF) базы 1С на SQL Server имеет свойство разрастаться до десятков и сотен гигабайт, особенно если база работает в модели восстановления Full, а резервное копирование журнала не настроено. Когда диск заполняется, SQL Server не может записывать новые транзакции, и пользователи 1С получают ошибки при проведении документов или вообще не могут войти в базу.

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

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

Почему лог-файл базы 1С разрастается

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

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

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

Что сделать до очистки: обязательная подготовка

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

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

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

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

Графический способ подходит тем, кто редко работает с SQL Server и не хочет писать запросы вручную. Все действия выполняются в SQL Server Management Studio под учётной записью с правами администратора сервера (sysadmin) или владельца базы.

Порядок такой: откройте свойства базы, перейдите на страницу Options и установите Recovery model в значение Simple. Подтвердите изменение. Затем щёлкните по базе правой кнопкой, выберите Tasks → Shrink → Files, в поле File type укажите Log, оставьте действие по умолчанию (Release unused space) и нажмите OK.

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

1. 1
   Сделайте полную резервную копию базы
2. 2
   Откройте свойства базы → Options → Recovery model → Simple
3. 3
   Правой кнопкой по базе: Tasks → Shrink → Files → File type: Log → OK
4. 4
   Проверьте размер LDF-файла на диске
5. 5
   При необходимости верните модель Full и снова сделайте полный бэкап

Способ 2: очистка лог-файла через T-SQL

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

Обратите внимание: в DBCC SHRINKFILE указывается логическое имя файла журнала, а не путь на диске. Узнать его можно запросом к sys.database_files — в выводе нужен столбец name для строки с типом LOG. Часто логическое имя совпадает с именем базы с суффиксом _log, но полагаться на это не стоит.

ALTER DATABASE [MyBase1C] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (N'MyBase1C_log', 1024);
GO
ALTER DATABASE [MyBase1C] SET RECOVERY FULL;
GO

Второй параметр SHRINKFILE — целевой размер в мегабайтах. Указывать ноль не рекомендуется: журналу нужен минимальный рабочий объём, и слишком агрессивное сжатие приведёт к тому, что файл сразу начнёт расти заново с накладными расходами на авторасширение. Разумный ориентир — 1–2 ГБ для средней базы.

Что делать, если файл не уменьшается

Самая частая ситуация после SHRINKFILE — операция завершилась успешно, но размер файла не изменился. Это значит, что активная часть журнала расположена в конце файла, и усечь его нельзя, пока эта часть не освободится. В модели Simple помогает выполнить команду CHECKPOINT и повторить сжатие, иногда два-три раза подряд.

Если не помогает, снова проверьте log_reuse_wait_desc в sys.databases. Значение ACTIVE_TRANSACTION указывает на зависшую транзакцию — её сеанс нужно найти и завершить штатно (в идеале — попросить пользователя выйти из 1С, принудительный KILL оставить как крайнюю меру). Значение REPLICATION или AVAILABILITY_REPLICA означает, что журнал удерживают механизмы репликации или Always On, и сначала нужно разбираться с ними.

Как не допустить повторного роста журнала

Усечение разово решает проблему места, но без профилактики журнал вырастет снова — вопрос лишь времени. Выбор стратегии зависит от требований к восстановлению данных.

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

Если потеря данных даже за несколько часов недопустима, оставьте модель Full, но обязательно настройте регулярное резервное копирование журнала транзакций — например, каждые 15–60 минут через план обслуживания или агент SQL Server. Каждый такой бэкап освобождает неактивную часть журнала, и файл держится в разумных пределах. Дополнительно контролируйте свободное место на диске и размеры файлов, чтобы заметить аномальный рост до заполнения диска.

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