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

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

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

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

Почему LDF-файл базы 1С разрастается

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

Типичная ситуация: базу 1С развернули из бэкапа или создали с настройками по умолчанию, модель осталась Full, а план обслуживания с копиями журнала никто не настроил. Каждая транзакция — проведение документа, запись элемента справочника — добавляет записи в LDF. За месяцы активной работы файл может превысить размер самой базы в несколько раз.

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

Что проверить перед сжатием

Сначала узнайте текущую модель восстановления. В SQL Server Management Studio (SSMS) откройте свойства базы, вкладка Options — поле Recovery model. Либо выполните запрос: SELECT name, recovery_model_desc FROM sys.databases;. От этого зависит вся дальнейшая стратегия.

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

Проверьте, что мешает усечению журнала: SELECT name, log_reuse_wait_desc FROM sys.databases;. Значение LOG_BACKUP означает, что нужен бэкап журнала. ACTIVE_TRANSACTION — есть незавершённая транзакция, возможно, зависший сеанс 1С. REPLICATION или AVAILABILITY_REPLICA — журнал удерживается механизмами репликации, и сжимать его без разбора с ними опасно.

Вариант 1: перевод базы в модель восстановления Simple

Для большинства баз 1С, где достаточно ежедневных полных бэкапов и восстановление «на любой момент времени» не требуется, оптимальный вариант — модель Simple. В ней журнал усекается автоматически, и проблема роста LDF исчезает навсегда. Это стандартная практика для типовых учётных баз 1С.

Порядок действий: сделайте полную резервную копию базы (обязательно — смена модели разрывает цепочку восстановления), затем в свойствах базы в SSMS установите Recovery model = Simple, либо выполните команду. После переключения журнал усечётся при ближайшей контрольной точке, и его можно сжать.

ALTER DATABASE [MyBase1C] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (N'MyBase1C_log', 1024);
GO

В команде DBCC SHRINKFILE второй параметр — целевой размер файла в мегабайтах. Ставить 1 МБ не стоит: при первой же активной работе журнал снова начнёт расти, а автоприращение — дорогая операция, вызывающая паузы. Разумный ориентир — размер, достаточный для пиковых операций: для небольших баз 1–2 ГБ, для крупных с массовыми обработками — 10–20% от размера данных.

Вариант 2: бэкап журнала при модели Full

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

Важно понимать: бэкап журнала усекает его логически, но не уменьшает физический файл на диске. Без DBCC SHRINKFILE LDF так и останется огромным, просто пустым внутри. Поэтому последовательность всегда одна: бэкап лога → shrink.

Чтобы проблема не вернулась, настройте регулярные копии журнала — например, каждые 30–60 минут через план обслуживания или задание SQL Server Agent. Частота определяет, сколько данных вы готовы потерять при сбое: при копиях раз в час максимальные потери — час работы.

Непосредственное сжатие LDF-файла

Через SSMS: правый клик по базе → Tasks → Shrink → Files. В поле File type выберите Log, оставьте действие по умолчанию (Release unused space) или укажите целевой размер через Reorganize pages. Нажмите OK и дождитесь завершения — на больших файлах операция может занять заметное время.

Через T-SQL управление точнее. Сначала узнайте логическое имя файла журнала: SELECT name FROM sys.database_files WHERE type_desc = 'LOG';. Затем выполните DBCC SHRINKFILE (N'имя_файла', целевой_размер_МБ);. Если сжатие прошло, но размер почти не изменился — активная часть журнала находится в конце файла; помогает повторное выполнение усечения (бэкапа лога или checkpoint) и повторный shrink.

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

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

Настройка автоприращения и профилактика роста

После сжатия задайте осмысленные параметры автоприращения LDF. Значение по умолчанию в процентах или 1 МБ приводит к частым мелким приращениям и фрагментации файла. Рекомендуется фиксированный шаг — например, 512 МБ или 1 ГБ для активных баз. Мгновенная инициализация файлов (instant file initialization) для журналов не работает, поэтому каждое приращение журнала — это реальное обнуление места на диске и пауза в работе.

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

Контролируйте свободное место на диске с LDF мониторингом. Заполнение диска под журнал приводит к ошибке 9002 и остановке всех записей в базу — пользователи 1С не смогут провести ни один документ. Пороговое оповещение при 15–20% свободного места даёт время отреагировать штатно.

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

Самая опасная ошибка — удаление LDF-файла средствами Windows при остановленной службе SQL Server. Без журнала база не открывается штатно, и придётся применять аварийные режимы восстановления с риском потери данных. Вторая распространённая ошибка — сжатие без устранения причины: файл уменьшили, а модель Full без бэкапов лога оставили, и через две недели диск снова полон.

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