Журнал регистрации разросся на гигабайты: чистим и ставим лимиты
Содержание
Обрезать журнал регистрации 1С проще всего в Конфигураторе: Администрирование → Настройка журнала регистрации → Сократить. Указываете дату, все записи раньше неё удаляются, а при желании сохраняются в отдельный файл. Чтобы журнал больше не разрастался, в том же окне снижают уровень записи и включают разделение по периодам.
Способ одинаков для файловых и клиент-серверных баз, для Бухгалтерии, ЗУП и УТ: журнал регистрации — механизм платформы 1С:Предприятие 8.3, а не конкретной конфигурации. Разница только в том, где физически лежат файлы.
Почему журнал регистрации надо держать в рамках
Платформа пишет в журнал каждое событие: вход и выход пользователя, запись документа, ошибку, фоновое задание, обмен данными. В базе на 30 пользователей с регламентными заданиями за год набегает несколько гигабайт. Если в базе настроен обмен по расписанию раз в минуту, рост ещё быстрее.
Чем грозит раздутый журнал:
- 🐢 Медленное открытие журнала. Отбор за месяц по пользователю выполняется минутами, иногда форма просто зависает.
- 💾 Заканчивается место на диске. Для файловой базы журнал лежит рядом с
1Cv8.1CDи может весить больше самой базы. - 📦 Тяжёлые резервные копии. Если копируют всю папку базы или каталог
srvinfo, в архив уходят гигабайты старых событий. - ⏳ Долгий старт сеанса. При повреждённом или огромном файле журнала заметно тормозит вход в базу.
При этом журнал нельзя просто выключить. По нему разбирают, кто удалил документ, почему упал обмен, когда перестало работать регламентное задание. Задача — хранить разумный срок, а не ноль.
Где лежат файлы журнала и в каком они формате
Перед чисткой полезно увидеть, сколько места реально занято. Журнал хранится в отдельной папке 1Cv8Log.
| Тип базы | Где искать папку 1Cv8Log |
|---|---|
| Файловая | В каталоге базы, рядом с файлом 1Cv8.1CD |
| Клиент-серверная | На сервере 1С: srvinfo\reg_1541\<GUID базы>\1Cv8Log |
GUID базы для клиент-серверного варианта видно в консоли администрирования серверов 1С в свойствах информационной базы. Есть и быстрый способ: отсортировать папки внутри reg_1541 по дате изменения — у рабочей базы журнал меняется постоянно.
В 8.3 встречаются два формата журнала:
| Формат | Файлы | Как чистить |
|---|---|---|
| Последовательный (текстовый) | 1Cv8.lgf — словарь, *.lgp — сами события | Кнопкой «Сократить» или удалением старых .lgp |
| SQLite | Один файл 1Cv8.lgd | Только кнопкой «Сократить» |
Имя файла .lgp — это дата и время начала периода, например 20250101000000.lgp. Если включено разделение по месяцам, на каждый месяц будет свой файл. Это и позволяет удалять старые периоды целиком.
Файл 1Cv8.lgf не удаляйте, пока остаются .lgp. В нём хранятся словари: имена пользователей, компьютеров, метаданных. Без него старые записи перестанут читаться.
Сокращение журнала регистрации через Конфигуратор
Это штатный и самый безопасный способ. Он работает для обоих форматов и не требует доступа к файлам сервера.
- Запустите базу в режиме Конфигуратор под пользователем с правом администрирования.
- Откройте
Администрирование → Настройка журнала регистрации. - Нажмите кнопку Сократить.
- В поле даты укажите границу: записи раньше этой даты будут удалены. Например, чтобы оставить последние 6 месяцев на 1 октября, ставьте 1 апреля.
- Если старые события могут понадобиться, отметьте сохранение удаляемых записей в файл и выберите папку на диске с запасом места.
- Подтвердите. На журнале в несколько гигабайт операция занимает от минут до часа, Конфигуратор в это время не отвечает — это нормально, не закрывайте его.
Не прерывайте сокращение через диспетчер задач. Оборванная операция может оставить журнал в повреждённом состоянии, и тогда его придётся пересоздавать с потерей всех записей.
Запускайте сокращение вечером или в выходные. Пользователи продолжают работать, но сама операция активно читает и пишет файлы журнала, на загруженном сервере это заметно.
Как выбрать дату границы:
- 📅 3 месяца — небольшая база, разбор инцидентов обычно идёт «по горячим следам».
- 📅 6–12 месяцев — типичный вариант для бухгалтерии, хватает, чтобы найти, кто правил документы закрытого квартала.
- 📅 Больше года — если служба безопасности или внутренний регламент требуют хранить историю действий дольше. Тогда лучше не держать всё в рабочем журнале, а выгружать архив в файл.
Как настроить хранение, чтобы журнал не разрастался снова
Одной чистки мало: через год журнал вернётся к прежнему размеру. В том же окне Администрирование → Настройка журнала регистрации есть две настройки, которые решают проблему надолго.
Уровень регистрации событий
Переключатель «Регистрировать в журнале» задаёт, какие события попадают в журнал. Каждый следующий уровень включает предыдущие.
| Уровень | Что пишется | Когда выбирать |
|---|---|---|
| Не регистрировать | Ничего | Почти никогда: теряется возможность разбора |
| Ошибки | Только ошибки | Большие базы, где журнал критично разросся |
| Предупреждения | Ошибки и предупреждения | Компромисс по объёму |
| Информация | Плюс вход/выход, запись данных | Обычный рабочий режим |
| Примечания | Всё подряд | Временно, на время поиска проблемы |
Основной объём дают именно информационные события и примечания. Переход с «Примечаний» на «Информацию» часто сокращает прирост в разы. Отказ от «Информации» экономит ещё больше, но тогда в журнале не будет записей о том, кто и когда изменил документ.
Разделение журнала по периодам
Параметр «Разделять журнал по периодам» действует для последовательного формата. Варианты — от отсутствия разделения до отдельных файлов на год, месяц, день или час (набор зависит от версии платформы).
Для большинства баз подходит «по месяцам»:
- каждый месяц — отдельный
.lgp-файл, удобно видеть, сколько весит период; - старые месяцы удаляются целиком, без запуска Конфигуратора;
- файл текущего месяца небольшой, журнал открывается быстрее.
«По дням» имеет смысл для баз с очень активными обменами, где один месяц весит гигабайты.
Регламент: как часто проверять размер журнала
Удобный ритм — раз в квартал смотреть размер папки 1Cv8Log у каждой базы и сравнивать с прошлой проверкой. Если прирост за квартал резко вырос, значит, появился новый источник событий: обмен, который падает с ошибкой, или фоновое задание, запущенное слишком часто.
Мини-пример. База Бухгалтерии на 25 пользователей, журнал за два года занял 18 ГБ. После сокращения до 6 месяцев осталось около 4 ГБ. Уровень снизили с «Примечаний» до «Информации», включили разделение по месяцам. Месячный файл стал весить 300–400 МБ, и раз в квартал администратор удаляет файлы старше года по списку.
Удаление старых файлов журнала на сервере
Когда журнал разделён по периодам, администратор может обрезать его без Конфигуратора — удалением старых .lgp. Это быстрее на больших объёмах, но требует аккуратности.
Порядок действий:
- Откройте папку
1Cv8Logнужной базы (см. таблицу выше). - Отсортируйте файлы
.lgpпо имени — это и есть хронология. - Скопируйте файлы, которые собираетесь удалить, в архив, если история может понадобиться.
- Удалите файлы периодов старше нужной границы. Файл текущего периода и
1Cv8.lgfне трогайте. - Откройте журнал регистрации в 1С и проверьте, что свежие записи читаются.
Если файл не удаляется с сообщением, что он занят другим процессом, им пользуется рабочий процесс сервера 1С. Не трогайте такие файлы, кроме текущего периода их обычно нет. Остановка службы сервера 1С освобождает все файлы, но при остановке службы обрываются сеансы всех пользователей всех баз на этом сервере. Делайте это только в согласованное нерабочее окно и после предупреждения пользователей.
Удаление можно автоматизировать скриптом по расписанию. Пример для PowerShell: удалить .lgp старше 365 дней в папке журнала одной базы.
$log = "D:\srvinfo\reg_1541\<GUID базы>\1Cv8Log"
Get-ChildItem -Path $log -Filter *.lgp |
Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-365) } |
Remove-Item -WhatIf
Ключ -WhatIf только показывает, что будет удалено. Убедитесь, что список правильный, и уберите его. Путь к папке подставьте свой.
Для формата SQLite (1Cv8.lgd) этот способ не подходит: все события в одном файле. Удалить его можно, только смирившись с потерей всего журнала. Сокращайте такой журнал кнопкой «Сократить».
Обработки и код для работы с журналом
На форумах предлагают десятки внешних обработок «для очистки журнала». Тут два риска. Первый — обработка из неизвестного источника выполняется с правами администратора в рабочей базе. Второй — встроенный язык не даёт удалять отдельные записи журнала, поэтому такие обработки обычно делают другое: выгружают журнал в файл, меняют уровень регистрации или показывают статистику.
Что реально можно сделать кодом:
- 📤 Выгрузить архив. Метод
ВыгрузитьЖурналРегистрации()сохраняет записи в файл с отбором по дате, пользователю, событию. Удобно перед сокращением, если нужна выборка, а не весь журнал. - ⚙️ Изменить уровень регистрации. Методы
ПолучитьИспользованиеЖурналаРегистрации()иУстановитьИспользованиеЖурналаРегистрации()позволяют переключать уровни программно, например включать подробную запись на время отладки обмена.
Пример выгрузки записей за период в файл:
Отбор = Новый Структура;
Отбор.Вставить("ДатаНачала", '20250101000000');
Отбор.Вставить("ДатаОкончания", '20250331235959');
ВыгрузитьЖурналРегистрации("D:\Архив\journal_2025_q1.xml", Отбор);
Код выполняется на сервере, поэтому путь указывается на диске сервера 1С, а не на компьютере пользователя. Само удаление записей после выгрузки делается кнопкой «Сократить» или удалением файлов периодов.
Журнал регистрации и СУБД: что где хранится
В клиент-серверной базе журнал регистрации не хранится в MS SQL или PostgreSQL. Это файлы на сервере 1С в каталоге srvinfo. Отсюда несколько практических следствий:
- 🗄️ Чистка таблиц SQL-базы журнал не уменьшит. Не ищите его среди таблиц СУБД.
- 🔀 Если серверов в кластере несколько, журнал ведёт центральный сервер, где зарегистрирована база. Ищите папку там.
- 💽 Каталог
srvinfoпо умолчанию лежит на системном диске. При большом журнале его переносят на отдельный том при установке сервера или его перерегистрации — заранее планируйте место.
Частая путаница — журнал транзакций MS SQL (файл .ldf). Его тоже «обрезают», но это совсем другая задача. Он растёт, если база в полной модели восстановления, а резервные копии журнала транзакций не делаются. Решение — регулярные бэкапы журнала транзакций либо простая модель восстановления, если она устраивает по требованиям к восстановлению. После этого файл ужимают:
USE [имя_базы];
DBCC SHRINKFILE (N'имя_базы_log', 1024);
Логическое имя файла журнала транзакций смотрите в свойствах базы в SQL Server Management Studio, второй параметр — целевой размер в мегабайтах.
Ещё один источник гигабайтов — технологический журнал 1С, который включается файлом logcfg.xml. Его забывают выключить после диагностики, и он забивает диск. К журналу регистрации он отношения не имеет: чистится удалением каталогов логов, указанных в logcfg.xml.