Как убрать записи «Сеанс Завершен» и очистить Журнал Регистрации в 1С 8.3

В процессе эксплуатации высоконагруженных систем на платформе 1С:Предприятие 8.3 многие администраторы сталкиваются с проблемой стремительного роста Журнала Регистрации (ЖР). Особенно это актуально для баз в формате .lgd (SQLite), где частое выполнение фоновых заданий генерирует тысячи записей «Сеанс завершен», «Сеанс начат» и транзакционных меток. Это не только занимает дисковое пространство, но и приводит к критической загрузке процессора (до 95-100%) при попытке системы записать новые данные или открыть журнал.

В данной статье мы разберем, почему стандартные программные методы часто не работают, и рассмотрим эффективные способы очистки журнала с использованием инструментов SQLite и PowerShell.

Почему не помогает стандартный код 1С

Попытки программно отключить регистрацию событий через встроенный язык 1С, например, с помощью функции УстановитьИспользованиеСобытияЖурналаРегистрации("_$Session$_.Finish", ...), часто оказываются тщетными. Проанализируем причину: события начала и завершения сеанса, а также фиксации транзакций, являются системными событиями низкого уровня. Платформа 1С регистрирует их еще до того, как начнет исполняться какой-либо программный код или сразу после его завершения. В версиях 8.3.x эти события жестко «вшиты» в логику работы сервера, и если уровень логирования в настройках базы позволяет записывать сеансы, они будут записываться вопреки программным запретам.

Способ 1: Удаление записей через утилиту SQLite3

Если файл вашего журнала регистрации 1cv8.lgd уже разросся до нескольких гигабайт, и стандартные средства «Настройки журнала регистрации» в Конфигураторе виснут, мы можем прибегнуть к прямому редактированию базы данных SQLite. Рассмотрим этот процесс по шагам.

Подготовительный этап:

1. Остановите службу сервера 1С:Предприятия или временно снимите базу с регистрации, чтобы файл 1cv8.lgd не был занят процессом rphost.
2. Сделайте резервную копию файла 1cv8.lgd. Это критически важно, так как любые прямые манипуляции с БД могут повредить структуру.
3. Скачайте официальные инструменты SQLite (sqlite3.exe).

Процесс очистки:

Запустите sqlite3.exe и выполните подключение к файлу журнала:

.open 1cv8.lgd

Теперь нам нужно выяснить внутренние идентификаторы (коды), которые платформа присвоила событиям и приложениям. Выясним код для фоновых заданий:

SELECT * FROM AppCodes WHERE name LIKE '%Background%';

Допустим, вы получили результат 2|"BackgroundJob". Запомним, что appCode = 2.

Аналогично найдем коды событий начала, фиксации и завершения транзакций, которые обычно создают основной объем «шума»:

SELECT * FROM EventCodes WHERE name LIKE '%Transaction%';

После того как коды получены (например, коды событий 2, 3 и 4), выполним удаление лишних записей, связанных именно с фоновыми заданиями на конкретном сервере:

DELETE FROM EventLog WHERE (eventCode=2 OR eventCode=3 OR eventCode=4) AND appCode=2;

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

VACUUM;

Проанализируем ситуацию: команда VACUUM на больших файлах (более 10 Гб) может выполняться длительное время и требовать двойного объема свободного места на диске для временных операций.

Способ 2: Ускоренная очистка через PowerShell и создание новой базы

Когда файл журнала достигает объема 20-40 Гб, обычное удаление (DELETE) работает крайне медленно. В этом случае эффективнее создать новый файл базы данных и перенести в него только нужные записи, пропуская мусор от фоновых заданий. Разберем, как автоматизировать это с помощью PowerShell.

Для работы скрипта потребуется библиотека System.Data.SQLite.dll. Убедитесь, что она установлена в системе или лежит рядом со скриптом.

Алгоритм работы скрипта:

1. Подключение библиотеки SQLite в сессию PowerShell.
2. Создание пустого файла 1cv9.lgd (будущий оптимизированный журнал).
3. Присоединение (ATTACH) старого тяжелого файла к новому в качестве внешнего источника.
4. Копирование справочников (имена пользователей, компьютеров, метаданные) «как есть».
5. Выборочное копирование основной таблицы EventLog с фильтрацией ненужных eventCode и appCode.

Пример ключевой части SQL-запроса внутри скрипта, который выполняет перенос:

CREATE TABLE EventLog AS 
SELECT * FROM v8.EventLog 
WHERE NOT (
    (eventCode IN (select code from v8.EventCodes where name like '%Finish%')) 
    AND appCode = (select code from v8.AppCodes where name = 'BackgroundJob')
);

Такой подход позволяет сократить время обработки 20 Гб журнала до 5-10 минут, так как операция вставки (INSERT) в новую таблицу в SQLite работает на порядки быстрее, чем удаление со смещением строк в существующей огромной таблице.

Важный нюанс: Восстановление индексов

Просто скопировать данные недостаточно. При подмене старого файла новым, 1С может выдать ошибку sqlite3_exec failed: attempt to write a readonly database или сообщить о повреждении формата. Это происходит потому, что платформа ожидает наличия определенных индексов в файле SQLite. Выясним, какие индексы необходимо создать вручную, если они не были перенесены:

CREATE INDEX IF NOT EXISTS EventLog_idx_date ON EventLog (date);
CREATE INDEX IF NOT EXISTS EventLog_idx_appCode ON EventLog (appCode);
CREATE INDEX IF NOT EXISTS EventLog_idx_eventCode ON EventLog (eventCode);
CREATE INDEX IF NOT EXISTS EventLog_idx_computerCode ON EventLog (computerCode);
CREATE INDEX IF NOT EXISTS EventLog_idx_userCode ON EventLog (userCode);

Без этих индексов поиск по журналу в интерфейсе «1С:Предприятия» будет практически невозможен, а сама платформа может вести себя нестабильно.

Рекомендации по предотвращению разрастания журнала

Чтобы не прибегать к ручной чистке базы каждые несколько месяцев, проанализируем настройки системы и предпримем профилактические меры:

1. Разделение хранения журнала: В настройках журнала регистрации (в Конфигураторе) установите опцию «Разделять хранение по периодам» (например, по дням или неделям). В этом случае вместо одного гигантского .lgd файла 1С будет создавать множество мелких, которые гораздо проще архивировать и удалять стандартными средствами ОС.
2. Настройка уровня детализации: Если вам не нужна детальная история того, когда завершилось каждое из сотен фоновых заданий, снизьте уровень регистрации событий до «Ошибки, предупреждения, информация», исключив «Примечания».
3. Исключения антивируса: Убедитесь, что папка srvinfo и файлы .lgd добавлены в исключения антивирусного ПО на сервере. Постоянная запись в SQLite-базу в сочетании со сканированием «на лету» — главная причина 100% загрузки диска и процессора.
4. Параметры SQLite: При выполнении скриптов очистки используйте команды PRAGMA synchronous = OFF; и PRAGMA journal_mode = MEMORY;. Это ускорит работу с базой в несколько раз, жертвуя отказоустойчивостью только на время выполнения скрипта.

Используя данные методы, вы сможете поддерживать работоспособность системы даже при интенсивном использовании фоновых механизмов в 1С 8.3.