Как объединить несколько файлов журнала транзакций базы данных SQL в один

← На главную

В практике системного администрирования 1С часто встречается ситуация, когда база данных имеет не один, а два или более файлов журнала транзакций (.LDF). Обычно это происходит из-за экстренных мер предыдущих администраторов, когда на основном диске заканчивалось место, и добавлялся второй файл на другой носитель. Однако в MS SQL Server работа с логами реализована иначе, чем с файлами данных: наличие нескольких файлов журнала не дает прироста производительности, а лишь усложняет обслуживание. Разберем подробно, как правильно объединить файлы логов и удалить лишние без риска повредить базу данных.

Почему несколько файлов журнала транзакций — это неэффективно

Прежде чем переходить к активным действиям, проанализируем архитектуру SQL Server. В отличие от файлов данных (MDF/NDF), которые могут записываться параллельно, заполнение журнала транзакций происходит строго последовательно. Это означает, что пока первый файл не заполнится, второй не начнет использоваться (или SQL будет переключаться между ними по кругу, но никогда не одновременно). Таким образом, мы не получаем выигрыша в скорости операций ввода-вывода (IOPS). Более того, наличие «раздутых» или разрозненных логов может замедлить процесс аварийного восстановления базы данных и создание бэкапов.

Подготовительный этап: Безопасность превыше всего

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

Создание полной резервной копии. Это обязательное условие. Даже если вы планируете менять модель восстановления, у вас должен быть актуальный бэкап.
Анализ свободного места. Убедитесь, что на диске, где останется основной файл журнала, достаточно места для приема данных из удаляемого файла.
Определение имен файлов. Нам понадобятся логические имена файлов в SQL Server (не путать с именами .ldf в проводнике).

Для получения логических имен выполним следующий запрос:


USE [Имя_Вашей_Базы];
GO
SELECT name, physical_name, type_desc 
FROM sys.database_files 
WHERE type = 1; -- 1 соответствует файлу лога
GO

Алгоритм объединения: Перенос данных и удаление

Простое удаление файла через GUI Management Studio часто завершается ошибкой «файл используется». Рассмотрим правильную последовательность действий, используя механизм EMPTYFILE.

Шаг 1: Переключение модели восстановления

Если ваша база работает в модели FULL, SQL Server будет удерживать активные транзакции в логах до тех пор, пока не будет сделан бэкап лога. Для упрощения процедуры удаления лишнего файла рекомендуется временно переключиться в модель SIMPLE. Это позволит очистить «хвосты» транзакций.


ALTER DATABASE [Имя_Вашей_Базы] SET RECOVERY SIMPLE;
GO

Шаг 2: Очистка и перенос активных записей

Теперь воспользуемся ключевой командой DBCC SHRINKFILE с параметром EMPTYFILE. Эта команда заставляет SQL Server перенести все активные виртуальные логи (VLF) из целевого файла в другие существующие файлы журнала.

Проанализируем выполнение команды:


DBCC SHRINKFILE (имя_лишнего_файла_лога, EMPTYFILE);
GO

Важный нюанс: После выполнения этой команды SQL Server пометит файл как пустой, и в него больше не будут записываться новые данные. Если команда выдает ошибку, попробуйте выполнить CHECKPOINT, чтобы сбросить все грязные страницы на диск.

Шаг 3: Программное удаление файла

Только после того, как файл был «опустошен», его можно безопасно удалить из структуры базы данных. Не делайте этого через проводник Windows! Используйте T-SQL:


ALTER DATABASE [Имя_Вашей_Базы] REMOVE FILE [имя_лишнего_файла_лога];
GO

Шаг 4: Возврат в рабочий режим

После успешного удаления необходимо вернуть базу в исходное состояние и обеспечить целостность цепочки логов:

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


ALTER DATABASE [Имя_Вашей_Базы] SET RECOVERY FULL;
GO
-- После этого запустите Full Backup через Maintenance Plan или вручную

Оптимизация оставшегося файла: Виртуальные логи (VLF)

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

Выясним количество VLF с помощью команды:

DBCC LOGINFO;

Если строк в результате слишком много (более 200-300), рекомендуется выполнить «пересоздание» лога:

Сжать основной файл лога до минимального размера (1 МБ).
Вручную увеличить его размер одной операцией до целевого объема (например, 10 ГБ), чтобы SQL создал крупные и эффективные VLF.

Что делать, если база «зависла» в режиме Recovery?

Если вы совершили ошибку и удалили файл .ldf физически до того, как удалили его в SQL Server, база может перестать запускаться. В этом случае выясним причину: SQL ищет файл по старому пути и, не находя его, помечает базу как поврежденную. Ни в коем случае не пытайтесь переустанавливать SQL Server.

Попробуйте следующие варианты решения:

Восстановление из бэкапа: Самый надежный и быстрый способ.
Режим EMERGENCY: Если бэкапа нет, базу переводят в режим EMERGENCY, выполняют DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS. Будьте осторожны: это может привести к потере последних транзакций 1С.

Таким образом, мы разобрали правильный и безопасный метод консолидации журналов транзакций. Помните, что порядок действий (EMPTYFILE -> REMOVE FILE) является критически важным для сохранения работоспособности системы.