В процессе эксплуатации систем на платформе 1С:Предприятие 8.3 администраторы иногда сталкиваются с парадоксальной ситуацией: при анализе журнала регистрации выясняется, что огромное количество записей за прошлые периоды отображается серым цветом со статусом «Отменена». При этом проверка в самой информационной базе показывает, что документы проведены, записи в регистрах присутствуют, и фактически транзакции были успешно зафиксированы в MS SQL Server. Рассмотрим подробнее, почему возникает этот программный диссонанс и как восстановить корректное отображение логов.
Для начала проанализируем, как 1С записывает события в современном формате .lgd. В отличие от старого текстового формата .lgf, новый формат базируется на СУБД SQLite. Процесс фиксации события разделен на два этапа:
1Cv8.lgd. На этом этапе статус транзакции помечается как «Не завершена».MS SQL Server или другая СУБД подтвердит успешный COMMIT транзакции, менеджер журнала регистрации отправляет в файл SQLite команду на обновление статуса записи на «Зафиксирована».Выясним причину сбоя: если между этими двумя шагами происходит микросекундная задержка, блокировка файла или аварийное завершение рабочего процесса rphost, статус в журнале регистрации так и остается «Не завершена». Платформа при чтении такого лога интерпретирует это состояние как «Отменена» и окрашивает строку в серый цвет.
В версиях платформы 8.3.8 (включая сборку 1964) механизмы работы с SQLite были еще недостаточно оптимизированы. Рассмотрим основные факторы риска:
SQLite — это файловая база данных, в момент записи статуса 1С требует монопольного доступа к определенным страницам файла .lgd. Если в этот момент антивирус сканирует каталог srvinfo, команда обновления статуса может быть проигнорирована платформой без вывода ошибки пользователю.Рассмотрим случай, когда проблема проявляется «со временем» или после переноса системы на новый сервер (например, с Windows Server 2008 на 2012). При копировании активного файла журнала регистрации без остановки службы 1C:Enterprise Server часто возникает нарушение целостности индексов SQLite.
Выясним, почему записи «сереют» не сразу. Платформа 1С динамически вычисляет цвет записи в момент открытия формы журнала регистрации. Если индексы в файле .lgd повреждены, запрос на выборку статусов транзакций может возвращать некорректные или пустые значения для старых периодов. В результате те записи, которые вчера выглядели «черными», сегодня могут отобразиться как «серые», так как связь между идентификатором события и статусом транзакции была потеряна в структуре SQLite.
Для восстановления корректной работы журнала регистрации и предотвращения «посерения» будущих записей, выполним следующие действия:
Поскольку журнал регистрации — это база SQLite, мы можем проверить ее состояние стандартными средствами. Для этого нам понадобится утилита sqlite3.exe.
Выполним команду в консоли:
sqlite3 1Cv8.lgd "PRAGMA integrity_check;"
Если в ответ вы получите что-либо, кроме ok, файл поврежден. В этом случае рекомендуется пересоздать журнал или попытаться выполнить REINDEX.
Проанализируем настройки безопасности сервера. Необходимо в обязательном порядке исключить из проверки антивирусом (особенно в режиме реального времени) следующие объекты:
C:\Program Files\1cv8\srvinfo)..lgd, .lgp, .lgf.SQLite (с суффиксами -journal или -wal).Разберем, как уменьшить нагрузку на файл. Чем больше размер 1Cv8.lgd, тем выше вероятность ошибок записи статуса транзакции. Рекомендуется настроить разделение журнала по периодам (например, по дням или неделям) в настройках информационной базы в консоли администрирования кластера 1С.
Это позволит системе работать с файлами меньшего объема, что значительно снижает вероятность возникновения блокировок SQLite.
Если специфика вашей работы (например, массовые транзакции в УПП) приводит к постоянным сбоям SQLite, можно рассмотреть возврат к старому формату .lgf. Для этого при создании базы или в параметрах существующей (путем редактирования конфигурационных файлов) можно указать использование текстового формата.
Однако стоит помнить, что текстовый формат работает медленнее при поиске и фильтрации больших объемов данных.
Проанализируем техническую политику компании. Версия 8.3.8.1964 содержит критические недоработки в части управления транзакциями лога. Рекомендуется выполнить обновление платформы как минимум до версий ветки 8.3.12 или выше. В этих релизах фирма «1С» существенно переработала механизм взаимодействия с файловыми базами данных, улучшив стабильность записи статусов при высоких нагрузках.
Иногда причиной может быть слишком быстрая фиксация транзакций в SQL при медленной дисковой системе, где лежит журнал. Проверьте параметр Delayed Durability в настройках MS SQL Server. Если он включен, это может создавать рассинхронизацию между моментом, когда 1С считает транзакцию завершенной, и физической записью данных, что косвенно влияет на логику менеджера логов 1С.
Таким образом, «посерение» записей — это в большинстве случаев информационная ошибка лога, а не потеря данных в основной базе. Правильная настройка инфраструктуры и своевременное обслуживание файлов SQLite позволят сохранить достоверность аудита системы.