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

← На главную

Работа системы «1С:Предприятие» в связке с СУБД Microsoft SQL Server — это стандарт де-факто для автоматизации среднего и крупного бизнеса. Однако администраторы баз данных часто сталкиваются с лавинообразным ростом файлов журнала транзакций (файлов с расширением .ldf). Порой размер лога превышает размер самой базы данных в несколько раз, полностью занимая дисковое пространство на сервере. В этой статье мы подробно разберем, почему растет журнал транзакций, как безопасно уменьшить его размер, почему популярные в сети методы могут быть опасны и как правильно настроить систему для стабильной работы.

Почему лог-файл увеличивается и когда его нужно сжимать

Для начала проанализируем, зачем вообще нужен журнал транзакций. SQL Server использует его для обеспечения принципов ACID (атомарность, согласованность, изолированность, долговечность). Любое изменение данных в 1С (проведение документа, запись элемента справочника) сначала фиксируется в журнале транзакций и только потом записывается в основной файл базы данных (.mdf). Это гарантирует, что в случае сбоя системы данные можно будет восстановить до мельчайших деталей.

Если база данных работает в полной модели восстановления (Full Recovery Model), журнал транзакций будет расти непрерывно до тех пор, пока не будет сделан бэкап самого журнала. Только после создания резервной копии лога SQL Server помечает обработанные транзакции как неактивные и разрешает использовать это пространство повторно. Если резервное копирование лога не настроено, файл .ldf рано или поздно заполнит весь жесткий диск.

Способ 1. Временный перевод базы в модель Simple (почему это «жгут на шее»)

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

Давайте выясним причину, почему это крайне опасный метод для рабочих баз данных 1С. Смена модели восстановления на Simple мгновенно разрушает последовательность регистрационных номеров транзакций (так называемую цепочку LSN — Log Sequence Number). Это означает следующее:

Разрыв цепочки бэкапов: Вы больше не сможете восстановить базу данных на определенный момент времени (Point-in-Time Recovery) в случае аварии.
Потеря защиты: Даже если вы сразу вернете базу обратно в режим Full, все последующие бэкапы транзакций будут абсолютно бесполезны до тех пор, пока вы не сделаете новый полный бэкап всей базы данных (Full Backup). До этого момента база остается полностью уязвимой.

Именно поэтому сравнение этого метода со «жгутом на шее при кровотечении из носа» в сообщении 5 абсолютно оправданно. Использовать этот способ на продуктивных базах данных категорически не рекомендуется.

Способ 2. Правильный бэкап и сжатие лога (Безопасный метод)

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

Для начала нам необходимо узнать логическое имя файла журнала транзакций. Выполним простой SQL-запрос в SQL Server Management Studio (SSMS):


USE [Имя_Вашей_Базы_1С]
GO
SELECT name, type_desc, physical_name 
FROM sys.database_files;

Запомните логическое имя файла лога (обычно оно имеет суффикс _log). Далее мы можем пойти двумя путями:

Вариант А. Создание стандартного бэкапа журнала на диск с последующим сжатием

Этот способ является наиболее правильным, так как у вас сохраняется резервная копия транзакций:


-- 1. Делаем бэкап журнала транзакций в файл
BACKUP LOG [Имя_Вашей_Базы_1С] 
TO DISK = N'D:\Backup\MyBase_Log.trn' 
WITH NOFORMAT, NOINIT, 
NAME = N'Log Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10;
GO

-- 2. Сжимаем файл журнала транзакций до желаемого размера (например, до 1024 МБ)
DBCC SHRINKFILE (N'Имя_Файла_Лога_log', 1024);
GO

Вариант Б. Бэкап лога «в никуда» (для экстренных случаев)

Если на диске физически нет свободного места для записи файла бэкапа, можно выполнить резервное копирование на специальное пустое устройство (в «никуда»):


-- Резервное копирование на виртуальное устройство NUL
BACKUP LOG [Имя_Вашей_Базы_1С] TO DISK = 'NUL';
GO

-- Сжатие файла лога
DBCC SHRINKFILE (N'Имя_Файла_Лога_log', 1024);
GO

Обратите внимание: в устаревших статьях часто советуют использовать команды WITH TRUNCATE_ONLY или WITH NO_LOG. Помните, что начиная с версии SQL Server 2008 эти параметры были полностью удалены. Их использование приведет к ошибке синтаксиса.

Как выяснить, что именно мешает сжатию файла лога

Проанализируем ситуацию, когда вы выполнили бэкап лога и запустили команду DBCC SHRINKFILE, но размер файла не уменьшился ни на один мегабайт. В SQL Server заложена защита от сжатия активной части лога. Чтобы понять, какой именно процесс внутри СУБД блокирует очистку, выполним следующий запрос:


SELECT name, log_reuse_wait_desc 
FROM sys.databases;

Найдите в списке вашу базу данных и посмотрите значение в колонке log_reuse_wait_desc:

LOG_BACKUP — лог не сожмется, пока не будет сделана резервная копия журнала транзакций. Сделайте бэкап лога еще раз.
ACTIVE_TRANSACTION — в базе выполняется долгая транзакция. В 1С это очень частая проблема: например, зависший сеанс пользователя, выполняющийся фоновый процесс, долгий расчет себестоимости или групповое перепроведение документов. Пока транзакция не завершится (или не будет принудительно прервана), сжать лог невозможно.
REPLICATION / DATABASE_MIRRORING — транзакции ожидают отправки на другие серверы в распределенной базе данных или в зеркальной копии.

Проблема виртуальных лог-файлов (VLF) и производительность 1С

Рассмотрим подробнее внутреннее устройство LDF-файла. Физически файл журнала транзакций делится внутри на сегменты — виртуальные лог-файлы (VLF). Если вы сожмете лог до минимального размера (например, до 1 МБ), а в свойствах базы оставите дефолтные настройки автоприроста (например, шаг в 1 МБ или 10%), то при каждой записи SQL Server будет динамически расширять файл и дробить его на тысячи мелких VLF.

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

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

Сразу после проведения процедуры шринка необходимо вручную задать журналу транзакций нормальный начальный целевой размер и установить адекватный фиксированный шаг автоприроста. Рекомендуется выделять под лог от 10% до 20% от размера самой базы данных. Шаг прироста лучше задавать в мегабайтах (например, по 256 или 512 МБ), избегая процентного соотношения:


ALTER DATABASE [Имя_Вашей_Базы_1С] 
MODIFY FILE ( NAME = N'Имя_Файла_Лога_log', SIZE = 4096MB , FILEGROWTH = 512MB );
GO

Специфика платформы 1С:Предприятие, вызывающая рост логов

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

Индексация и обновление статистик средствами 1С: Если в вашей системе настроены регламентные задания по обслуживанию индексов (дефрагментация, реиндексация) силами самой платформы 1С, а не планами обслуживания SQL, это генерирует колоссальный объем транзакций. На время таких процедур лог-файл может увеличиваться в разы.
Интенсивная работа с временными таблицами: Запросы 1С активно используют временные таблицы для построения сложных отчетов. Эти операции сильно нагружают как базу tempdb, так и журналы транзакций рабочих баз.

Резюме: правильная стратегия обслуживания

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

Рекомендуется организовать автоматическое резервное копирование журнала транзакций через Планы обслуживания (Maintenance Plans) или SQL Server Agent с интервалом от 15 до 60 минут (в зависимости от интенсивности работы пользователей). Это позволит SQL Server своевременно помечать прошедшие транзакции как неактивные, благодаря чему система будет циклически перезаписывать данные внутри файла .ldf, не позволяя ему бесконтрольно расти.