Журнал транзакций базы 1С на MS SQL съел диск: возвращаем место без потери данных

Чтобы очистить лог-файл SQL базы 1С, сначала сделайте резервную копию журнала командой BACKUP LOG, а затем сожмите файл .ldf командой DBCC SHRINKFILE. Если журнал вам не нужен для восстановления на момент времени, проще перевести базу в модель восстановления SIMPLE, выполнить CHECKPOINT и тот же SHRINKFILE. Удалять файл .ldf вручную нельзя: база перейдёт в состояние RECOVERY_PENDING или SUSPECT, и 1С перестанет к ней подключаться.

Частое заблуждение — считать, что SQL Server сам чистит журнал, если в нём «ничего важного». В модели FULL место внутри журнала освобождается только после бэкапа журнала. Нет таких бэкапов — файл растёт, пока не займёт весь диск.

Почему лог базы 1С растёт до десятков гигабайт

Файл журнала транзакций (.ldf) хранит все изменения данных до тех пор, пока они не станут ненужными для восстановления. Когда именно запись «становится ненужной», решает модель восстановления базы.

Основные причины разрастания:

• 📦 Модель FULL без бэкапов журнала. Самый частый случай. База, созданная из консоли кластера 1С, наследует настройки системной базы model, а в редакциях Standard и Enterprise там по умолчанию стоит FULL. Полные бэкапы журнал не усекают.
• ⏳ Долгая открытая транзакция. Пока транзакция не завершена, SQL Server не может переиспользовать журнал после её начала. В 1С это бывает при зависшем сеансе, долгой обработке или фоновом задании.
• 🔄 Массовые операции 1С. Обновление конфигурации базы данных с реструктуризацией, загрузка .dt, свёртка базы, перепроведение документов за год, закрытие месяца в крупной базе. Каждая из них может за час записать в журнал десятки гигабайт.
• 📈 Автоприращение по 10%. На большом файле каждый шаг роста становится огромным, а журнал дробится на множество виртуальных файлов (VLF), что замедляет запуск базы и бэкапы.
• 🔗 Репликация или группа доступности. Если база участвует в Always On или репликации, а реплика отстала, журнал держится до её синхронизации.

Диагностика: что держит журнал и сколько в нём пустого места

Прежде чем что-то сжимать, узнайте, сколько места занято внутри файла и почему SQL Server не может его переиспользовать. Иначе сожмёте файл, а через день он снова вырастет.

Размер и заполненность журнала

Откройте SQL Server Management Studio (SSMS), подключитесь к серверу и выполните запрос в окне New Query:

DBCC SQLPERF(LOGSPACE);

В результате для каждой базы видно Log Size (MB) и Log Space Used (%). Если файл занимает 80 ГБ, а заполнен на 3%, — место можно вернуть сразу. Если заполнен на 99%, сначала надо освободить его изнутри.

Тот же результат даёт графический отчёт: правый клик по базе → Reports → Standard Reports → Disk Usage.

Причина, по которой журнал не усекается

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
WHERE name = N'buh_base';

Подставьте имя своей базы вместо buh_base. Колонка log_reuse_wait_desc прямо отвечает на вопрос «что мешает»:

Имя логического файла журнала

Для команды сжатия нужно логическое имя файла, а не путь на диске:

USE buh_base;
SELECT name, type_desc, physical_name, size * 8 / 1024 AS size_mb
FROM sys.database_files;

Строка с type_desc = LOG — ваш журнал. У баз, созданных через консоль 1С, имя обычно имеет вид buh_base_log, но лучше проверить.

Способ 1. Бэкап журнала и сжатие без смены модели

Этот путь сохраняет цепочку бэкапов и возможность восстановиться на любую минуту. Его выбирают, если база в FULL осталась сознательно и вы не хотите терять точку восстановления.

1. Сделайте полный бэкап, если его ещё не было ни разу. Без полного бэкапа BACKUP LOG вернёт ошибку.
2. Сделайте бэкап журнала:

BACKUP LOG buh_base
TO DISK = N'D:\SQLBackup\buh_base_log.trn'
WITH COMPRESSION;

3. Проверьте DBCC SQLPERF(LOGSPACE): процент занятости должен упасть.
4. Сожмите файл до разумного размера (в примере — 2048 МБ):

USE buh_base;
DBCC SHRINKFILE (N'buh_base_log', 2048);

Если после первого прохода файл уменьшился слабо, активная часть журнала сидит в его конце. Сделайте ещё один BACKUP LOG и повторите SHRINKFILE — обычно хватает двух-трёх итераций.

Через SSMS то же самое: правый клик по базе → Tasks → Back Up…, тип бэкапа Transaction Log. Затем Tasks → Shrink → Files, в поле File type выберите Log, отметьте вариант с освобождением неиспользуемого места и укажите целевой размер в мегабайтах. Окно сразу показывает, сколько процентов файла свободно.

Способ 2. Перевод базы 1С в модель Simple

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

1. Сделайте полный бэкап базы средствами SQL или выгрузку .dt из Конфигуратора. Если диск заполнен на 100%, бэкап кладите на другой диск или сетевую папку.
2. Переключите модель восстановления:

ALTER DATABASE buh_base SET RECOVERY SIMPLE;

3. Принудительно запишите контрольную точку:

USE buh_base;
CHECKPOINT;

4. Сожмите журнал:

DBCC SHRINKFILE (N'buh_base_log', 1024);

В SSMS модель меняют так: правый клик по базе → Properties → страница Options → поле Recovery model → Simple → OK.

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

Почему не стоит сжимать «в ноль»

Команда DBCC SHRINKFILE (N'buh_base_log', 0) или целевой размер 1 МБ сожмут файл до минимума. Но уже утром пользователи 1С начнут работу, журнал станет расти маленькими шагами, и каждый шаг — пауза в записи. Оставьте запас: для базы бухгалтерии на 20–50 ГБ разумно 1–4 ГБ журнала, для базы на 200 ГБ — 8–16 ГБ.

Способ 3. Когда журнал не сжимается

Иногда SHRINKFILE отрабатывает без ошибок, а файл остаётся прежнего размера. Типовые ситуации:

В старых статьях советуют BACKUP LOG … WITH TRUNCATE_ONLY или бэкап журнала в устройство NUL. Первый вариант удалён из SQL Server начиная с версии 2008. Второй работает, но фактически выбрасывает бэкап и рвёт цепочку так же, как переход в SIMPLE, только незаметно для администратора. Делать так не стоит.

Возврат в Full и настройка резервного копирования журнала

Если после чистки база должна жить в FULL, верните модель и сразу начните новую цепочку бэкапов:

ALTER DATABASE buh_base SET RECOVERY FULL;

BACKUP DATABASE buh_base
TO DISK = N'D:\SQLBackup\buh_base_full.bak'
WITH COMPRESSION, CHECKSUM;

Пока не сделан полный бэкап, база в FULL ведёт себя как в SIMPLE, и восстановиться на минуту не получится. Поэтому полный бэкап — обязательная часть возврата, а не опция.

Дальше настройте регулярные бэкапы журнала. Частота зависит от того, сколько работы вы готовы потерять:

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

В SSMS это делают через Management → Maintenance Plans (мастер Maintenance Plan Wizard) или отдельными заданиями в SQL Server Agent → Jobs. В плане обслуживания добавьте задачу Back Up Database Task с типом Transaction Log и задачу очистки старых файлов .trn, чтобы бэкапы не заполнили уже другой диск.

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

Сжатие лечит симптом. Чтобы журнал не вырос снова, нужен режим, при котором место внутри файла переиспользуется.

Правильное автоприращение

Замените прирост в процентах на фиксированный размер. Для журнала баз 1С среднего размера подходит шаг 512–1024 МБ:

ALTER DATABASE buh_base
MODIFY FILE (NAME = N'buh_base_log', FILEGROWTH = 512MB);

То же в SSMS: Properties → Files, кнопка с многоточием в колонке Autogrowth / Maxsize у файла журнала.

Мониторинг и разовые операции

• 🔍 Раз в неделю смотрите DBCC SQLPERF(LOGSPACE) или настройте оповещение SQL Server Agent на заполнение журнала выше 70–80%.
• 💾 Держите журнал на отдельном диске от файла данных и системы: переполнение журнала тогда не остановит ОС и другие базы.
• 🛠 Перед обновлением конфигурации с реструктуризацией, загрузкой .dt или свёрткой базы проверьте свободное место. На время такой операции допустимо перевести базу в SIMPLE, а после неё вернуть FULL с полным бэкапом.
• 🔢 Если журнал раздроблен на тысячи VLF, сожмите его до минимума один раз и сразу задайте нужный размер одним шагом. Число VLF в SQL Server 2016 SP2 и новее показывает SELECT COUNT(*) FROM sys.dm_db_log_info(DB_ID(N'buh_base'));.

Не ставьте SHRINKFILE журнала в регулярное задание по расписанию. Ежедневное сжатие только заставляет файл расти заново, дробит его и нагружает диск. Сжимают журнал разово, после аварии или крупной операции.

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