Журнал регистрации 1С (ЖР) — один из важнейших инструментов для аудита действий пользователей и расследования технических сбоев. Однако при высокой интенсивности работы базы данных его объем может лавинообразно увеличиваться. Ситуации, когда файл лога разрастается до 100, 200 или даже 400 ГБ — далеко не редкость в крупных организациях. Работа с таким гигантским файлом стандартными средствами превращается в кошмар: Конфигуратор зависает, выгрузка данных идет часами, а дисковая подсистема испытывает колоссальные нагрузки.
В этой статье мы подробно разберем, как правильно подойти к задаче обрезки журнала регистрации, выясним требования к монопольному режиму, проанализируем разницу в форматах логов и составим безопасный пошаговый план оптимизации дискового пространства без долгого простоя рабочих процессов.
Начнем с главного вопроса, который волнует каждого администратора: можно ли выполнить сокращение ЖР «на лету», когда в базе работают пользователи?
Ответ однозначный: штатное сокращение журнала регистрации требует монопольного доступа к базе данных.
Если мы попытаемся выполнить процедуру через Конфигуратор (меню «Администрирование» — «Настройка журнала регистрации» — кнопка «Сократить») или запустим пакетный режим утилиты командной строки с параметром /ReduceEventLogSize, система потребует эксклюзивную блокировку. В файловом варианте не должно быть ни одного активного сеанса. В клиент-серверном варианте активные транзакции пользователей также заблокируют выполнение этой операции. Пытаться «резать» 400-гигабайтный рабочий файл в монопольном режиме в рабочее время — критическая ошибка, которая приведет к многочасовому простою компании.
Прежде чем приступать к активным действиям, нам необходимо выяснить, в каком формате ведется запись событий в нашей системе. От этого зависят дальнейшие шаги. Платформа 1С:Предприятие 8.3 поддерживает два формата хранения:
1Cv8.lgd). Этот формат появился в платформе версии 8.3.5. Все данные пишутся в одну монолитную базу данных SQLite.
Особенность: Настройка разделения журнала по периодам (дням, неделям, месяцам) здесь недоступна. База всегда хранится в одном файле. Самый главный подводный камень формата SQLite заключается в том, что после удаления записей (даже успешного сокращения через Конфигуратор) размер файла на диске физически не уменьшается. Чтобы вернуть свободное место операционной системе, необходимо выполнять процедуру сжатия базы данных — VACUUM.
1Cv8.lgf и файлы данных .lgp). Начиная с версии платформы 8.3.12, компания 1С вернула этот текстовый формат в качестве рекомендуемого по умолчанию из-за частых проблем с производительностью и блокировками SQLite на высоконагруженных системах.
Особенность: В этом формате журнал отлично разбивается физически на файлы по периодам (например, каждый день или каждый месяц создается новый файл с расширением .lgp). Это позволяет безболезненно удалять или переносить старые архивные периоды обычными средствами операционной системы, не заходя в Конфигуратор.
Если перед нами стоит задача очистить журнал объемом в несколько сотен гигабайт, попытка использовать стандартную кнопку «Сократить» в Конфигураторе почти гарантированно приведет к зависанию процесса, переполнению диска временными файлами и сбою. Мы пойдем другим, гораздо более безопасным и быстрым путем, который потребует остановки базы всего на несколько минут.
Наш план состоит из двух ключевых этапов: быстрый запуск нового чистого журнала на рабочей базе и последующая обработка старого гигантского архива в офлайн-режиме.
Проанализируем шаги, которые позволят нам мгновенно освободить рабочую базу от тяжелого лога:
C:\Program Files\1cv8\srvinfo\<Имя_кластера>\<Идентификатор_базы>\1Cv8Log
1Cv8Log на другой физический диск — например, на медленный архивный накопитель, где много свободного места. На основном быстром SSD-диске не должно остаться этого файла.1Cv8Log.1Cv8.lgf (обратите внимание на расширение). Когда платформа обнаружит этот файл-маркер, она автоматически начнет писать лог в старом формате..lgp. В конце года мы сможем просто скопировать файлы за прошедшие месяцы в архив, а из рабочей папки удалить их вручную без остановки системы!У нас остался перемещенный файл старого лога (допустим, это был файл нового формата 1Cv8.lgd). Нам нужно оставить из него только данные за 2018–2019 годы, а остальное удалить для экономии места. Теперь мы можем делать это абсолютно спокойно на любом свободном компьютере или тестовом сервере, не мешая пользователям.
Поскольку .lgd — это стандартная база данных SQLite, мы воспользуемся бесплатной и удобной утилитой DB Browser for SQLite или консольным клиентом sqlite3.exe.
Разберем по шагам процесс очистки через SQL-запросы:
1Cv8.lgd._$Transaction$_.Begin, _$Transaction$_.Commit, а также задачи фонового обмена).
DELETE FROM EventLog
WHERE Date < '2018-01-01 00:00:00'
OR Date >= '2020-01-01 00:00:00';
DELETE FROM EventLog
WHERE EventID IN (
SELECT EventID FROM EventIDTable
WHERE Name LIKE '_$Transaction$%'
);
1Cv8.lgd все еще весит 400 ГБ. Нам необходимо выполнить команду сжатия.VACUUM утилите потребуется создать временную копию файла. Это значит, что на диске, где выполняется процедура, должно быть свободно как минимум еще столько же места, сколько весит сам файл (в нашем случае — еще около 400 ГБ свободного пространства!). Убедитесь в наличии свободного места перед запуском команды.
VACUUM;
Используя предложенную методику, мы не только решили сиюминутную проблему с дисковым пространством и зависанием Конфигуратора, но и перевели систему на современный, легко обслуживаемый формат хранения логов, предотвратив подобные проблемы в будущем.