При переходе на новые версии платформы 1С или при длительной работе базы размер файла журнала регистрации 1Cv8.lgd может превысить десятки гигабайт. При попытке открыть такой файл (например, объемом более 9 ГБ) через штатное меню Конфигуратора, программа часто зависает, так как пытается построить временные индексы, исчерпывая лимиты оперативной памяти и места на диске. Разберем по шагам, как решить эту проблему и проанализировать данные с помощью прямого доступа к SQLite.
Проанализируем ситуацию: формат .lgd — это база данных SQLite. Когда мы пытаемся открыть большой файл средствами 1С, платформа начинает обработку и построение временных индексов в папке пользователя %TEMP%. Если места на системном диске мало, или файл остался в состоянии незакрытой транзакции (рядом лежат файлы -wal или -shm), 1С может уйти в бесконечное чтение. Важно помнить: никогда не удаляйте вспомогательные файлы -wal и -shm, так как они содержат незаписанные данные журнала.
Откажемся от штатных средств 1С и рассмотрим использование внешних утилит (например, DB Browser for SQLite, DBeaver или консольной sqlite3). Внешний менеджер открывает базу без попыток загрузить ее в память платформы 1С, что позволяет работать даже с файлами по 200 ГБ.
Однако в таблицах SQLite данные хранятся в нормализованном виде. Основная таблица EventLog содержит лишь идентификаторы. Чтобы вместо цифр увидеть осмысленные данные, разберем структуру связанных таблиц:
Чтобы получить читаемый отчет, нам необходимо связать эти таблицы в SQL-запросе с помощью оператора LEFT JOIN.
Посмотрим на пример работы с датами в журнале 1С. В SQLite-версии время хранится как число микросекунд, прошедших с 0001 года. Обычные средства SQLite не смогут автоматически привести это значение к привычному виду. Выясним, как преобразовать это в удобочитаемый формат.
Мы применим формулу приведения к Unix-времени. Для этого поделим значение на миллион (перевод в секунды) и вычтем константу разницы между эрами 1С и Unix. Рассмотрим код SQL-запроса:
SELECT
datetime(e.date/1000000 - 62135596800, 'unixepoch') AS EventTime,
c.name AS EventType,
u.name AS UserName
FROM EventLog e
LEFT JOIN EventCodes c ON e.eventCode = c.code
LEFT JOIN Users u ON e.user = u.code
LIMIT 1000;
Чтобы ускорить выполнение запросов к файлу на 9+ ГБ, проанализируем возможности оптимизации. По умолчанию в файле может не быть нужных индексов. Сделаем следующее:
CREATE INDEX IF NOT EXISTS idx_eventlog_date ON EventLog(date);
PRAGMA cache_size = 1000000;
PRAGMA temp_store = MEMORY;
PRAGMA journal_mode = OFF;
Команда journal_mode = OFF отключит ведение журнала транзакций SQLite, что значительно ускорит процесс чтения (используйте только если вы не планируете изменять данные журнала).
Часто в логах мы видим записи по удаленным объектам. В таблице EventLog в колонке data хранится навигационная ссылка (UUID) в двоичном виде. Обратим внимание на колонку metadata. Она содержит ссылку на таблицу Metadata, по которой можно узнать тип объекта (например, «Справочник.Номенклатура»). Сопоставив тип объекта и его UUID, мы сможем найти удаленный элемент в архивной копии базы 1С.
Если нет желания писать SQL-запросы, рассмотрим альтернативное решение. Платформа 1С позволяет конвертировать внешний журнал в формат XML через командную строку. Это разгрузит конфигуратор от интерфейсных подвисаний. Используем параметр запуска DumpEventLog:
1cv8.exe DESIGNER /F"C:\Path\To\EmptyBase" /DumpEventLog "C:\ExportedLog.xml" /LogFile "C:\Path\To\1Cv8.lgd"
Для выполнения этой команды потребуется пустая файловая база 1С. Выгруженный XML файл можно в дальнейшем распарсить скриптом или открыть специальными текстовыми редакторами, способными обрабатывать гигантские файлы. Выбирайте тот инструмент, который лучше всего подходит под ваши задачи и объем ресурсов.