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

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Почему выгрузка и загрузка через .dt — плохая идея

Выгрузка информационной базы в файл .dt предназначена исключительно для файловых вариантов и переноса конфигураций. Использование формата .dt в качестве резервного копирования или способа обслуживания крупной рабочей СУБД несёт в себе серьёзные риски:

  1. Риск потери данных и целостности: При выгрузке крупной базы могут возникнуть ошибки структуры данных или превышение лимитов формата.
  2. Простой предприятия: Процесс выгрузки и загрузки базы большого объема может занять несколько часов, блокируя работу пользователей.
  3. Низкая эффективная производительность: Создание базы с нуля и импорт данных заново пересоздают индексы и таблицы, но не решают системную причину роста лога на уровне MS SQL Server.

Шаг 1. Выбор модели восстановления базы данных (Recovery Model)

Проанализируем причины роста журнала транзакций. Объем файла .ldf напрямую зависит от выбранной модели восстановления базы данных в MS SQL Server:

  1. Полная модель (Full): Журнал транзакций фиксирует абсолютно все операции и не очищается автоматически после резервного копирования самой базы. Файл лога будет непрерывно расти до тех пор, пока не будет сделан бэкап журнала транзакций (BACKUP LOG). Полная модель необходима только тогда, когда требуется возможность восстановления базы на любой произвольный момент времени.
  2. Простая модель (Simple): В этом режиме транзакции усекаются автоматически после завершения и фиксации. Лог используется только для обеспечения целостности текущих операций и не разрастается до гигантских размеров при регулярных операциях.

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

Шаг 2. Перевод базы в Simple и выполнение сжатия (Shrink)

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

Способ 1. Через графический интерфейс SSMS:

  1. Откроем SQL Server Management Studio и подключимся к серверу баз данных.
  2. В дереве объектов Object Explorer найдем нужную базу 1С, кликнем по ней правой кнопкой мыши и выберем Properties (Свойства).
  3. Перейдем на вкладку Options (Параметры).
  4. В поле Recovery model (Модель восстановления) выберем значение Simple и нажмем OK.
  5. Для выполнения сжатия кликнем правой кнопкой мыши по базе данных, выберем Tasks (Задачи) -> Shrink (Сжать) -> Files (Файлы).
  6. В поле File type (Тип файла) выберем Log, укажем требуемый размер или вариант сжатия и нажмем OK.

Способ 2. С помощью T-SQL скрипта:

Выполним эквивалентные действия с помощью следующего скрипта:


-- Переводим базу в простую модель восстановления
ALTER DATABASE [ИмяБазы1С] SET RECOVERY SIMPLE;
GO

-- Выполняем сжатие файла журнала транзакций
DBCC SHRINKFILE (N'ИмяФайлаЛога_log', 1);
GO

Как уменьшить лог транзакций в режиме Full (Полная модель)

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

  1. Настроем регулярный бэкап журнала транзакций (например, каждые 15–30 минут через Планы обслуживания SQL Server). Это предотвратит бесконечный рост лога.
  2. Если лог разросся до критических размеров одноразово (из-за перепроведения документов или реструктуризации), выполним резервное копирование журнала с последующим сжатием:

-- Создаем бэкап журнала транзакций
BACKUP LOG [ИмяБазы1С] TO DISK = N'C:\Backup\LogBackup.trn';
GO

-- Выполняем сжатие файла лога
DBCC SHRINKFILE (N'ИмяФайлаЛога_log', 100);
GO

Важные рекомендации по настройке и обслуживанию MS SQL для 1С

Проанализируем дополнительные настройки СУБД, которые помогут избежать проблем с журналом транзакций в будущем:

  1. Настройка шага автоувеличения (Auto-growth): Не оставляйте приращение лога в процентах или малыми фиксированными порциями (по 1 МБ). Установите фиксированный шаг приращения, например 512 MB или 1024 MB. Это позволит избежать сильной фрагментации виртуальных файлов журнала (VLF).
  2. Избегайте постоянного использования Auto-Shrink: Включение опции AUTO_SHRINK вызывает постоянно повторяющиеся циклы сжатия и расширения файлов, что сильно деградирует производительность дисковой подсистемы и вызывает высокую фрагментацию индексов.
  3. Диагностика незавершенных транзакций: Если журнал транзакций не усекается даже в Simple режиме, следует проверить наличие зависших или длинных транзакций 1С с помощью команды DBCC OPENTRAN.
← На главную