Почему не уменьшается размер файла журнала регистрации 1Cv8.lgd после сокращения и как его сжать?

При активной эксплуатации информационных баз 1С журнал регистрации быстро разрастается до десятков гигабайт. При выполнении штатной процедуры сокращения журнала (через Конфигуратор или вызовом метода платформы) администраторы часто сталкиваются с ситуацией, когда записи за выбранный период удалены, но физический размер файла 1Cv8.lgd на диске остался прежним. Разберем внутренние механизмы платформы, выясним причину такого поведения и рассмотрим проверенные способы уменьшения объема журнала регистрации.

Почему размер файла не уменьшается автоматически

Проанализируем архитектуру хранения данных. Начиная с платформы 1С:Предприятие 8.3, новый формат журнала регистрации реализован на базе компактной реляционной СУБД SQLite. Все события записываются в единый файл 1Cv8.lgd.

Когда мы выполняем штатное сокращение журнала, внутри базы данных SQLite происходит удаление строк таблиц. Однако архитектура СУБД устроена так, что освободившиеся страницы данных не возвращаются операционной системе. Они лишь помечаются как свободные внутри структуры самого файла базы данных. Это штатное поведение: при дальнейшей работе 1С будет повторно использовать эти зарезервированные блоки для записи новых событий, и файл не будет увеличиваться в размерах до тех пор, пока весь очищенный объем не заполнится новыми логами.

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

Способ 1. Принудительное сжатие утилитой sqlite3 (команда VACUUM)

Рассмотрим основной способ физического уменьшения размера файла 1Cv8.lgd без потери оставшихся актуальных записей. Для этого используется штатная команда СУБД SQLite — VACUUM. Она перестраивает базу данных с нуля, копируя только полезные данные в новый временный файл, полностью исключая пустые страницы.

Разберем процесс выполнения процедуры по шагам:

1. Завершаем блокирующие процессы. Команда сжатия требует монопольного доступа к файлу. При наличии активных подключений возникнет ошибка блокировки (database is locked). Для клиент-серверной базы останавливаем службу «Агент сервера 1С:Предприятия», для файловой базы — завершаем все пользовательские сеансы и фоновые задания.
2. Проверяем свободное место на диске. Механизм команды VACUUM создает полную временную копию базы данных. На диске должно быть доступно не менее 100% от текущего объема файла 1Cv8.lgd (например, если файл весит 22 ГБ, свободно должно быть минимум 22–25 ГБ).
3. Проверяем служебные файлы транзакций. Убеждаемся, что файлы 1Cv8.lgd-wal и 1Cv8.lgd-shm закрыты и их данные корректно сброшены в основной файл после остановки службы 1С.
4. Запускаем утилиту SQLite. Скачиваем консольную утилиту sqlite3.exe с официального сайта разработчика и помещаем в каталог с файлом журнала либо запускаем командную строку.
5. Выполняем сжатие. В командной строке выполняем следующую инструкцию:

sqlite3.exe "C:\1Cv8Log\1Cv8.lgd" "VACUUM;"

Дожидаемся окончания процесса (для больших файлов размером свыше 20 ГБ операция может занять продолжительное время в зависимости от скорости дисковой подсистемы). После завершения размер файла 1Cv8.lgd уменьшится до реального объема содержащихся в нем данных. После этого запускаем службу сервера 1С.

Способ 2. Быстрая ротация и инициализация нового журнала

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

1. Останавливаем службу кластера серверов 1С или закрываем сеансы файловой базы.
2. Переходим в каталог журнала регистрации (1Cv8Log в каталоге базы данных или каталоге кластера серверов).
3. Перемещаем файл 1Cv8.lgd (вместе с файлами -wal и -shm, если они остались) в архивную папку или на резервный накопитель.
4. Запускаем службу 1С:Предприятия. При старте платформа автоматически создаст чистый файл 1Cv8.lgd минимального начального размера.

При возникновении необходимости расследования старых инцидентов архивный файл журнала можно открыть непосредственно в Конфигураторе через меню Файл — Открыть или подключить к тестовой копии базы.

Способ 3. Переход на разделенный (текстовый) формат журнала

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

Преимущества такого подхода:

1. Удаление или архивирование устаревших логов сводится к простому удалению старых файлов .lgp из файловой системы без необходимости остановки сервера и процедур сжатия.
2. Физическое место на диске освобождается мгновенно.

Для смены формата перейдем в Конфигуратор, откроем меню Администрирование — Настройка журнала регистрации и нажмем кнопку изменения формата хранения событий. Процесс конвертации выполнится штатно средствами платформы.

Рекомендации по автоматизации и контролю объема

Для предотвращения неконтролируемого разрастания журнала в будущем настроим регулярное обслуживание и скорректируем уровень детализации:

1. Настройка уровня событий. В диалоге настройки журнала регистрации имеет смысл отключить избыточное логирование некритичных событий (например, регистрацию успешных запусков регламентных заданий и чисто информационных сообщений), оставив фиксацию только предупреждений, ошибок и критических действий пользователей.
2. Автоматическое сокращение по расписанию. Настроим регулярный запуск Конфигуратора в пакетном режиме с ключом /ReduceEventLogSize через планировщик задач Windows для периодической отсечки устаревших записей по дате:

"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /S "ServerName\BaseName" /N "Admin" /P "Password" /ReduceEventLogSize 2024-01-01 /Out "C:\Logs\reduce.log"

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