Почему журнал регистрации 1С перестал записывать новые события и как это исправить?

← На главную

В процессе администрирования баз данных «1С:Предприятие 8.3» можно столкнуться с ситуацией, когда журнал регистрации внезапно перестает фиксировать новые события. Чаще всего такое поведение наблюдается после аварийного отключения электропитания, внезапного падения сети или некорректного завершения работы процессов сервера 1С. При этом информационная база продолжает функционировать в штатном режиме, пользователи работают, но история действий не сохраняется либо новые записи не отображаются в интерфейсе.

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

Анализ причин сбоя

Начиная с версии платформы 8.3, журнал регистрации по умолчанию использует единую базу данных на движке SQLite (файл 1Cv8.lgd), функционирующую с механизмом упреждающей записи WAL (Write-Ahead Logging). Вместе с основным файлом создаются вспомогательные файлы 1Cv8.lgd-wal и 1Cv8.lgd-shm.

Выясним основные причины, приводящие к остановке записи:

Повреждение структуры SQLite или незафиксированная транзакция WAL: при резком обесточивании сервера данные из файла 1Cv8.lgd-wal не успевают перенестись в основной файл 1Cv8.lgd, из-за чего база журнала переходит в несогласованное состояние и блокирует новые операции вставки.
Файловые и монопольные блокировки: аварийно остановленный процесс кластера (rphost) или фоновый антивирусный монитор может удерживать дескрипторы файлов журнала.
Ошибки отображения и фильтрации: события фактически записываются на диск, но из-за сбоя индексов или повреждения заголовочных метаданных не выводятся в интерфейсе программы.

Шаг 1. Программная проверка записи в журнал

Для начала проверим, способна ли платформа 1С в текущем состоянии отправлять команды записи в журнал или возникает системная ошибка. Выполним проверочный запуск специального фрагмента кода во внешней обработке или через консоль кода:


Для Х = 1 По 10 Цикл
    Попытка
        ЗаписьЖурналаРегистрации("ТестоваяЗапись", УровеньЖурналаРегистрации.Информация, , , "Проверка фиксации события: " + Х);
    Исключение
        Сообщить("Ошибка записи: " + ОписаниеОшибки());
    КонецЦикла;

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

Шаг 2. Проверка настроек и фильтров журнала

Проверим базовые настройки отображения и регистрации:

Откроем Конфигуратор информационной базы.
Перейдем в главное меню: Администрирование → Настройка журнала регистрации.
Убедимся, что режим регистрации событий включен (выбран вариант «Регистрировать ошибки, предупреждения, информацию, примечания», а не отключен полностью). При необходимости перевыберем режим и применим изменения.
В режиме 1С:Предприятие откроем форму журнала регистрации и нажмем Установить отбор, после чего выполним сброс всех фильтров по периоду, пользователям и событиям.

Шаг 3. Быстрое восстановление работы пересозданием журнала

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

Остановим службу кластера серверов 1C:Enterprise Server Agent (служба ragent).
Перейдем в каталог расположения журнала конкретной базы: .../srvinfo/reg_xxxx/<GUID_базы>/1Cv8Log/.
Переместим существующий файл 1Cv8.lgd (а также временные файлы 1Cv8.lgd-wal и 1Cv8.lgd-shm, если они присутствуют) в отдельную архивную папку.
Запустим службу сервера 1С.

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

Шаг 4. Восстановление поврежденного файла SQLite без потери данных

Если архивные записи критически важны и их требуется сохранить в текущей базе, выполним процедуру восстановления структуры SQLite с помощью консольной утилиты sqlite3:

Остановим службу сервера 1С и сделаем резервную копию каталога 1Cv8Log.
В командной строке перейдем в каталог с файлом журнала и выполним проверку целостности:sqlite3 1Cv8.lgd "PRAGMA integrity_check;"
Если утилита сообщает об ошибках, выполним процедуру восстановления в новый файл:sqlite3 1Cv8.lgd ".recover" | sqlite3 1Cv8_new.lgd
Заменим исходный файл 1Cv8.lgd полученным файлом 1Cv8_new.lgd, удалив остаточные файлы -wal и -shm.
Запустим службу сервера 1С и проверим чтение и запись журнала.

Шаг 5. Конвертация формата журнала регистрации

Если оборудование сервера периодически подвергается сбоям электропитания, новый единый формат SQLite может регулярно повреждаться. В таких условиях более устойчивым решением является перевод журнала в старый текстовый формат (набор файлов .lgf и .lgp, разделенных по периодам). При повреждении одного текстового фрагмента остальные периоды остаются полностью доступными.

Конвертацию выполним в пакетном режиме запуска Конфигуратора через командную строку:

Для перевода в текстовый формат используем параметр /ConvertEventLogToTextFormat:
```
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" CONFIG /S "server-1c\base_name" /N "Admin" /P "Password" /ConvertEventLogToTextFormat
```
Если в будущем потребуется вернуть журнал обратно в формат SQLite, используем параметр /ConvertEventLogToSQLiteFormat:
```
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" CONFIG /S "server-1c\base_name" /N "Admin" /P "Password" /ConvertEventLogToSQLiteFormat
```

При конвертации платформа выполнит перенос всех накопленных записей в новый формат автоматически.