1С и SQL Server: как очистить лог базы данных

База 1С на SQL Server со временем может «съесть» всё свободное место на диске не из-за самих данных, а из-за журнала транзакций — файла с расширением .ldf. Этот лог фиксирует каждую операцию изменения данных, и при модели восстановления Full он растёт неограниченно, пока администратор не настроит резервное копирование журнала или не сменит модель восстановления. Типичная картина: диск заполнен, 1С перестаёт запускаться, пользователи видят ошибки соединения с СУБД.

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

Ниже разобраны практические способы очистки лога: через SQL Server Management Studio и через T-SQL, а также настройка, которая не даст проблеме повториться. Инструкции применимы к базам 1С:Предприятие 8.x, развёрнутым на Microsoft SQL Server любой актуальной версии.

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

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

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

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

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

Первое действие — узнать текущую модель восстановления. Откройте SQL Server Management Studio, найдите базу, щёлкните правой кнопкой, выберите «Свойства» → «Параметры» (Options) и посмотрите поле «Модель восстановления» (Recovery model). Это же можно сделать запросом: SELECT name, recovery_model_desc FROM sys.databases;

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

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

Быстрый способ: Simple-модель и сжатие журнала через SSMS

Это стандартный сценарий для большинства баз 1С, где не требуется восстановление на произвольный момент времени. Выполняется через графический интерфейс Management Studio за несколько минут.

1. 1
   Сделайте полную резервную копию базы: правый клик по базе → Задачи → Создать резервную копию
2. 2
   Откройте Свойства базы → Параметры и установите модель восстановления «Простая» (Simple), нажмите ОК
3. 3
   Правый клик по базе → Задачи → Сжать → Файлы
4. 4
   В поле «Тип файла» выберите «Журнал» (Log)
5. 5
   Оставьте действие по умолчанию (освободить неиспользуемое пространство) и нажмите ОК
6. 6
   Проверьте размер файла .ldf на диске — он должен уменьшиться до минимального

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

Если сжатие не дало эффекта и файл остался большим, значит в журнале есть активная часть, которую нельзя усечь прямо сейчас: незавершённая транзакция, отложенная операция или репликация. Проверить причину можно запросом SELECT log_reuse_wait_desc FROM sys.databases WHERE name = 'ИмяБазы'; — значение ACTIVE_TRANSACTION указывает на открытую транзакцию, LOG_BACKUP — на необходимость бэкапа журнала.

Очистка лога через T-SQL

Те же действия удобно выполнять скриптом — особенно когда баз много или операцию нужно повторять регулярно. Скрипт ниже переводит базу в Simple, сжимает журнал и при необходимости возвращает Full.

ALTER DATABASE [MyBase1C] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (N'MyBase1C_log', 1024);
GO
-- Если нужна полная модель — вернуть и сразу сделать бэкап:
-- ALTER DATABASE [MyBase1C] SET RECOVERY FULL;
-- BACKUP DATABASE [MyBase1C] TO DISK = 'D:\Backup\MyBase1C_full.bak';

В команде DBCC SHRINKFILE первый параметр — логическое имя файла журнала (его можно посмотреть в свойствах базы на вкладке «Файлы» или запросом SELECT name FROM sys.database_files WHERE type_desc = 'LOG';), второй — целевой размер в мегабайтах. Указывайте разумный минимум, например 512–2048 МБ: слишком маленький журнал будет постоянно авторасширяться при работе 1С, а каждое расширение — это паузы в производительности.

Если база должна остаться в модели Full, альтернатива смене модели — сделать резервную копию журнала (BACKUP LOG ... TO DISK) и затем сжать файл. Так цепочка бэкапов не разрывается. Но если копии журнала вам не нужны, проще и надёжнее оставить Simple.

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

Разовая очистка решает симптом, но не причину. Чтобы ситуация не повторилась, определитесь со стратегией восстановления и настройте её под неё.

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

При модели Full обязательно создайте задание агента SQL Server (или план обслуживания) для регулярного бэкапа журнала. Именно копия журнала освобождает его пространство — без неё даже ежедневный полный бэкап не остановит рост файла .ldf. Заодно настройте авторасширение файла журнала фиксированным шагом (например, 512 МБ) вместо процентного, чтобы рост был предсказуемым.

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

Отдельно стоит предостеречь от популярного «совета» из старых форумов — использовать BACKUP LOG ... WITH NO_LOG или TRUNCATE_ONLY. В современных версиях SQL Server эти параметры удалены, а их смысл (усечь журнал без копии) теперь корректно реализуется только через перевод базы в Simple.

Проверка результата

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

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

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