Как уменьшить файл журнала (LDF) базы 1С на SQL Server

Файл журнала транзакций (LDF) базы 1С на SQL Server часто разрастается до десятков и сотен гигабайт, переполняя диск и останавливая работу пользователей. Причина почти всегда одна: база работает в полной модели восстановления (Full), а резервное копирование журнала транзакций не настроено. Пока лог не очищается бэкапом, SQL Server не может переиспользовать его место и файл только растёт.

Уменьшение LDF — это две разные задачи: сначала освободить место внутри файла (очистить журнал), затем сжать сам файл на диске (shrink). Если выполнить только shrink без очистки, файл либо не уменьшится, либо снова вырастет при первой же интенсивной загрузке данных. Поэтому действовать нужно последовательно и с пониманием модели восстановления базы.

Ниже — практический порядок действий: диагностика, выбор модели восстановления, команды сжатия, настройка регулярного обслуживания и типичные ошибки, которые приводят к потере данных или повторному росту файла.

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

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

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

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

Прежде чем сжимать файл, выясните текущее состояние базы. Выполните в SQL Server Management Studio запрос к представлению sys.database_recovery_status или проще — проверьте модель восстановления в свойствах базы (Options → Recovery model). Заодно посмотрите фактический размер файлов и процент свободного места внутри LDF: если внутри файла свободно 99%, проблема не в очистке, а только в сжатии.

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

Способ 1: перевод базы в простую модель и сжатие

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

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

ALTER DATABASE [MyBase1C] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (N'MyBase1C_log', 1024);
GO
-- при необходимости вернуть полную модель:
-- ALTER DATABASE [MyBase1C] SET RECOVERY FULL;

Имя логического файла журнала (параметр в SHRINKFILE) посмотрите запросом SELECT name FROM sys.database_files WHERE type_desc = 'LOG'; — оно часто отличается от имени файла на диске. Число после имени — целевой размер в мегабайтах; не ставьте его слишком маленьким, иначе файл тут же начнёт автоприращение, что замедляет работу.

Способ 2: сжатие при сохранении полной модели восстановления

Если требования к сохранности данных предполагают восстановление на любой момент времени (например, база финансового учёта с жёстким регламентом), модель Full нужно сохранить. Тогда очистка журнала достигается только резервным копированием лога: BACKUP LOG [MyBase1C] TO DISK = 'D:\Backup\log.trn'; — после него место внутри LDF освобождается и файл можно сжать.

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

1. 1
   Убедитесь в наличии свежего полного бэкапа базы
2. 2
   Выполните BACKUP LOG для журнала транзакций
3. 3
   Выполните DBCC SHRINKFILE для лог-файла с разумным целевым размером
4. 4
   Настройте план обслуживания с регулярным бэкапом лога
5. 5
   Проверьте через день-два, что файл не растёт прежними темпами

Сколько места оставить и как настроить автоприращение

Не стремитесь сжать LDF до минимума. Журнал нужен рабочего размера: для активной базы это обычно 10–25% от размера данных, а на период массовых операций (обновление конфигурации, закрытие месяца) — больше. Если сжать файл до 100 МБ, при первой же интенсивной загрузке SQL Server будет многократно наращивать его, а каждое приращение лога — это обнуление места на диске и пауза в работе пользователей.

Настройте автоприращение фиксированным объёмом в мегабайтах, а не процентами: приращение в процентах на большом файле приводит к огромным разовым расширениям. Для журнала разумны шаги в 512 МБ – 2 ГБ в зависимости от профиля нагрузки. Также убедитесь, что на диске с LDF есть запас свободного места хотя бы под двукратный рост журнала — это защита от остановки базы в пиковые периоды.

Риски и когда остановиться

Сжатие журнала — безопасная операция при соблюдении условий, но есть границы. Никогда не удаляйте файл LDF вручную через проводник и не используйте «отсоединить базу и удалить лог» как способ уменьшения: при повреждённой или не завершившей работу базе это приводит к невозможности присоединить базу обратно. Не применяйте устаревшие приёмы с BACKUP LOG WITH TRUNCATE_ONLY в современных версиях SQL Server — эта опция удалена, а её замена через переключение моделей должна выполняться осознанно.

Остановитесь и привлеките администратора БД, если: база участвует в репликации, Always On, лог-шиппинге или CDC — смена модели восстановления и shrink могут нарушить эти механизмы; журнал не очищается по непонятной причине (проверьте log_reuse_wait_desc в sys.databases); нет ни одной проверенной резервной копии — сначала бэкап, потом любые манипуляции.

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

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

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

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