Ситуация, когда файл журнала транзакций (LDF) разрастается до огромных размеров и занимает все свободное место на диске, является одной из самых «классических» проблем при эксплуатации 1С:Предприятие на базе MS SQL Server. В результате пользователи получают ошибку при входе, а администратору приходится вручную очищать место. Разберем подробно, почему это происходит и как настроить систему так, чтобы проблема исчезла навсегда.
Для начала проанализируем, за что отвечает журнал транзакций. SQL Server записывает в него каждое изменение данных в базе (вставку, удаление, изменение). Это необходимо для обеспечения целостности данных (ACID) и возможности восстановления. Рост файла сам по себе — это нормальный процесс, но он должен быть контролируемым. Рассмотрим две основные стратегии управления этим процессом в зависимости от выбранной модели восстановления базы данных.
Если для вашей организации не критична возможность восстановления базы данных на конкретный момент времени (например, на 14:15), а достаточно иметь просто ежедневный бэкап, то этот вариант будет самым оптимальным. Проанализируем, как работает модель Simple:
Чтобы изменить модель восстановления, выполните следующие действия в SQL Server Management Studio (SSMS): нажмите правой кнопкой на базу — Properties (Свойства) — Options (Параметры) — Recovery model — Simple.
Если данные крайне важны и вы хотите иметь возможность восстановиться «на любую секунду», необходимо использовать модель Full. Однако помните: в этой модели журнал будет расти бесконечно до тех пор, пока вы не сделаете бэкап самого журнала транзакций.
Рассмотрим правильную политику обслуживания для этого случая:
Именно процедура бэкапа журнала сообщает SQL Server, что записанные данные уже сохранены в архив и место в LDF-файле можно использовать повторно. Рассмотрим, как создать такой план обслуживания: воспользуйтесь разделом Management — Maintenance Plans в SSMS. Для автоматизации регулярного резервного копирования и обслуживания можно использовать набор SQL-скриптов для архивации и сжатия баз данных.
Иногда возникают ситуации, когда бэкап сделан, а место не освобождается. Выясним причину с помощью специального системного запроса. Рассмотрим использование представления sys.databases:
SELECT name, log_reuse_wait_desc
FROM sys.databases
WHERE name = 'Имя_Вашей_Базы';
Проанализируем результаты колонки log_reuse_wait_desc:
REPLICATION: если настроена репликация, журнал не очистится, пока данные не уйдут на другой сервер.ACTIVE_TRANSACTION: в 1С часто бывают «зависшие» сеансы или длительные операции (закрытие месяца). Пока транзакция не завершена, хвост журнала нельзя обрезать.CHECKPOINT: SQL Server ожидает записи данных из памяти на диск.Посмотрим на внутреннюю структуру LDF. Он состоит из мелких сегментов — Virtual Log Files (VLF). Если файл рос мелкими порциями (например, по 1 Мб), создаются тысячи VLF. Это приводит к тому, что 1С начинает «тормозить», а база данных после перезагрузки сервера может открываться очень долго (стадия Recovery).
Рекомендуемый алгоритм действий для оптимизации:
Shrink (сжатие) файла лога почти до минимума.Выясним, как типовые задачи 1С влияют на объем лога. Такие операции, как «Дефрагментация индексов» или «Реиндексация», выполняемые через консоль или типовые обработки, генерируют колоссальный объем записей. В полной модели восстановления после ночной реиндексации файл лога может превысить размер самой базы. Для оптимизации этих операций можно использовать скрипт адаптивного обновления индексов MS SQL.
Рассмотрим решение: если вы используете полную модель, настройте выполнение бэкапа журнала транзакций непосредственно ПЕРЕД и сразу ПОСЛЕ выполнения регламентных работ с индексами.
Никогда не включайте опцию Auto Shrink в настройках SQL. Это создает «эффект гармошки»: SQL сжимает файл, а при следующей операции записи в 1С вынужден снова его расширять. Это не только фрагментирует диск, но и катастрофически снижает производительность системы. Файл лога должен иметь стабильный, заранее выделенный размер, в рамках которого он будет работать циклически.
Для стабильной работы 1С необходимо либо перевести базу в режим Simple (если не нужны бэкапы логов), либо настроить Full модель с частыми бэкапами транзакций (раз в 15 минут). Также важно следить за параметрами Autogrowth и избегать чрезмерного количества виртуальных файлов VLF. Проанализировав эти аспекты и настроив план обслуживания один раз, вы избавите себя от необходимости чистить логи вручную.