Разрастание файла журнала и фрагментация VLF вызывают серьезные проблемы производительности:

• Файл .ldf занял 100% емкости тома, парализуя работу СУБД;
• Медленный старт базы данных (Recovery Phase) при перезагрузке сервера из-за наличия десятков тысяч мелких VLF;
• Задержки при вставке и модификации данных в 1С (Log Write Waits / WRITELOG wait types).

1. Проверка количества и размера виртуальных лог-файлов (VLF)

Выполните анализ фрагментации структуры журнала:

-- Для SQL Server 2016 SP2 и новее:
SELECT 
    file_id,
    COUNT(vlf_sequence_number) AS Total_VLF_Count,
    SUM(vlf_size_mb) AS Total_Size_MB
FROM sys.dm_db_log_info(DB_ID('ERP_1C'))
GROUP BY file_id;

Если Total_VLF_Count превышает 500-1000 — журнал транзакций сильно фрагментирован и требует пересоздания.

2. Корректная процедура сжатия файла журнала (Shrink)

Шаг 1: Убедитесь, что активная часть лога сброшена бэкапом:

USE [ERP_1C];
GO
BACKUP LOG [ERP_1C] TO DISK = N'E:\Backup\Log\flush.trn' WITH COMPRESSION;
GO

Шаг 2: Определение логического имени файла LDF:

SELECT name, physical_name FROM sys.database_files WHERE type_desc = 'LOG';

Шаг 3: Выполнение сжатия до минимального целевого размера (например, 1024 МБ):

USE [ERP_1C];
GO
DBCC SHRINKFILE (N'ERP_1C_Log', 1024);
GO

3. Предотвращение фрагментации VLF (Правильный Autogrowth)

После сжатия задайте достаточный фиксированный размер файла LDF и правильный шаг авторасширения (от 512MB до 2048MB, но не в процентах!):

ALTER DATABASE [ERP_1C] 
MODIFY FILE ( NAME = N'ERP_1C_Log', SIZE = 8192MB , FILEGROWTH = 1024MB );
GO