Как настроить автоматическую очистку журнала транзакций (LDF) в MS SQL Server для баз данных 1С

Рано или поздно каждый системный администратор или специалист 1С, сопровождающий клиент-серверные базы данных, сталкивается с проблемой неконтролируемого роста лог-файлов. Ситуация, когда скромная база «1С:Бухгалтерия государственного учреждения» (БГУ) или «1С:Бухгалтерия предприятия» объемом в 4 ГБ раздувает свой журнал транзакций (файл с расширением .ldf) до 60–100 ГБ, — классическая реальность.

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

Главное заблуждение: почему лог растет, несмотря на ежедневные бэкапы

Очень часто администраторы рассуждают так: «Я настроил резервное копирование базы данных каждый вечер. Почему лог продолжает расти?»

Это ключевая ошибка в понимании архитектуры MS SQL Server. Если ваша база данных работает в модели восстановления Full (Полная), то стандартный ежедневный бэкап базы данных (Full Database Backup) не очищает и не усекает журнал транзакций. Механизм работы СУБД устроен следующим образом:

• В режиме FULL сервер SQL обязан хранить абсолютно все изменения (транзакции) в файле лога с момента последнего создания бэкапа именно журнала транзакций. Это необходимо для того, чтобы в случае сбоя вы могли восстановить состояние системы на любую секунду («точка во времени»).
• Чтобы лог очистился (произошло его усечение — truncation), необходимо регулярно выполнять специальный бэкап самого журнала транзакций с помощью команды BACKUP LOG.
• Если бэкап лога не настроен, MS SQL Server будет бесконечно копить транзакции в файле .ldf, пока на диске физически не закончится свободное место.

Опасность схемы ручного сжатия «Full -> Simple -> Shrink -> Full»

В попытках быстро решить проблему администраторы часто прибегают к следующему алгоритму: вручную меняют модель восстановления базы на Simple, делают сжатие файла лога (Shrink) до минимального размера, а затем возвращают модель Full. Это крайне опасная практика, несущая огромные риски:

1. Разрыв цепочки LSN (Log Sequence Number): В момент переключения базы данных в режим Simple последовательность логов безвозвратно прерывается. Все резервные копии журналов, сделанные до этого момента, становятся бесполезными для восстановления. Вы больше не сможете восстановиться «на точку во времени» после совершения этой процедуры, пока не создадите новый полный бэкап базы данных.
2. Фрагментация VLF (Virtual Log Files): Физический файл лога .ldf внутри себя разбит на виртуальные сегменты — VLF. Когда мы сжимаем файл лога до 0 или нескольких мегабайт, а затем база 1С начинает активно записывать данные, файл лога начинает лавинообразно расти. Если авторост настроен по умолчанию (например, на 10% или мелкими шагами по 1 МБ), СУБД нарежет внутри файла десятки тысяч микроскопических VLF.

Чем опасна высокая фрагментация VLF для 1С?

• Существенно падает скорость выполнения любых транзакций записи (проведение документов, групповое перепроведение, импорт данных) в 1С.
• База данных начинает очень долго запускаться и зависает в статусе In Recovery (В процессе восстановления) при перезапуске службы SQL Server или перезагрузке сервера.
• Замедляются процессы резервного копирования и восстановления базы из бэкапа.

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

Прежде чем приступать к решительным действиям, выясним, почему именно MS SQL Server не может очистить и переиспользовать место внутри файла лога. Для этого выполним системный запрос в среде SQL Server Management Studio (SSMS):

SELECT name, recovery_model_desc, log_reuse_wait_desc 
FROM sys.databases;

Проанализируем столбец log_reuse_wait_desc. Он показывает, какое событие мешает очистке лога в данный момент:

• LOG_BACKUP: Самая частая причина при модели FULL. Лог ждет резервного копирования журнала транзакций.
• ACTIVE_TRANSACTION: В системе есть зависшая или очень долгая транзакция. Например, пользователь в 1С запустил тяжелый отчет, проведение документов за год или фоновое задание зависло. SQL Server не может очистить лог, пока эта транзакция не завершится (COMMIT) или не откатится (ROLLBACK).
• REPLICATION / DATABASE_MIRRORING: Данные еще не передались на сервер-подписчик или зеркало в отказоустойчивых кластерах.

Пошаговые сценарии автоматизации и решения проблемы

Выбор стратегии зависит от того, насколько критична для вашего бизнеса потеря данных за рабочий день.

Сценарий А. Нам необходимо восстановление «точка во времени» (Модель FULL)

Этот сценарий обязателен для высоконагруженных баз данных (ERP, УТ, КА), где работают сотни пользователей и потеря даже часа работы критична.

Шаг 1. Настраиваем регулярный бэкап журналов транзакций

Вам необходимо создать План обслуживания (Maintenance Plan) или задание в SQL Server Agent, которое будет выполнять резервное копирование лога. Оптимальная частота для активно работающей 1С — каждые 15–30 минут (в крайнем случае — каждый час) в течение рабочего дня.

Скрипт резервного копирования лога выглядит следующим образом:

BACKUP LOG [Имя_Вашей_Базы] 
TO DISK = N'D:\Backup\Log\Имя_Вашей_Базы_log.trn' 
WITH NOFORMAT, NOINIT, 
NAME = N'Backup_Log', SKIP, NOREWIND, NOUNLOAD, STATS = 10;

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

Шаг 2. Разово устраняем фрагментацию VLF и фиксируем здоровый размер файла

Для того чтобы исправить последствия частых сжатий, выполним процедуру оздоровления файла лога:

1. Временно переводим базу в простую модель восстановления: ALTER DATABASE [Имя_Вашей_Базы] SET RECOVERY SIMPLE;
2. Сжимаем лог-файл до минимального размера (например, до 10 МБ). В SSMS это можно сделать через контекстное меню базы: Задачи -> Сжать -> Файлы (Тип файла: Журнал). Либо скриптом: DBCC SHRINKFILE (N'Имя_Файла_Лога_Логическое' , 10);
3. Критически важно: Сразу после сжатия задаем файлу лога фиксированный целевой размер, который покроет нагрузку вашей базы в течение дня без автороста. Например, для базы 1С размером 4 ГБ хорошим размером лога будет 1-2 ГБ. Зададим его вручную:
   Скопировать код

   
   ALTER DATABASE [Имя_Вашей_Базы] 
   MODIFY FILE ( NAME = N'Имя_Файла_Лога_Логическое', SIZE = 2048MB );
   

   Это действие создаст несколько крупных, здоровых VLF-сегментов внутри файла.
4. Возвращаем модель восстановления FULL: ALTER DATABASE [Имя_Вашей_Базы] SET RECOVERY FULL;
5. Обязательно: Сразу же делаем полный бэкап базы данных, чтобы возобновить непрерывную цепочку LSN: BACKUP DATABASE [Имя_Вашей_Базы] TO DISK = N'D:\Backup\Имя_Вашей_Базы.bak';

Шаг 3. Настраиваем правильный авторост

Избегайте автороста лога в процентах. Настройте фиксированный шаг роста. Например, укажите авторост по 256 МБ или 512 МБ. Это предотвратит лавинообразную фрагментацию VLF, если транзакциям все же не хватит выделенного объема лога.

Сценарий Б. Нам достаточно бэкапа раз в день (Модель SIMPLE)

Для небольших баз (таких как БГУ 4 ГБ в рассматриваемом вопросе), где работает небольшое количество бухгалтеров и в случае аварии проще восстановить архив за прошлый вечер и заново ввести документы за текущий день, модель Simple является идеальным и беспроблемным решением.

Рассмотрим по шагам, как перевести базу на эту модель и навсегда забыть о ручной очистке логов:

1. Переводим базу данных в модель восстановления SIMPLE навсегда: ALTER DATABASE [Имя_Вашей_Базы] SET RECOVERY SIMPLE;
2. Выполняем разовый SHRINK (сжатие) файла лога, чтобы вернуть операционной системе гигабайты пустого места на диске: DBCC SHRINKFILE (N'Имя_Файла_Лога_Логическое' , 1024); Мы рекомендуем сжать лог до фиксированного объема порядка 1 ГБ, чтобы СУБД не тратила ресурсы на выделение дискового пространства во время проведения тяжелых документов.
3. Настраиваем параметры автороста файла лога: задаем фиксированный шаг (например, по 256 МБ).
4. В планах обслуживания оставляем только регулярный ежедневный бэкап базы данных (Full Backup). Бэкап лога делать не нужно (он заблокирован в режиме Simple).

Что произойдет после этого?

В модели восстановления SIMPLE SQL Server будет автоматически очищать неактивную часть журнала транзакций каждый раз при прохождении контрольной точки (Checkpoint). Это означает, что новые данные будут циклически записываться поверх старых прямо внутри вашего файла .ldf размером 1 ГБ. Он больше никогда не разрастется до критических 65 ГБ, и вам больше не придется заходить на сервер каждые два месяца для ручных манипуляций.