При работе с базами данных 1С на платформе SQL Server 2008 администраторы часто сталкиваются с ситуацией, когда файл журнала транзакций (.LDF) начинает стремительно расти, занимая всё дисковое пространство. Даже стандартные операции сжатия (Shrink) не всегда помогают сразу, а файл продолжает увеличиваться вскоре после манипуляций. Разберем детально, почему это происходит и как правильно обслуживать журнал транзакций, чтобы избежать подобных проблем.
Прежде чем приступать к активным действиям, нам необходимо понять, почему SQL Server не освобождает место внутри журнала транзакций самостоятельно. Журнал транзакций работает по принципу циклической записи, но он не может перезаписывать сегменты, которые помечены как «активные» или «ожидающие». Проанализируем состояние базы данных с помощью системного запроса:
SELECT name, log_reuse_wait_desc
FROM sys.databases
WHERE name = 'Имя_Вашей_Базы';
В колонке log_reuse_wait_desc мы увидим конкретную причину, по которой место в логе не может быть переиспользовано. Рассмотрим основные значения:
Full Recovery Model. SQL Server ждет, пока вы сделаете бэкап именно журнала транзакций.Simple это может означать, что давно не выполнялась контрольная точка.Выбор модели восстановления — ключевой фактор, определяющий поведение журнала. Проанализируем ситуацию в зависимости от выбранного режима:
Полная модель (Full Recovery Model). В этом режиме SQL Server сохраняет записи о каждой операции до тех пор, пока не будет сделан бэкап журнала транзакций (Transaction Log Backup). Важно понимать: обычный полный бэкап всей базы (Full Backup) не очищает журнал транзакций. Если вы делаете бэкап базы раз в сутки, но не делаете бэкап лога каждые 15–30 минут, файл LDF будет расти бесконечно.
Простая модель (Simple Recovery Model). Здесь SQL Server автоматически очищает журнал после завершения каждой транзакции (при выполнении контрольной точки). Этот режим подходит для тестовых баз или если вы готовы потерять данные с момента последнего полного бэкапа в случае аварии.
Если в 1С запущена обработка, которая длится часами, SQL Server не сможет уменьшить файл лога ниже точки начала этой транзакции. Для поиска таких процессов воспользуемся командой:
DBCC OPENTRAN('Имя_Вашей_Базы');
Если команда возвращает данные об активной транзакции, мы увидим SPID (идентификатор процесса). Его можно найти в Activity Monitor или через запрос sp_who2 и выяснить, какой пользователь или фоновое задание 1С удерживает журнал. Пока эта транзакция не завершится (COMMIT) или не будет отменена (ROLLBACK), сжатие файла не даст результата.
Одной из самых частых причин взрывного роста лога в 1С является переиндексация. При перестройке индексов (Rebuild) в полной модели восстановления SQL Server записывает в лог огромный объем данных. Если таблица занимает 50 ГБ, то при перестройке её индексов лог может вырасти на те же 50 ГБ за один проход.
Для оптимизации этого процесса рекомендуется следующая последовательность действий:
SIMPLE перед началом обслуживания индексов.FULL.Файл журнала транзакций внутри разделен на сегменты, называемые Virtual Log Files (VLF). Если файл рос автоматически маленькими порциями (например, по 1 Мб или по 10%), в нем могут образоваться тысячи мелких VLF. Это приводит к тому, что операции SHRINKFILE работают некорректно или крайне медленно.
Посмотрим на количество сегментов:
DBCC LOGINFO('Имя_Вашей_Базы');
Если количество строк в результате исчисляется сотнями или тысячами, это явный признак фрагментации лога. В такой ситуации правильным решением будет:
Если вы решили сжать журнал вручную в полной модели восстановления, следуйте этому проверенному алгоритму, чтобы физически освободить место на диске:
Шаг 1. Бэкап лога. Выполните бэкап журнала транзакций. Это пометит неактивные транзакции как готовые к перезаписи.
BACKUP LOG [Имя_Вашей_Базы] TO DISK = 'NUL';
Примечание: запись на 'NUL' используется для очистки лога без сохранения файла бэкапа (используйте только если у вас есть свежий полный бэкап).
Шаг 2. Сжатие файла. Выполните команду сжатия целевого файла.
DBCC SHRINKFILE (N'Имя_Файла_Лога_Логическое' , 1024);
Здесь 1024 — это целевой размер в мегабайтах.
Шаг 3. Проверка. Если размер не уменьшился, повторите Шаг 1 еще раз. Иногда требуется два бэкапа лога подряд, чтобы «протолкнуть» активную часть транзакций в начало файла.
Чтобы проблема не повторялась, мы рекомендуем настроить регулярный план обслуживания в SQL Server Management Studio. Посмотрим на минимально необходимый набор действий:
log_reuse_wait_desc, чтобы вовремя заметить аномальное поведение транзакций в 1С.