Как уменьшить лог транзакций SQL в базе 1С

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

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

Материал ориентирован на администраторов 1С, работающих с MS SQL Server. Описанные действия выполняются через SQL Server Management Studio (SSMS) или запросы T-SQL и требуют прав sysadmin или db_owner на базу.

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

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

Вторая типичная причина — длинные транзакции. Массовая загрузка данных, перепроведение документов за длительный период, регламентные операции обмена — всё это удерживает активную часть журнала, и SQL Server не может переиспользовать место внутри файла. Третья причина — репликация, Always On или отложенные процессы, которые удерживают лог до подтверждения передачи.

Отдельно стоит упомянуть параметр автороста. Если для LDF задан прирост в процентах (например, 10%), то при большом файле каждое расширение добавляет гигабайты за раз и замедляет работу. Абсолютный прирост фиксированным размером предсказуемее.

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

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

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

Если в колонке log_reuse_wait_desc стоит LOG_BACKUP — проблема в отсутствии бэкапов журнала. Если ACTIVE_TRANSACTION — найдите виновника запросом к sys.dm_tran_active_transactions и sys.dm_exec_sessions: длительную транзакцию либо дождитесь завершения, либо завершите сессию, предварительно убедившись, что это не критичный процесс обмена.

Дополнительно проверьте текущее заполнение лога командой DBCC SQLPERF(LOGSPACE) — она покажет размер каждого журнала и процент использования. Если файл занимает 100 ГБ, а использовано 2%, сжатие пройдёт быстро и эффективно. Если использовано 95% — сначала нужно освободить активную часть, иначе shrink ничего не даст.

Быстрое сжатие через модель Simple

Для большинства баз 1С, где не требуется восстановление на произвольный момент времени, оптимальна модель восстановления Simple. В ней SQL Server автоматически очищает неактивную часть журнала после checkpoint, и лог не растёт сверх реальной потребности.

Последовательность безопасного сжатия: сделайте полную резервную копию базы, переведите модель восстановления в Simple, выполните CHECKPOINT и сожмите файл:

ALTER DATABASE [ИмяБазы1С] SET RECOVERY SIMPLE;
GO
USE [ИмяБазы1С];
GO
CHECKPOINT;
GO
DBCC SHRINKFILE (N'ИмяЛогическогоФайлаЛога', 1024);
GO

Логическое имя файла лога смотрите в sys.database_files (столбец name, type_desc = 'LOG'). Второй параметр SHRINKFILE — целевой размер в мегабайтах; разумно указать 1024–4096 МБ в зависимости от интенсивности работы базы. Не ставьте слишком маленькое значение: файл всё равно вырастет при ближайшей массовой операции, а частый авторост фрагментирует лог.

1. 1
   Сделайте полную резервную копию базы и убедитесь, что файл бэкапа читается
2. 2
   Выполните запрос к sys.databases и определите log_reuse_wait_desc
3. 3
   Устраните причину удержания: дождитесь транзакции или переключите модель в Simple
4. 4
   Выполните CHECKPOINT в контексте базы
5. 5
   Выполните DBCC SHRINKFILE для LDF с целевым размером 1–4 ГБ
6. 6
   Проверьте результат через DBCC SQLPERF(LOGSPACE) и настройте обслуживание

Сжатие лога при модели Full

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

BACKUP LOG [ИмяБазы1С] TO DISK = 'D:\Backups\log_backup.trn';
GO
USE [ИмяБазы1С];
DBCC SHRINKFILE (N'ИмяЛогическогоФайлаЛога', 2048);
GO

Иногда одного бэкапа лога недостаточно: активная часть журнала находится в конце файла, и shrink освобождает мало места. В таком случае выполните резервное копирование журнала дважды подряд и повторите сжатие. Это штатное поведение, связанное с циклической структурой виртуальных файлов журнала (VLF).

Обязательно настройте регулярное расписание бэкапов лога — например, каждые 15–60 минут в зависимости от допустимой потери данных. Без этого мероприятия лог в модели Full вырастет снова, и вся операция потеряет смысл.

Настройка профилактики: чтобы лог не рос снова

Разовое сжатие — это устранение симптома. Чтобы проблема не вернулась, настройте три вещи: модель восстановления, расписание бэкапов и параметры автороста.

Для баз 1С без требований point-in-time восстановления оставьте модель Simple и настройте ежедневные полные бэкапы плюс дифференциальные копии в течение дня. Для модели Full — обязательное резервное копирование журнала по расписанию через план обслуживания (Maintenance Plan) или задание SQL Server Agent.

Параметры автороста задайте в свойствах базы (SSMS → База данных → Свойства → Файлы): для LDF — фиксированный прирост, например 512–1024 МБ, без ограничения максимального размера либо с разумным лимитом. Процентный прирост для больших файлов — плохая практика: каждое расширение занимает время и блокирует запись в журнал.

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

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

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

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

Третья ошибка — настройка регламентного сжатия по расписанию. Постоянный shrink вызывает цикл «сжал — выросло — сжал», фрагментирует файл на уровне VLF и деградирует производительность дисковой подсистемы. Сжимать лог нужно только после аномального роста, а не по расписанию.

Как проверить результат и контролировать размер лога

После сжатия проверьте фактический размер файла на диске и заполнение журнала командой DBCC SQLPERF(LOGSPACE). Нормальная картина: физический размер LDF соответствует целевому (1–4 ГБ), процент использования колеблется в пределах 10–60% в течение рабочего дня и сбрасывается после checkpoint или бэкапа лога.

Для постоянного контроля настройте мониторинг свободного места на диске с журналами и размера LDF-файлов. Простой вариант — задание SQL Server Agent с запросом к sys.database_files и отправкой уведомления при превышении порога. Это позволит заметить аномальный рост до того, как закончится диск и остановится работа пользователей.

Признак того, что профилактика работает: размер LDF стабилен неделями, а рост происходит только во время плановых массовых операций и возвращается к норме после их завершения (в модели Simple — автоматически, в Full — после бэкапа лога).

Контрольные точки

Как проверить результат

Размер LDF-файла на диске

Норма

Соответствует целевому размеру после shrink

Тревожный признак

Файл не уменьшился — активная часть журнала удерживает место

DBCC SQLPERF(LOGSPACE)

Норма

Использование 10–60%, сбрасывается после checkpoint или бэкапа

Тревожный признак

Использование стабильно выше 90% и растёт

log_reuse_wait_desc

Норма

NOTHING или CHECKPOINT

Тревожный признак

LOG_BACKUP, ACTIVE_TRANSACTION длительное время

Размер лога через неделю

Норма

Стабилен, рост только при массовых операциях

Тревожный признак

Вернулся к исходному объёму — причина не устранена

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

Можно ли просто удалить LDF-файл, если база не нужна в восстановлении?

Нет. Удаление файла журнала при работающем или даже остановленном сервере почти гарантированно приведёт базу в состояние SUSPECT. Восстановление после этого возможно через аварийный режим (EMERGENCY) с перестроением лога, но с риском потери незафиксированных транзакций. Используйте только штатные средства: модель Simple и DBCC SHRINKFILE.

Почему DBCC SHRINKFILE не уменьшает лог?

Активная часть журнала расположена в конце файла, и SQL Server не может освободить занятое место. Проверьте log_reuse_wait_desc: при LOG_BACKUP сделайте бэкап журнала (иногда дважды), при ACTIVE_TRANSACTION найдите и завершите длинную транзакцию. После этого повторите CHECKPOINT и shrink.

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

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

Опасно ли сжатие лога для данных 1С?

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

Какой размер лога считать нормальным для базы 1С?

Универсальной цифры нет: размер зависит от интенсивности записи. Ориентир — лог должен вмещать самую большую типичную транзакцию (например, массовое перепроведение) без автороста. На практике для средних баз это 1–10 ГБ. Если лог стабильно в десятки раз больше размера данных (MDF), это признак проблемы с обслуживанием.

Нужно ли сжимать лог после свёртки базы 1С?

Да, это типичный сценарий: свёртка генерирует огромный объём транзакций, и лог разрастается в разы. После завершения свёртки выполните бэкап, затем CHECKPOINT и DBCC SHRINKFILE до разумного целевого размера. Заодно проверьте и сожмите файл данных, если свёртка освободила значительный объём.