Очистка журнала регистрации 1С и журналов SQL без потери базы

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

Разберу всё по порядку: где физически лежат «логи 1С», когда уместна команда DELETE, почему TRUNCATE тут обычно не работает , и как настроить регулярную очистку, чтобы файл не разрастался снова. Главное — ни один из способов не трогает ваши данные: журнал событий и журнал транзакций хранятся отдельно от учётной информации.

Какие именно логи 1С вы собираетесь чистить

Под «логами 1С» в запросах скрываются три разных объекта. Прежде чем запускать любую команду, определитесь, что именно разрослось.

• 📒 Журнал регистрации — события входа пользователей, проведения документов, ошибок. Хранится в файле 1Cv8.lgd (новый формат) или в папке 1Cv8Log (старый текстовый формат). К основной SQL-базе отношения не имеет.
• 🗄️ Журнал транзакций СУБД — служебный лог MS SQL Server (.ldf) или WAL в PostgreSQL. Растёт из-за модели восстановления и отсутствия бэкапов журнала.
• 🔧 Технологический журнал — текстовые файлы диагностики платформы, включаются вручную через logcfg.xml. Если его никто не настраивал — его у вас нет.

Чаще всего под «очисткой логов в SQL» понимают именно первый пункт — раздувшийся журнал регистрации в клиент-серверной базе на SQL Server. С него и начнём.

Где физически хранится журнал регистрации

Журнал регистрации (ЖР) не лежит в таблицах SQL Server. Это отдельное хранилище рядом с базой. Поэтому в самой СУБД вы не найдёте таблицу вроде EventLog — её там нет, и TRUNCATE TABLE по журналу 1С выполнить не получится.

Расположение зависит от режима работы:

• Файловая база — в каталоге информационной базы. Новый формат: файл 1Cv8.lgd. Старый формат: папка 1Cv8Log с файлами *.lgf и *.lgp.
• Клиент-серверная база — в рабочем каталоге кластера srvinfo, внутри подпапки с идентификатором базы. Там тот же 1Cv8.lgd или папка 1Cv8Log.

Начиная с платформы версии не ниже 8.3.5, по умолчанию используется новый формат — единый файл 1Cv8.lgd. Это полноценная база SQLite. Именно поэтому к нему в принципе применим SQL — но не диалект SQL Server, а SQLite. Старый формат 1Cv8Log — это набор текстовых файлов, и чистится он просто удалением старых файлов периодов.

Способы очистки и когда какой выбрать

Способов четыре. Выбор зависит от того, можно ли вывести пользователей из базы и насколько вам важна история событий.

Для большинства ситуаций хватает первых двух строк. Прямой SQL по .lgd — крайний случай для опытного администратора, а не рутинная операция.

Очистка журнала регистрации штатными средствами

Это рекомендуемый путь. Он безопасен, не трогает файлы руками и позволяет сохранить удаляемые записи в архив.

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

После сокращения размер файла 1Cv8.lgd на диске сразу не уменьшится — SQLite освобождает место внутри файла, но не возвращает его системе. Как ужать файл физически — в разделе про обслуживание ниже.

Если журнал ведётся в старом формате 1Cv8Log, сокращение работает так же. Дополнительно в этом формате можно включить разделение журнала по периодам методом УстановитьРазделениеЖурналаРегистрации (час, день, неделя, месяц). Тогда старые файлы периодов удаляются по отдельности, не затрагивая свежие.

Полное обнуление: удаление файла журнала

Когда история событий не нужна целиком, быстрее удалить сам файл журнала — платформа создаст его заново пустым при следующем запуске.

Порядок для клиент-серверной базы:

1. Убедитесь, что в базе нет активных сеансов (консоль кластера или rac session list).
2. Остановите работу с базой: завершите сеансы или временно заблокируйте вход пользователей штатной блокировкой соединений.
3. В каталоге базы внутри srvinfo найдите 1Cv8.lgd (или папку 1Cv8Log).
4. Сделайте копию файла на случай отката, затем удалите оригинал.
5. Снимите блокировку и дайте пользователям войти — журнал начнёт писаться с нуля.

Для файловой базы всё то же самое, только файл лежит прямо в каталоге информационной базы.

Перед удалением обязательно сделайте резервную копию файла журнала и, в идеале, самой базы. Откатить удалённый журнал иначе не выйдет.

Прямой SQL по файлу журнала: DELETE, VACUUM и почему это крайний случай

Поскольку 1Cv8.lgd — это SQLite, к нему технически применимы SQL-команды. Но делать это стоит, только если штатные способы недоступны, и с полным пониманием рисков.

Ключевые моменты:

• Работать можно исключительно при остановленной базе и закрытых сеансах — иначе вы повредите журнал, с которым параллельно работает платформа.
• Диалект — SQLite, а не Transact-SQL. Подключаться нужно SQLite-клиентом (sqlite3, DB Browser for SQLite), а не через SSMS.
• В SQLite нет команды TRUNCATE. Полная очистка таблицы делается через DELETE FROM <таблица>;, после чего запускают VACUUM;, чтобы ужать файл.
• Внутренняя схема таблиц журнала не документирована и может меняться между версиями платформы. Прямые правки — неподдерживаемый сценарий.

Общая логика (имена таблиц в вашей версии уточняйте по факту, открыв файл в SQLite-клиенте):

-- Сначала посмотреть список таблиц
.tables

-- Удалить записи (пример; реальное имя таблицы событий смотрите в схеме)
DELETE FROM EventLog WHERE Date < '20260101';

-- Вернуть освобождённое место системе
VACUUM;

Вывод простой: DELETE по .lgd возможен, но это инструмент для редких ситуаций. TRUNCATE в этом контексте не существует, а VACUUM — обязательный финальный шаг, если вы хотите реально освободить место на диске.

Если разросся журнал транзакций SQL Server

Часто под «логами 1С в SQL» имеют в виду вовсе не журнал регистрации, а файл журнала транзакций СУБД — .ldf, который занял весь диск. Это отдельная задача на стороне MS SQL Server.

Причина роста почти всегда одна: база в модели восстановления FULL, а резервное копирование журнала не настроено. В FULL журнал копит все изменения до тех пор, пока не будет сделан бэкап журнала.

Что делать:

1. Проверьте модель восстановления базы в SSMS (свойства базы → «Параметры» → «Модель восстановления»).
2. Если нужна возможность восстановления на точку во времени — настройте регулярный бэкап журнала (BACKUP LOG). После бэкапа место внутри .ldf освобождается.
3. Только после этого ужмите файл:

DBCC SHRINKFILE (N'ИмяБазы_log', 1024);  -- целевой размер в МБ

4. Если точечное восстановление не требуется, можно перевести базу в простую модель:

ALTER DATABASE [ИмяБазы] SET RECOVERY SIMPLE;

Для PostgreSQL прямого аналога нет: WAL-файлы платформа и СУБД обслуживают сами, а «раздувание» таблиц лечится регулярным VACUUM и настройкой автовакуума, а не ручным удалением логов.

Автоматизация: регулярная очистка по расписанию

Разовой чистки мало — без регламента файл разрастётся снова. Автоматизацию выстраивают отдельно для каждого типа логов.

Журнал регистрации. Встроенного ограничения по размеру у журнала нет. Варианты:

• 🔁 Снизить объём записываемого — методом УстановитьИспользованиеЖурналаРегистрации оставить только нужные классы событий (например, ошибки и вход, без рутинных операций). Это самый спокойный способ сдержать рост.
• 🗓️ Включить разделение по периодам (для формата 1Cv8Log) и по расписанию удалять старые файлы периодов средствами ОС.
• ⏱️ Периодически запускать «Сокращение» в нерабочее окно — вручную или скриптом запуска Конфигуратора в пакетном режиме.

Журнал транзакций SQL Server. Вот здесь SQL-автоматизация работает полноценно: настройте в SQL Server Agent задание с регулярным BACKUP LOG (например, раз в час) или план обслуживания с резервным копированием журнала. Файл перестанет расти, точечное восстановление сохранится.

Обслуживание после очистки: как реально уменьшить файл

Удаление записей не всегда уменьшает размер файла на диске. Финальный шаг — освобождение места.

• Для 1Cv8.lgd (SQLite): после массового DELETE выполните VACUUM; — файл сожмётся до фактического объёма данных.
• Полное обнуление через удаление файла сразу даёт минимальный размер: платформа создаёт пустой журнал.
• Для .ldf в SQL Server: сначала бэкап журнала, затем DBCC SHRINKFILE. Без бэкапа shrink почти ничего не даст.

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

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