Многие администраторы и разработчики 1С сталкиваются с проблемой, когда стандартный журнал регистрации (ЖР) в формате SQLite (файл 1Cv8.lgd) разрастается до огромных размеров. Это приводит к тому, что попытка просто открыть журнал или построить по нему отчет вызывает длительные зависания системы, блокировки и недовольство пользователей. В рамках данной статьи мы разберем продвинутый метод решения этой задачи: выгрузку данных из SQLite во внешнюю базу данных SQL с последующим подключением через механизм Внешних источников данных и выводом в отчет на СКД.
Прежде чем перейти к решению, проанализируем причину проблемы. Начиная с версии платформы 8.3.5, 1С по умолчанию использует формат SQLite для хранения событий. Несмотря на его надежность, он имеет ряд ограничений в контексте 1С:
SQLite плохо справляется с одновременной интенсивной записью и чтением. Когда сервер 1С активно пишет логи, попытка прочитать их внешним запросом может вызвать ошибку Database is locked..lgd индексы оптимизированы под стандартную форму просмотра, но не под сложные аналитические выборки.Рассмотрим стратегию, которая позволяет обойти эти ограничения. Основная идея заключается в создании "прослойки" между живым журналом регистрации и аналитическим отчетом. Разберем по шагам, как это реализовать.
Шаг 1: Подготовка внешней базы данных
Для начала нам понадобится база данных на MS SQL Server, PostgreSQL или ClickHouse. Последний вариант считается наиболее современным и эффективным для хранения миллиардов строк логов, так как ClickHouse обеспечивает колоссальное сжатие данных и мгновенный поиск.
Шаг 2: Организация процесса выгрузки (ETL)
Мы не должны читать "живой" файл 1Cv8.lgd напрямую во время активной работы пользователей. Правильнее всего использовать следующий алгоритм:
1Cv8.lgd и сопутствующего ему файла 1Cv8.lgd-wal во временную папку. Файл -wal (Write-Ahead Log) критически важен, так как в нем содержатся последние записи, еще не перенесенные в основной файл.OneScript или на языке 1С с использованием внешних компонент) для чтения данных из скопированного SQLite файла.Рассмотрим пример логики, которую можно реализовать в процедуре выгрузки:
// Пример логики определения последней выгруженной записи
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ МАКСИМУМ(ДатаСобытия) ИЗ ВнешнийИсточникДанных.ЖурналSQL.События";
Результат = Запрос.Выполнить();
ДатаПоследнейЗаписи = Результат.Выгрузить()[0].ДатаСобытия;
// Далее открываем SQLite файл через ADO или специализированную компоненту
// и выбираем записи, где Дата > ДатаПоследнейЗаписи
Проанализируем внутреннюю структуру файла 1Cv8.lgd. Чтобы ваш отчет в 1С был читаемым, недостаточно перенести только таблицу событий. Вам потребуется собрать данные из нескольких связанных таблиц:
EventLog — сами записи событий.Metadata — идентификаторы объектов метаданных (справочники, документы).UserCodes — сопоставление кодов пользователей с их именами и UUID.ComputerCodes — имена компьютеров.EventCodes — типы событий (Данные.Изменение, Сеанс.Начало и т.д.).При переносе в SQL рекомендуется сразу соединять эти таблицы (делать JOIN), чтобы в базе-приемнике хранились уже понятные строки (имя пользователя, название документа), а не числовые идентификаторы. Это значительно ускорит работу СКД в будущем.
После того как данные начали регулярно поступать в SQL-базу, нам нужно вернуть их в интерфейс 1С для пользователей (например, для бухгалтеров или аудиторов). Выясним, как это сделать максимально эффективно:
View, созданную на стороне SQL), которая содержит данные журнала.Дата и УникальныйИдентификатор.Теперь вы можете использовать эту таблицу в обычном запросе или как набор данных в Схеме компоновки данных (СКД). Пользователь сможет накладывать любые фильтры, и поиск будет происходить мгновенно средствами SQL-сервера, не нагружая рабочую базу 1С.
Если разработка собственной системы выгрузки кажется слишком трудоемкой, рассмотрим встроенный механизм платформы, о котором упоминалось в обсуждении. В настройках журнала регистрации можно выбрать режим "Разделять хранение по периодам" (недели или месяцы).
В этом случае система создает множество мелких файлов .lgp (для старого формата) или управляет сегментами в новом формате. Это облегчает архивирование старых данных (их можно просто перенести в другое хранилище), однако не решает проблему медленного поиска по всему периоду сразу. Именно поэтому вариант с SQL-базой остается приоритетным для крупных систем.
При реализации выгрузки в SQL обратите внимание на следующие моменты:
Дата, Пользователь и ОбъектМетаданных в вашей внешней базе. В стандартном ЖР 1С вы не можете управлять индексами, а здесь — это ваш главный инструмент ускорения..lgd, всегда проверяйте наличие .lgd-wal. Если он есть, его нужно копировать в ту же папку, иначе база SQLite может считаться поврежденной или данные будут неактуальными.Таким образом, доработка журнала регистрации через внешний SQL-источник — это надежный способ обеспечить прозрачный и быстрый аудит системы без ущерба для производительности основной базы данных. Рассмотрим этот путь как инвестицию в стабильность работы крупной информационной системы.