При администрировании баз данных 1С:Предприятия под управлением Microsoft SQL Server системные администраторы часто сталкиваются с ситуацией, когда файл журнала транзакций (с расширением .ldf) начинает бесконтрольно увеличиваться в размерах, занимая десятки и сотни гигабайт дискового пространства. Разберем по шагам, почему возникает эта проблема, когда имеет смысл перевести базу в простую модель восстановления (Simple), как правильно выполнить сжатие (Shrink) и как оптимизировать работу СУБД и платформы 1С, чтобы ситуация не повторялась.
Файл .ldf содержит журнал всех изменений данных, происходящих в базе. Проанализируем основные факторы, которые приводят к его стремительному росту:
Прежде чем предпринимать действия по очистке, выясним причину, по которой SQL Server не может освободить пространство внутри файла. Для этого выполним системный запрос к представлению sys.databases:
SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
WHERE name = 'Имя_Базы_1С';
Рассмотрим значения поля log_reuse_wait_desc, которые объясняют причину блокировки усечения:
DBCC OPENTRAN.Если для базы данных нет жесткого требования восстанавливать состояние на любую произвольную секунду (Point-in-Time Recovery), а достаточно иметь ночные копии базы, перевод в режим Simple является самым простым и надежным решением. В этом режиме журнал транзакций автоматически усекается по контрольной точке (Checkpoint).
Разберем по шагам правильный алгоритм перевода базы в режим Simple:
USE [master];
ALTER DATABASE [Имя_Базы_1С] SET RECOVERY SIMPLE;
USE [Имя_Базы_1С];
DBCC SHRINKFILE (N'Имя_Файла_Лога' , 1024);
Здесь второй параметр задает целевой размер файла в мегабайтах (например, 1024 МБ).
Если специфика бизнеса требует возможности восстановления на любой момент времени, базу необходимо оставить в режиме Full. В этом случае уменьшение размера и предотвращение дальнейшего роста решается организацией правильного расписания обслуживания:
DBCC SHRINKFILE.Проанализируем важный нюанс: при частых автоматических увеличениях файла лога на маленькие порции (например, по 1 МБ или по 10%) внутри файла создается огромное количество виртуальных файлов журнала (Virtual Log Files — VLF). Избыток VLF (более 1000) приводит к существенному замедлению старта базы, фиксации транзакций и создания бэкапов.
Посмотрим, как оптимизировать параметры размещения файла:
DBCC LOGINFO или сделаем выборку из sys.dm_db_log_info. Если количество строк превышает 1000–2000, структуру лога следует оптимизировать.DBCC SHRINKFILE, а затем сразу вручную задаем ему фиксированный рабочий объем (например, 4096 МБ или 8192 МБ). Это сформирует минимальное и оптимальное количество фрагментов VLF.AUTO_SHRINK должна быть отключена, а регулярное сжатие лога не должно входить в ночные планы обслуживания, так как постоянное сжатие и расширение файла фрагментирует диск и создает лишнюю нагрузку на подсистему ввода-вывода.Чтобы снизить нагрузку на журнал транзакций на уровне прикладного кода 1С, рассмотрим следующие правила разработки и администрирования:
ЗафиксироватьТранзакцию() и последующим открытием новой транзакции методом НачатьТранзакцию():
Счетчик = 0;
НачатьТранзакцию();
Для Каждого Стр Из ТаблицаДанных Цикл
// Обработка данных
Счетчик = Счетчик + 1;
Если Счетчик % 1000 = 0 Тогда
ЗафиксироватьТранзакцию();
НачатьТранзакцию();
КонецЕсли;
КонецЦикла;
Если ТранзакцияАктивна() Тогда
ЗафиксироватьТранзакцию();
КонецЕсли;
tempdb), а не промежуточным записям в физические таблицы базы.