Журнал регистрации и журнал транзакций SQL: уменьшаем и настраиваем

Под «журналом 1С на SQL» на практике скрываются два разных файла, которые растут по своим причинам. Журнал регистрации лежит на диске кластера (файл 1Cv8.lgd), а журнал транзакций — это .ldf базы на MS SQL Server. Уменьшают их по-разному: первый — через конфигуратор (Администрирование → Настройка журнала регистрации → Сократить), второй — сменой модели восстановления и командой DBCC SHRINKFILE.

Если вы видите, что раздутый файл — это .lgd в каталоге 1Cv8Log, работайте с ним средствами платформы. Если на диске кончается место из-за <имя_базы>_log.ldf, это уже обслуживание SQL Server. Ниже — что именно делать в каждом случае, с точными путями и командами.

Какой журнал вы уменьшаете: регистрации или транзакций

Это ключевое различие, без которого легко удалить не то.

Журнал регистрации — это история действий пользователей: входы, проведение документов, изменения настроек, ошибки платформы. Платформа 8.3 хранит его не в базе SQL, а в файлах на диске:

• в клиент-серверном режиме — в рабочем каталоге кластера: srvinfo\reg_<порт>\<guid-базы>\1Cv8Log\;
• в файловом режиме — в каталоге информационной базы, папка 1Cv8Log.

Начиная с платформы 8.3.5 журнал по умолчанию ведётся в формате SQLite — это один файл 1Cv8.lgd. В старом формате были текстовые файлы .lgp и индекс 1Cv8.lgf.

Журнал транзакций MS SQL Server — это служебный файл .ldf, в который СУБД пишет все изменения перед фиксацией в основном файле данных .mdf. Он нужен самому SQL Server для отката и восстановления и к журналу регистрации 1С отношения не имеет.

Насколько заполнен журнал транзакций и чем именно, подскажет служебная команда SQL Server:

DBCC SQLPERF(LOGSPACE);

Она выводит по каждой базе размер журнала и процент использования. Если процент близок к 100 — журнал забит и его пора освобождать копией или сменой модели восстановления (об этом ниже).

Почему журнал разрастается и чем это грозит

Журнал регистрации пухнет, когда включена регистрация всех событий и файл давно не сокращали. Типичная картина — 1Cv8.lgd на несколько десятков гигабайт в базе, которой пару лет.

Основные причины роста:

• 📝 включена запись событий уровня «Информация» и «Примечания» — платформа фиксирует каждое открытие формы и обращение к данным;
• 👥 много пользователей и активный документооборот — события копятся быстро;
• 🗓 журнал ни разу не сокращали и не настроили разделение по периодам;
• 🔁 фоновые и регламентные задания генерируют тысячи записей в сутки.

Журнал транзакций SQL растёт по другой причине: база работает в модели восстановления Full, а резервные копии журнала (BACKUP LOG) не делаются. В этом режиме SQL Server не освобождает место в .ldf, пока не выполнена копия журнала, — файл пухнет до заполнения диска.

Чем это опасно:

• закончится место на диске — и кластер, и SQL Server встанут, пользователи не смогут работать;
• большой журнал регистрации замедляет его открытие и отбор, а запись новых событий идёт медленнее;
• переполненный .ldf блокирует любые операции записи в базе — проведение документов начнёт падать с ошибкой.

Настройка ведения журнала регистрации в конфигураторе

Прежде чем чистить, уменьшите скорость роста. Зайдите в конфигуратор и откройте Администрирование → Настройка журнала регистрации.

В диалоге настраиваются две вещи:

1. Какие события регистрировать. Снимите запись лишних уровней. Для рабочей базы обычно достаточно уровней «Ошибки» и «Предупреждения», а подробную «Информацию» включают временно — на время диагностики проблемы. Чем меньше уровней, тем медленнее растёт файл.
2. Разделение хранения по периодам. Если включить разделение (например, по месяцам), журнал будет храниться отдельными частями. Тогда старые периоды удобно удалять целиком, а открытие журнала за свежий период идёт быстрее.

Посмотреть журнал можно и не заходя в конфигуратор. В режиме 1С:Предприятие откройте Главное меню → Все функции → Стандартные → Журнал регистрации (пункт Все функции включается в параметрах, доступ — у пользователя с административными правами). Там удобно отобрать события по пользователю, дате и важности, но сократить журнал из режима предприятия стандартными средствами нельзя — только просмотр и выгрузка.

Как сократить журнал регистрации

Основной штатный способ — кнопка Сократить в том же окне Администрирование → Настройка журнала регистрации конфигуратора.

Порядок действий:

1. Откройте базу в конфигураторе под пользователем с полными правами.
2. Перейдите в Администрирование → Настройка журнала регистрации.
3. Нажмите Сократить.
4. Укажите дату — все события до неё будут удалены.
5. При необходимости отметьте сохранение удаляемых записей в отдельный файл (на случай будущего разбора) и укажите путь.
6. Запустите и дождитесь завершения.

Операция читает и переписывает файл 1Cv8.lgd, поэтому на большом журнале она долгая и нагружает диск. Запускайте сокращение в период низкой активности — ночью или в обед. Сеансы пользователей при этом не разрываются, но отклик базы может просесть.

Удалять 1Cv8.lgd целиком вручную не стоит — платформа при следующем старте создаст пустой, но вы потеряете всю историю и рискуете повредить структуру каталога базы, если сделаете это на работающем кластере.

Как уменьшить журнал транзакций MS SQL Server

Если разрослась не история 1С, а файл .ldf, работаем на стороне SQL Server. Сначала определите логическое имя файла журнала:

USE [имя_базы];
SELECT name, type_desc, size * 8 / 1024 AS size_mb
FROM sys.database_files;

Строка с type_desc = LOG — это ваш журнал транзакций, колонка name даёт логическое имя (обычно вида <имя_базы>_log).

Дальше есть два сценария.

Сценарий 1. Базе не нужно восстановление на точку во времени. Переведите базу в модель SIMPLE — SQL Server сам будет освобождать журнал после каждой транзакции:

ALTER DATABASE [имя_базы] SET RECOVERY SIMPLE;
DBCC SHRINKFILE (N'имя_базы_log', 512);

Второй параметр DBCC SHRINKFILE — целевой размер в мегабайтах. Задавайте разумный запас (здесь 512 МБ), чтобы файл не сжимался «в ноль» и потом сразу не рос обратно.

Сценарий 2. Нужны копии журнала (восстановление на любой момент). Оставьте модель FULL, но наладьте регулярные копии журнала — именно они освобождают место внутри .ldf:

BACKUP LOG [имя_базы] TO DISK = N'D:\Backup\имя_базы_log.trn';
DBCC SHRINKFILE (N'имя_базы_log', 512);

Если вы временно переключались на SIMPLE, после возврата в FULL цепочка резервного копирования обрывается. Сразу сделайте полную резервную копию базы — иначе первая же копия журнала завершится ошибкой:

ALTER DATABASE [имя_базы] SET RECOVERY FULL;
BACKUP DATABASE [имя_базы] TO DISK = N'D:\Backup\имя_базы_full.bak';

То же самое делается и мышью в SSMS: правый клик по базе → Tasks → Shrink → Files, в поле File type выбрать Log.

Сжатие базы и переиндексация для производительности

Уменьшение журналов освобождает место, но на скорость работы 1С сильнее влияет обслуживание индексов. Со временем они фрагментируются, и запросы замедляются.

Что делать по регламенту:

• Реорганизация (ALTER INDEX ... REORGANIZE) — лёгкая операция, подходит при фрагментации примерно до 30 %, выполняется без блокировки.
• Перестроение (ALTER INDEX ... REBUILD) — тяжелее, нужно при фрагментации выше 30 %, пересобирает индекс полностью.
• Обновление статистики (UPDATE STATISTICS) — помогает оптимизатору SQL строить правильные планы запросов.

Сжимать основной файл данных .mdf командой DBCC SHRINKDATABASE регулярно не стоит: это переупорядочивает страницы и повышает фрагментацию индексов, то есть делает ровно обратное обслуживанию. Сжатие данных оправдано только разово — например, после массового удаления данных из базы.

Автоматизация обслуживания по расписанию

Чтобы не чистить журналы вручную, настройте регулярные операции.

На стороне SQL Server это планы обслуживания (Maintenance Plans) в SSMS или задания SQL Server Agent. Базовый набор для 1С:

• копия журнала транзакций (Back Up Database → Transaction Log) — по расписанию, если база в модели FULL;
• полная копия базы — ежедневно/еженедельно;
• реорганизация или перестроение индексов — по порогу фрагментации;
• обновление статистики — регулярно.

Сокращение журнала регистрации автоматизируется сложнее: кнопка Сократить в конфигураторе разового запуска не имеет встроенного расписания. На практике поступают так:

• включают разделение по периодам, чтобы старые части было легко удалять;
• заводят напоминание администратору периодически запускать сокращение;
• в server-сценариях применяют собственные скрипты обслуживания, но без уверенности в них журнал безопаснее сокращать штатной кнопкой.

Типичные ошибки при уменьшении журналов

Несколько промахов, из-за которых место не освобождается или теряются данные.

• Чистят не тот журнал. Администратор удаляет записи журнала регистрации, а место на диске съедает .ldf — и наоборот. Сначала определите, какой файл вырос.
• Сжимают .ldf в расписании. Регулярный DBCC SHRINKFILE в модели FULL без копий журнала — это бесконечная борьба с симптомом. Файл каждый раз растёт обратно, а диск фрагментируется.
• Переходят на SIMPLE на продуктивной базе без согласования. Модель SIMPLE лишает восстановления на точку во времени. Если регламент требует точку отката — это недопустимо, выбор модели согласуйте с ответственным за резервное копирование .
• После возврата в FULL не делают полную копию. Цепочка копий журнала обрывается при переключении моделей. Без свежей полной копии первая же BACKUP LOG упадёт с ошибкой.
• Удаляют файлы журнала регистрации на работающем кластере. Платформа держит 1Cv8.lgd открытым. Правьте журнал через конфигуратор, а файлы периодов трогайте только при остановленной службе.
• Сжимают файл данных .mdf «для профилактики». DBCC SHRINKDATABASE повышает фрагментацию индексов и замедляет базу. Сжатие данных — разовая мера после массового удаления, а не часть регламента.

Частые вопросы