Очистка истории изменений и журнала регистрации в 1С 8.3

База разрослась до десятков гигабайт, резервная копия делается всё дольше, а на диске кончается место. Чаще всего виноваты две вещи, которые путают между собой: история изменений документов (версии объектов) и журнал регистрации. Чистятся они по-разному и из разных мест.

Историю изменений в 1С 8.3 убирают из режима 1С:Предприятие: Администрирование → Общие настройки, раздел «История изменений». Журнал регистрации сокращают из Конфигуратора: меню Администрирование → Настройка журнала регистрации, кнопка «Сократить». Это два независимых механизма — удаление одного не трогает другой.

История изменений и журнал регистрации — что есть что

Прежде чем чистить, разберитесь, что именно разрослось. Это разные хранилища с разным назначением.

История изменений (версионирование объектов) — копии документов и справочников на каждый момент записи. Механизм включается в конфигурациях на базе БСП: Бухгалтерия предприятия 3.0, ЗУП 3.1, Управление торговлей 11, ERP, Комплексная автоматизация. По кнопке история изменений видно, кто и что правил в документе и какие были значения реквизитов раньше.

Журнал регистрации — встроенный в платформу лог всех событий: входы и выходы пользователей, проведение документов, ошибки, обмены. Он есть в любой базе 1С 8.3 независимо от конфигурации и хранится отдельно от данных.

Ни версии, ни записи журнала не влияют на остатки, проводки и отчётность. Это служебные данные. Их очистка уменьшает размер базы и ускоряет резервное копирование , но на цифры в учёте не влияет.

Что сделать до очистки

Удаление истории и журнала необратимо. Порядок подготовки одинаков для обоих механизмов.

1. Сделайте резервную копию: для файловой базы — выгрузку в .dt через Конфигуратор (Администрирование → Выгрузить информационную базу) или копию каталога целиком; для клиент-серверной — средствами СУБД.
2. Выгоните пользователей. Многие операции (особенно работа с файлами журнала и тестирование базы ) требуют, чтобы в базе никого не было.
3. Определите, что именно разрослось — версии или журнал. Если не уверены, посмотрите размер файлов (см. раздел про проверку размера ниже).
4. При сокращении журнала решите, нужна ли выгрузка удаляемых событий в файл — её можно будет открыть позже, если понадобится история.

Как очистить историю изменений объектов

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

Уменьшить срок хранения версий. Откройте Администрирование → Общие настройки, найдите раздел «История изменений» и перейдите по ссылке настройки хранения. Откроется список объектов, по которым ведутся версии, и срок их хранения — например, «последние три месяца», «последний год» или «бессрочно».

Чтобы освободить место, уменьшите срок хранения у самых «тяжёлых» объектов (обычно это массовые документы — реализации, поступления, кадровые приказы). После этого устаревшие версии удалит регламентное задание очистки — оно запускается по расписанию в фоне. В клиент-серверной базе задание работает само, в файловой — при входе пользователя.

Удалить версии конкретного объекта. Откройте документ или элемент справочника, вызовите его историю изменений (команда истории в форме объекта), выделите ненужные версии и удалите их. Для этого нужны права администратора.

Почему версии так быстро разрастаются: при каждой записи объекта сохраняется его полная копия со всеми реквизитами и табличными частями. Для массовых документов (реализации, поступления, начисления зарплаты), которые перепроводят пачками, версии суммарно могут занимать больше места, чем сами документы. Хранятся они в служебном хранилище базы, а не в видимых справочниках, поэтому «на глаз» разрастание не заметно — видно только по общему размеру базы.

Отсюда практичный вывод: не включайте хранение версий подряд по всем объектам. Оставьте его там, где история правок реально нужна для разбора спорных ситуаций (договоры, ключевые документы реализации, кадровые приказы), а по техническим и массовым объектам — отключите или задайте короткий срок.

Сокращение журнала регистрации в Конфигураторе

Это основной и безопасный способ уменьшить журнал. Он не трогает данные базы и работает в любой версии платформы 8.3.

1. Запустите Конфигуратор под пользователем с правами администрирования.
2. Откройте меню Администрирование → Настройка журнала регистрации.
3. Нажмите кнопку «Сократить».
4. Укажите дату: будут удалены все события, записанные раньше неё.
5. Включите флаг записи удаляемых событий в файл и укажите имя файла, если хотите сохранить историю. Файл можно будет открыть для просмотра позже.
6. Подтвердите. Платформа удалит старые записи, а при включённой выгрузке — предварительно сохранит их.

В этом же окне настраивается, какие события вообще регистрировать и как часто разделять хранение (не разделять / по дням / месяцам / годам). Разделение по периодам само по себе журнал не чистит, но делает файлы мельче и позволяет потом удалять их по периодам точечно.

Там же задаётся уровень регистрируемых событий по важности — ошибки, предупреждения, информационные сообщения, примечания. Если журнал растёт слишком быстро, отключите запись маловажных событий (информация и примечания) и оставьте ошибки и предупреждения. Это самый безболезненный способ замедлить рост: вы ничего не удаляете, журнал просто перестаёт копить «шум» вроде каждого открытия формы. Для разбора инцидентов ошибок и предупреждений обычно достаточно.

Удаление журнала регистрации на уровне файлов

Если журнал нужно обнулить полностью или Конфигуратор недоступен, его удаляют на уровне файлов хранилища. Способ зависит от типа базы.

Где лежит журнал. В платформе начиная с версии 8.3.5 журнал хранится одним файлом 1Cv8.lgd (формат SQLite). В более старом формате это каталог 1Cv8Log с файлами .lgf и .lgp.

• Файловая база. Файл 1Cv8.lgd (или каталог 1Cv8Log) лежит в каталоге информационной базы, рядом с 1Cv8.1CD.
• Клиент-серверная база . Журнал лежит на сервере, в рабочем каталоге кластера, в папке соответствующей информационной базы (подкаталог вида reg_<порт>). Доступ к нему есть только у администратора сервера.

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

Как освободить базу безопасно. Не выдёргивайте пользователей на ходу. В Конфигураторе есть Администрирование → Блокировка соединений с информационной базой — она запрещает новые сеансы и позволяет дождаться, пока активные корректно завершатся. Для клиент-серверной базы то же делается из консоли администрирования кластера. Удалять 1Cv8.lgd, пока к базе кто-то подключён, нельзя: файл занят, а при файловой базе есть риск повредить хранилище.

В клиент-серверном варианте для удаления серверного файла пришлось бы останавливать службу агента сервера, а это остановит сразу все базы на этом сервере, не только вашу. Поэтому на сервере почти всегда правильнее сокращать журнал через Конфигуратор, а не удалять файл руками.

Отдельной команды командной строки, которая «чистит журнал», у платформы нет — не ищите мифический ключ запуска. Штатные пути только два: кнопка «Сократить» в Конфигураторе и удаление файла хранилища на освобождённой базе.

Автоматическая очистка, чтобы не разрасталось снова

Разовая чистка проблему не закрывает — через полгода база разрастётся опять. Настройте правила хранения один раз.

Для истории изменений автоочистка встроена: задайте разумный срок хранения версий (например, год по ключевым документам), и устаревшие версии будет удалять регламентное задание очистки по расписанию. Отдельно ничего запускать не нужно.

Для журнала регистрации платформа старые записи сама не удаляет — встроенного «срока хранения» у журнала нет. Варианты:

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

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

Как проверить, что база уменьшилась

После очистки сам файл базы обычно не уменьшается сразу — освободившееся место остаётся «внутри» файла. Проверка и финальная оптимизация делаются так.

1. Посмотрите размеры файлов. Файл журнала 1Cv8.lgd после сокращения должен заметно уменьшиться. Файл данных 1Cv8.1CD (файловая база) после удаления версий сразу не сожмётся — это нормально.
2. Сожмите файловую базу . В Конфигураторе откройте Администрирование → Тестирование и исправление информационной базы, включите реиндексацию таблиц и реструктуризацию. Это пересоберёт файл и вернёт место на диск.
3. Сожмите клиент-серверную базу . В том же окне тестирования доступно сжатие таблиц; физическое уменьшение файла СУБД — задача администратора сервера (shrink средствами СУБД).

Порядок величин для ориентира: журнал регистрации активной базы на несколько десятков пользователей за год легко набирает несколько гигабайт, а в крупных базах — десятки. История изменений по массовым документам за год тоже может прибавить гигабайты. Если 1Cv8.lgd или общий размер базы измеряется такими цифрами — чистить есть смысл; если журнал занимает десятки мегабайт, трогать его незачем.

Если место не освободилось даже после тестирования, дело не в истории и журнале, а в самих данных: большие таблицы движений, вложенные файлы, присоединённые сканы. Это уже отдельная тема.

Частые вопросы