Журнал транзакций базы 1С занял весь диск: сжимаем LDF и не даём ему расти

Чтобы уменьшить LDF файл базы 1С, сначала освободите место внутри журнала, а потом сожмите сам файл. В модели восстановления FULL это делает резервная копия журнала транзакций, в SIMPLE — обычная контрольная точка. Затем выполните DBCC SHRINKFILE для логического имени журнала или в SQL Server Management Studio выберите Задачи → Сжать → Файлы с типом файла «Журнал».

Способа два, и выбирают их по ситуации. Через SSMS удобно, если база одна и нужно разово освободить диск. Команды T-SQL удобнее, когда баз на сервере 1С:Предприятия десятки, когда нужна точная цель по размеру или сжатие надо поставить в регламентное задание. Но без настройки модели восстановления и автоприращения журнал за месяц снова разрастётся до сотен гигабайт.

Откуда берётся раздутый LDF у базы 1С

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

Главная причина роста у баз 1С:

• 📌 Модель восстановления FULL без резервных копий журнала. Когда базу создают из консоли кластера 1С, SQL Server берёт настройки системной базы model. В редакциях Standard и Enterprise у model по умолчанию стоит FULL. Записи журнала в этой модели освобождаются только после BACKUP LOG. Если такой копии никто не делает, журнал растёт бесконечно.
• 🔄 Длинные транзакции. Обновление конфигурации с реструктуризацией таблиц, загрузка .dt, удаление помеченных объектов, закрытие месяца в большой базе, пересчёт итогов. Пока транзакция не завершена, её записи держат журнал.
• 🧱 Перестроение индексов в плане обслуживания. Операция REBUILD в модели FULL полностью логируется. На базе 1С объёмом 200 ГБ одна ночь перестроения легко добавляет к журналу 100–150 ГБ.
• 🔗 Репликация, зеркалирование, группы доступности Always On. Журнал не освободится, пока записи не переданы на вторую сторону.
• 📈 Автоприращение в процентах. При шаге 10% файл в 100 ГБ прирастает сразу на 10 ГБ, и такой «запас» остаётся навсегда.

Что проверить до сжатия журнала транзакций

Сжимать вслепую бессмысленно. Если причина не устранена, через неделю файл вернётся к прежнему размеру. Сначала три запроса в SSMS (кнопка «Создать запрос» на подключении к серверу).

Сколько места внутри журнала реально занято:

DBCC SQLPERF(LOGSPACE);

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

Что держит журнал и какая модель восстановления у каждой базы:

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
ORDER BY name;

Значения log_reuse_wait_desc, которые встречаются чаще всего:

Логическое имя файла журнала (оно понадобится для команды сжатия):

USE [buh_2024];
SELECT name, type_desc, physical_name, size / 128 AS size_mb
FROM sys.database_files;

Здесь buh_2024 — имя базы на SQL Server. Оно задано в параметрах информационной базы в консоли кластера и может не совпадать с именем базы в списке запуска 1С.

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

Способ 1. Уменьшить LDF через SQL Server Management Studio

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

Шаг 1. Освободите место внутри журнала

Если модель FULL и нужна точка-в-время, сделайте копию журнала:

1. Щёлкните базу правой кнопкой → Задачи → Создать резервную копию.
2. В поле «Тип резервной копии» выберите «Журнал транзакций».
3. Укажите путь к файлу .trn на диске, где есть место, и нажмите «ОК».

Если копии журнала вам не нужны, переведите базу в SIMPLE: свойства базы → страница «Параметры» → «Модель восстановления» → «Простая». Записи журнала освободятся на ближайшей контрольной точке.

Шаг 2. Сожмите файл журнала

1. Правой кнопкой по базе → Задачи → Сжать → Файлы.
2. «Тип файла» — «Журнал». Убедитесь, что в поле «Имя файла» стоит файл с окончанием _log, а не основной файл данных.
3. В блоке «Действие сжатия» выберите «Реорганизовать страницы перед освобождением неиспользуемого места» и задайте «Сжать файл до» в мегабайтах, например 2048.
4. Нажмите «ОК» и обновите сведения о файле: размер в проводнике Windows должен уменьшиться.

Способ 2. Сжатие LDF командами T-SQL

Скрипт делает то же самое, что SSMS, но быстрее и без риска промахнуться галочкой.

Вариант для модели FULL с копиями журнала

USE [buh_2024];
BACKUP LOG [buh_2024] TO DISK = N'E:\Backup\buh_2024_log.trn';
DBCC SHRINKFILE (N'buh_2024_log', 2048);

Второй аргумент SHRINKFILE — целевой размер в мегабайтах. Если с первого раза файл не дошёл до цели, повторите пару «копия журнала + сжатие» ещё раз: сжать можно только до последней активной части журнала, а после копии она смещается в начало файла.

Вариант, когда копии журнала не нужны

USE [master];
ALTER DATABASE [buh_2024] SET RECOVERY SIMPLE;
GO
USE [buh_2024];
CHECKPOINT;
DBCC SHRINKFILE (N'buh_2024_log', 2048);

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

Сразу для всех баз 1С на сервере

На сервере с десятком баз удобно сначала посмотреть, кто занимает место:

SELECT DB_NAME(database_id) AS db, name, size / 128 AS size_mb
FROM sys.master_files
WHERE type_desc = 'LOG'
ORDER BY size DESC;

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

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

Модель восстановления определяет, нужен ли вам вообще большой журнал.

Для типичной бухгалтерии на 5–20 пользователей SIMPLE плюс ежедневная полная копия — нормальный выбор. Если выбрали FULL, настройте план обслуживания: полная копия раз в сутки и копия журнала каждые 15–60 минут. Тогда журнал будет переиспользовать одно и то же место и держаться в разумном размере.

Чтобы новые базы 1С не создавались с FULL, поменяйте модель у системной базы model:

ALTER DATABASE [model] SET RECOVERY SIMPLE;

Уже существующие базы это не затронет.

Настройка размера и автоприращения журнала

После сжатия задайте журналу разумный стартовый размер и фиксированный шаг роста. Свойства базы → страница «Файлы» → в строке файла журнала колонка «Автоувеличение / максимальный размер» → кнопка с многоточием.

Ориентиры для баз 1С:

• 📏 Начальный размер журнала — примерно 10–25% от размера данных, но не меньше 1–2 ГБ. Для базы 50 ГБ это 5–10 ГБ.
• ➕ Шаг роста — фиксированный, в мегабайтах: 256–1024 МБ. Проценты не ставьте.
• 🚧 Максимальный размер — ограничьте, если журнал лежит на одном диске с базами. Лучше получить ошибку переполнения журнала в одной базе, чем остановку всех баз из-за заполненного тома.

То же самое командой:

ALTER DATABASE [buh_2024]
MODIFY FILE (NAME = N'buh_2024_log', SIZE = 8192MB, FILEGROWTH = 512MB);

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

Файл LDF не уменьшается: разбор причин

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

Если DBCC OPENTRAN показал сеанс, который висит часами, сначала найдите его в консоли кластера 1С по пользователю и времени. Завершение сеанса откатит всю его транзакцию: незаписанные данные пользователя пропадут, а откат большой транзакции может идти долго и сам писать в журнал. Делайте это вне рабочего времени или после согласования с пользователем.

Ещё одна неочевидная причина — тысячи виртуальных файлов журнала (VLF) после многолетнего роста по 10%. Количество проверяют так (SQL Server 2016 SP2 и новее):

SELECT COUNT(*) AS vlf_count
FROM sys.dm_db_log_info(DB_ID(N'buh_2024'));

Если там несколько тысяч, сожмите журнал до минимума, а затем одним действием задайте ему нужный размер через MODIFY FILE. Число VLF упадёт до десятков, а восстановление базы после сбоя ускорится.

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