Как в 1С удалить историю изменений объектов

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

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

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

Где 1С хранит историю изменений

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

Второй источник — регистрация изменений в планах обмена. Когда настроен обмен (РИБ, синхронизация с другой базой, обмен с сайтом), каждое изменение объекта фиксируется в служебных таблицах регистрации. После успешной выгрузки записи должны удаляться, но при сбоях или неактивных узлах они копятся месяцами.

Третий источник — история данных (механизм платформы, появившийся в версии 8.3.11). Он позволяет хранить историю изменения объектов и анализировать её запросами. Если механизм включён, но не используется, он бесполезно расходует место.

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

Подготовка: резервная копия и анализ объёма

Любая очистка истории — операция необратимая. Удалённые версии объектов, записи регистрации и журнал регистрации восстановить штатными средствами нельзя. Поэтому первый шаг всегда одинаков: создать резервную копию базы. Для файловой базы достаточно скопировать файл 1Cv8.1CD при остановленной работе пользователей, для клиент-серверной — выполнить выгрузку через конфигуратор (Администрирование → Выгрузить информационную базу) или средствами СУБД.

Второй шаг — определить, что именно занимает место. В типовых конфигурациях есть отчёт «Размер и количество данных в таблицах» или аналогичный инструмент в разделе администрирования. В клиент-серверном варианте объём таблиц смотрят средствами СУБД. Часто выясняется, что 60–80% объёма базы — это именно версии объектов и регистрация изменений, а не учётные данные.

Третий шаг — проверить, кто пользуется историей. Если версионирование включено «на всякий случай» и никто никогда не открывает отчёт «История изменений», очистка ничем не грозит. Но если версии используются для разбора спорных ситуаций или аудита, удалять их полностью нельзя — только устаревшие, за выбранный период.

Как удалить версии объектов (историю версионирования)

В типовых конфигурациях на базе Библиотеки стандартных подсистем (УТ 11, ERP, Бухгалтерия 3.0, ЗУП 3.1) есть штатный механизм очистки версий. Он находится в разделе «Администрирование» → «Обслуживание» → «Регламентные операции» либо вызывается из настроек версионирования. Точное расположение зависит от конфигурации, но функция называется «Очистка устаревших версий объектов».

Настройка очистки выполняется там же, где включается версионирование: «Администрирование» → «Общие настройки» → «Версионирование объектов». Для каждого типа объектов можно задать срок хранения версий: например, хранить версии документов последние 6 месяцев, версии справочников — год, а для некритичных объектов не хранить вовсе. После установки сроков регламентное задание будет удалять устаревшие версии автоматически.

Разовая очистка вручную

Если нужно очистить накопленное прямо сейчас, запустите регламентное задание «Очистка устаревших версий объектов» вручную из списка регламентных заданий («Администрирование» → «Обслуживание» → «Регламентные и фоновые задания»). Задание удалит все версии, срок хранения которых истёк согласно настройкам. На больших объёмах операция может занять часы — запускайте её в нерабочее время.

Полное удаление всех версий

Если требуется удалить вообще все версии, сначала отключите версионирование для всех типов объектов, затем установите минимальный срок хранения и дождитесь отработки регламентного задания. Альтернатива — программная очистка регистра сведений «Версии объектов» через обработку, но делать это стоит только при понимании структуры данных и после резервной копии.

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

Как удалить регистрацию изменений в планах обмена

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

Чтобы удалить регистрацию для конкретного узла, откройте список узлов плана обмена, выделите нужный узел и используйте команду «Удалить регистрацию изменений» (в разных конфигурациях она доступна через «Ещё» в форме узла или через обработку «Регистрация изменений для обмена данными»). Можно удалить регистрацию для всех объектов сразу или выборочно по типам.

В конфигураторе есть более жёсткий способ: свойства узла плана обмена не содержат такой команды, поэтому используют обработку «Регистрация изменений для обмена данными» (входит в поставку БСП и доступна на диске ИТС) либо программный вызов ПланыОбмена.УдалитьРегистрациюИзменений(Узел, НомерСообщения). Указание номера сообщения удаляет регистрацию только до этого номера — это безопаснее, чем полная очистка.

// Удаление регистрации изменений для узла после успешной выгрузки
Узел = ПланыОбмена.ОбменССайтом.НайтиПоКоду("000000001");
ПланыОбмена.УдалитьРегистрациюИзменений(Узел);

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

Как отключить и очистить историю данных платформы

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

Чтобы очистить историю данных, сначала отключите её для объектов, где она не нужна: в конфигураторе снимите флажок «История данных» в свойствах объекта или измените настройку через меню «Администрирование» → «Параметры информационной базы» в режиме управления историей данных. Само отключение не удаляет уже накопленные данные — их нужно удалить отдельно.

Удаление накопленной истории выполняется программно методами менеджера истории данных (ИсторияДанных.УдалитьВерсии и связанные вызовы) или через штатные средства управления историей в конфигураторе. После удаления для клиент-серверной базы имеет смысл выполнить сжатие таблиц средствами СУБД — физическое место на диске само по себе не освобождается.

Как очистить и урезать журнал регистрации

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

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

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

Частые ошибки и ограничения

Самая распространённая ошибка — удаление регистрации изменений до того, как данные реально ушли в узел обмена. Внешне всё выглядит нормально: база «похудела», обмены стали быстрыми. Но в другой базе изменения так и не появились, и расхождение обнаруживается спустя недели, когда восстановить ситуацию можно только полной повторной выгрузкой всех данных.

Вторая ошибка — ожидание, что база сразу уменьшится на диске. В файловом варианте после массового удаления нужно выполнить тестирование и исправление с сжатием таблиц, в клиент-серверном — shrink/реиндексацию средствами СУБД. Без этого удалённые записи просто помечаются как свободное место внутри файлов базы.

Третья ошибка — очистка без анализа причин. Если регистрация изменений копится из-за неработающего узла, удаление записей не решит проблему: через неделю объём вернётся. Сначала устраните причину (почините обмен или удалите узел), потом чистите накопленное.

Как проверить результат очистки

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

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

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

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