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

При администрировании баз данных 1С на платформе MS SQL Server нередко возникает ситуация, когда файл журнала транзакций (LDF) по объему превосходит сам файл данных информационной базы (MDF). Выясним причину такого поведения СУБД, разберем различия в моделях восстановления и рассмотрим по шагам, как безопасно сжать файл журнала транзакций и предотвратить его повторное бесконтрольное разрастание.

Зачем нужен LDF и почему он разрастается

Файл MDF хранит непосредственные данные таблиц и индексов конфигурации 1С. Файл LDF — это журнал предварительной записи транзакций (Write-Ahead Logging). Любое изменение данных (проведение документов, пересчет итогов, групповое перепроведение или регламентная реиндексация) сначала протоколируется в журнале и лишь затем попадает на страницы данных. Если лог транзакций не очищается, он увеличивается в размерах с каждой операцией изменения.

Главным фактором поведения лога является выбранная модель восстановления (Recovery Model):

1. Full (Полная): в журнале сохраняются абсолютно все изменения, что позволяет восстановить состояние базы данных на определенную секунду (Point-in-time recovery). Однако в этой модели транзакции никогда не удаляются из LDF автоматически — усечение лога происходит только после создания резервной копии самого журнала транзакций (бэкапа лога). Если делать только ночной полный бэкап базы, но не бэкапить лог в течение дня, LDF вырастет до гигантских размеров.
2. Simple (Простая): после фиксации каждой транзакции и прохождения контрольной точки (CHECKPOINT) неактивное пространство внутри LDF освобождается и используется повторно для новых операций. Сам физический файл лога при этом не уменьшается на диске, но и не разрастается бесконечно. Восстановление в этой модели возможно только на момент последнего полного или разностного бэкапа базы.

Способ 1. Однократное сжатие с переводом базы в модель Simple

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

Разберем по шагам выполнение этой операции с помощью скрипта в среде SQL Server Management Studio (SSMS):

USE [master];
GO
-- Переводим базу данных в простую модель восстановления
ALTER DATABASE [Имя_Базы] SET RECOVERY SIMPLE;
GO
-- Выполняем сжатие файла журнала транзакций до минимального размера
-- Вместо Имя_Файла_Лога укажите логическое имя файла LDF
DBCC SHRINKFILE (Имя_Файла_Лога, 1);
GO

Если же политика резервного копирования на предприятии строго требует полной модели восстановления, вернем базу в режим Full сразу после усечения. Посмотрим на пример такого скрипта:

USE [master];
GO
ALTER DATABASE [Имя_Базы] SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (Имя_Файла_Лога, 1);
GO
ALTER DATABASE [Имя_Базы] SET RECOVERY FULL;
GO
-- ВАЖНО: После возврата в FULL цепочка логов разорвана, 
-- необходимо сразу же создать полный бэкап базы данных!
BACKUP DATABASE [Имя_Базы] TO DISK = 'D:\Backup\Имя_Базы_Full.bak';
GO

Обратите внимание: для версий MS SQL Server 2005 и более старых ранее применялась директива BACKUP LOG [Имя_Базы] WITH TRUNCATE_ONLY, однако в современных версиях SQL Server (начиная с 2008) эта команда удалена из соображений надежности, поэтому переключение в Simple является универсальным методом.

Способ 2. Сжатие файла через графический интерфейс Management Studio

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

1. Откроем SQL Server Management Studio и подключимся к экземпляру сервера.
2. В дереве объектов развернем узел Databases, нажмем правой кнопкой мыши на требуемую базу 1С и выберем Properties (Свойства).
3. Перейдем на вкладку Options (Параметры) и изменим значение Recovery model на Simple. Нажмем OK.
4. Снова нажмем правой кнопкой мыши по базе, перейдем в пункт Tasks (Задачи) -> Shrink (Сжать) -> Files (Файлы).
5. В открывшемся окне в выпадающем списке File type выберем Log. В поле File name отобразится текущее логическое имя файла журнала.
6. В блоке параметров сжатия выберем Reorganize pages before releasing unused space или Release unused space, укажем желаемый минимальный размер (например, 1 МБ) и нажмем OK.
7. Если файл сжался не полностью с первого раза, повторим операцию еще раз, так как транзакции внутри лога могли освободиться только после создания контрольной точки.

Что делать, если файл LDF не сжимается?

Иногда после выполнения команды сжатия размер файла уменьшается лишь незначительно (например, с 12 ГБ до 11 ГБ) либо не уменьшается вовсе, даже если пользователей в 1С нет. Выясним причину этой проблемы.

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

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

Проанализируем возвращаемое значение в поле log_reuse_wait_desc:

1. LOG_BACKUP: база находится в режиме Full, и SQL Server ждет снятия копии лога. Пока не будет выполнен BACKUP LOG или переключение в Simple, файл ужать невозможно.
2. ACTIVE_TRANSACTION: внутри базы есть открытая, незафиксированная транзакция (например, зависший фоновый сеанс 1С или незакрытая операция). Определим сеанс командой DBCC OPENTRAN и завершим проблемное подключение.
3. CHECKPOINT: журнал ожидает фиксации контрольной точки. Выполним команду CHECKPOINT в окне запроса для принудительного сброса «грязных» страниц памяти на диск.

Правильная настройка лога транзакций для баз 1С

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

1. Не ставьте жестких ограничений размера (Limit file growth): значение по умолчанию 2 097 152 МБ означает фактическое отсутствие лимита (2 ТБ). Если задать лимит искусственно (например, ограничить лог размером 4 ГБ), то при его заполнении все пользователи 1С получат критическую ошибку, а база данных полностью заблокирует проведение документов и запись данных.
2. Настройте бэкап журнала транзакций при модели Full: если используется Full Recovery Model, настройте в Плане обслуживания (Maintenance Plan) или SQL Server Agent регламентное создание бэкапа лога с интервалом каждые 15–30 минут. Это не только стабилизирует размер LDF на постоянной отметке, но и защитит базу от потери данных при аппаратных сбоях.
3. Избегайте процентного прироста (Autogrowth): переведите автоприрост файла LDF из процентов в фиксированные мегабайты (например, шаг в 256 МБ или 512 МБ). Механизм мгновенной инициализации файлов (Instant File Initialization) в Windows не распространяется на файлы логов — при каждом расширении LDF сервер принудительно перезаписывает выделяемое место нулями, что в момент прироста вызывает зависание сеансов 1С.
4. Задайте стартовый размер после сжатия: сжав файл до 1 МБ, сразу увеличьте его вручную до рабочего технологического размера (например, 2–4 ГБ). Это создаст внутри лога оптимальное число виртуальных файлов журнала (VLF), предотвратит их фрагментацию и избавит сервер от микрозадержек в процессе рабочего дня.