Как уменьшить размер log-файла SQL для базы 1С

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

Уменьшить log-файл можно двумя путями: корректным — через настройку модели восстановления и регламентное обслуживание, и аварийным — через принудительное усечение (shrink). Оба способа описаны ниже с точными командами, условиями применения и рисками. Инструкция подходит для баз 1С:Предприятие 8.x на MS SQL Server 2012 и новее.

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

Почему log-файл 1С растёт и когда это проблема

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

Характерные признаки проблемы: LDF-файл в разы больше MDF, на диске заканчивается место, в журнале ошибок SQL Server появляются сообщения о невозможности расширить файл, пользователи 1С получают ошибки при записи документов. Рост ускоряют массовые операции: перепроведение документов, загрузка данных обработками, обновление конфигурации, реиндексация.

Шаг 1. Проверьте модель восстановления и состояние журнала

Прежде чем что-то сжимать, определите текущую модель восстановления и причину, по которой журнал не переиспользуется. Откройте SQL Server Management Studio (SSMS), подключитесь к серверу и выполните запрос:

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
WHERE name = 'ИмяВашейБазы';

Если recovery_model_desc = FULL, а log_reuse_wait_desc = LOG_BACKUP — журнал ждёт резервного копирования, и у вас два варианта: начать делать бэкапы журнала или перейти на Simple. Если указано ACTIVE_TRANSACTION или ACTIVE_BACKUP_OR_RESTORE — сначала нужно дождаться завершения операции или найти зависший сеанс, shrink в этот момент не даст эффекта.

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

Шаг 2. Выберите модель восстановления под ваши требования

Модель Simple означает, что SQL Server автоматически переиспользует место в журнале после завершения каждой транзакции и контрольной точки. LDF перестаёт расти бесконечно, но восстановить базу можно только на момент последней полной или разностной копии — «откат на 10 минут назад» невозможен.

Модель Full сохраняет возможность восстановления на любой момент времени, но требует регулярных резервных копий журнала (обычно раз в 15–60 минут). Без них Full не даёт никаких преимуществ — только раздувает диск. Выбор зависит от того, насколько критична потеря данных за несколько часов.

Сравнение моделей восстановления

Simple

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

Full + бэкапы журнала

Для баз, где недопустима потеря данных даже за час. Требует настроенного плана обслуживания и места под копии журнала.

Full без бэкапов журнала

Худший вариант: преимуществ нет, а LDF растёт бесконечно. Так базы оказываются после установки «по умолчанию».

Шаг 3. Уменьшите log-файл: два рабочих сценария

Сценарий А: перевод в Simple и shrink

Это стандартный путь для баз 1С без требований к восстановлению на произвольный момент. Сначала сделайте полную резервную копию базы средствами SQL Server или выгрузку DT из конфигуратора — это страховка на случай любой ошибки. Затем выполните команды:

ALTER DATABASE [ИмяВашейБазы] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (N'ИмяЛогическогоФайлаЖурнала', 1024);
GO

Имя логического файла журнала смотрите в свойствах базы: правый клик по базе → Properties → Files, колонка Logical Name у строки с типом Log. Число 1024 — целевой размер в мегабайтах; не ставьте слишком маленькое значение, иначе файл сразу начнёт расти заново с накладными расходами на авторасширение.

Сценарий Б: shrink при сохранении модели Full

Если Full нужно сохранить, порядок другой: сначала резервная копия журнала, затем shrink, затем настройка регулярного расписания бэкапов журнала. Команды:

BACKUP LOG [ИмяВашейБазы]
TO DISK = 'D:\Backup\ИмяВашейБазы_log.trn';
GO
DBCC SHRINKFILE (N'ИмяЛогическогоФайлаЖурнала', 2048);
GO

Иногда одного бэкапа журнала недостаточно — активная часть журнала находится в конце файла, и shrink не освобождает место. В этом случае выполните BACKUP LOG ещё раз и повторите shrink.

1. 1
   Сделайте полную резервную копию базы или выгрузку DT
2. 2
   Проверьте recovery_model_desc и log_reuse_wait_desc
3. 3
   Переведите базу в Simple: ALTER DATABASE ... SET RECOVERY SIMPLE
4. 4
   Выполните DBCC SHRINKFILE для логического файла журнала
5. 5
   Проверьте размер LDF на диске и настройте авторасширение в МБ, а не в процентах
6. 6
   Запланируйте регулярные полные бэкапы базы

Шаг 4. Настройте базу, чтобы журнал не вырос снова

После shrink обязательно проверьте параметры авторасширения: свойства базы → Files → кнопка «...» у файла журнала. Рост в процентах (по умолчанию 10%) на больших файлах приводит к резким скачкам по многу гигабайт и паузам в работе 1С. Установите фиксированный шаг в мегабайтах, соответствующий нагрузке.

Настройте регулярное обслуживание: план обслуживания (Maintenance Plan) в SSMS или задания SQL Server Agent с полным бэкапом ежедневно и, при модели Full, бэкапом журнала каждые 15–60 минут. Без этого шага вся процедура теряет смысл — через месяц вы вернётесь к той же проблеме.

Частые ошибки и риски при уменьшении журнала

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

Вторая распространённая ошибка — выполнить shrink без предварительного бэкапа и без проверки log_reuse_wait_desc. Если в базе висит активная транзакция (например, незавершённое перепроведение в 1С или зависший сеанс), shrink не даст эффекта, а администратор начнёт повторять операцию, теряя время. Также не стоит запускать shrink в разгар рабочего дня на нагруженной базе — операция конкурирует за ресурсы диска.

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

Сразу после операции проверьте физический размер LDF-файла на диске и сравните с исходным. Затем выполните запрос к sys.databases и убедитесь, что модель восстановления соответствует выбранной, а log_reuse_wait_desc равен NOTHING — это значит, что журнал ничем не блокируется.

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

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

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

Размер LDF на диске

Норма

Файл уменьшился до целевого размера

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

Размер не изменился — проверьте log_reuse_wait_desc

log_reuse_wait_desc

Норма

NOTHING

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

LOG_BACKUP или ACTIVE_TRANSACTION — причина роста не устранена

Динамика за неделю

Норма

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

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

Непрерывный рост — нет бэкапов журнала или зависают транзакции

Работа пользователей 1С

Норма

Запись документов без ошибок, нет пауз

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

Ошибки записи — проверьте место на диске и авторасширение

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

Можно ли уменьшить log-файл без остановки работы пользователей 1С?

Технически да: перевод в Simple и shrink не требуют монопольного доступа. Но на нагруженной базе операция будет конкурировать за диск и может замедлить работу. Рекомендуется выполнять её в нерабочее время, а активные сеансы с долгими транзакциями предварительно завершить.

Чем shrink отличается от выгрузки базы в DT?

Выгрузка DT — это резервная копия средствами 1С, она не влияет на размер LDF. Shrink — операция SQL Server над физическим файлом журнала. Это взаимодополняющие вещи: DT нужен как страховка, shrink — как способ освободить место на диске.

После shrink файл уменьшился, но через день снова вырос. Что не так?

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

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

Универсальной нормы нет: размер зависит от пикового объёма изменений между контрольными точками или бэкапами журнала. Ориентир — при корректной настройке LDF обычно заметно меньше MDF или сопоставим с ним. Журнал, в разы превышающий данные, — почти всегда признак отсутствия обслуживания.

Опасно ли переводить базу из Full в Simple?

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

Нужно ли уменьшать ещё и MDF-файл базы?

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