История данных в 1С: где хранится и как с ней работать

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

Короткий ответ: история данных хранится не в отдельных файлах и не в журнале регистрации, а в специальных служебных таблицах той же самой информационной базы. В файловом варианте это таблицы внутри файла 1Cv8.1CD, в клиент-серверном — таблицы в базе данных MS SQL Server, PostgreSQL, Oracle или IBM Db2. Поэтому включение механизма напрямую влияет на размер базы и требует планомерной очистки.

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

Где физически хранится история данных

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

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

С точки зрения резервного копирования это удобно: история входит в выгрузку .dt и в бэкап базы СУБД автоматически, отдельно архивировать её не нужно. Обратная сторона — при активном версионировании размер бэкапа растёт заметно быстрее.

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

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

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

1. 1
   Откройте конфигуратор и убедитесь, что версия платформы не ниже 8.3.11.
2. 2
   В свойствах нужного вида объектов (например, документов) включите использование истории данных.
3. 3
   Обновите конфигурацию базы данных и проверьте запись объекта в пользовательском режиме.
4. 4
   Откройте историю объекта через команду «История изменений» или программно и убедитесь, что версия создалась.
5. 5
   Настройте расписание очистки устаревших версий, чтобы контролировать рост базы.

Как оценить и контролировать рост объёма базы

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

В клиент-серверной базе оценить объём можно штатными средствами СУБД — по размеру таблиц хранилища истории. В файловой базе косвенным признаком служит рост файла 1Cv8.1CD при неизменном объёме прикладных данных. Точный размер можно увидеть и при тестировании и исправлении базы, где выводится статистика по таблицам.

Очистка истории и сроки хранения

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

Учитывайте, что удаление версий из таблиц не всегда уменьшает физический размер файла базы. В файловом варианте освобождённое место остаётся внутри 1Cv8.1CD до выполнения сжатия (тестирование и исправление с опцией сжатия таблиц). В MS SQL Server может потребоваться shrink файлов, который разумно выполнять планово и с пониманием последствий для фрагментации индексов.

Альтернативы платформенной истории данных

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

Сравнение вариантов версионирования

Платформенная история данных

Подходит для платформы 8.3.11 и новее, работает «из коробки» без доработки конфигурации. Ограничение: хранит полные снимки, гибкая настройка состава полей ограничена.

Подсистема «Версионирование объектов» (БСП)

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

Журнал регистрации

Подходит, когда достаточно знать, кто и когда изменил объект, без содержимого изменений. Ограничение: не показывает, что именно изменилось, сравнение версий невозможно.

Собственная подписка на события

Подходит для нестандартных требований: выборочные поля, внешнее хранилище. Ограничение: требует разработки и сопровождения кода.

На практике часто комбинируют подходы: журнал регистрации включён всегда и даёт общую картину событий, а версионирование включают точечно — для критичных объектов вроде договоров, цен, банковских документов.

Проверка работы механизма и типичные проблемы

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

Контрольные точки

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

Создание версии при записи объекта

Норма

После изменения объекта в истории появляется новая версия с датой и пользователем

Тревожный признак

История пуста — версионирование для этого вида объектов не включено или конфигурация БД не обновлена

Рост размера базы

Норма

Размер растёт умеренно и соответствует интенсивности изменений

Тревожный признак

База растёт на гигабайты за дни — версионирование включено на массовые объекты или отсутствует очистка

Работа регламентной очистки

Норма

Старые версии удаляются по расписанию, объём истории стабилен

Тревожный признак

Версии копятся месяцами — задание не настроено или завершается с ошибкой

Ещё одна частая проблема — замедление записи объектов после включения версионирования. Формирование снимка добавляет накладные расходы на каждую транзакцию записи. Если пользователи жалуются на скорость проведения документов, проверьте, не включена ли история на высокооборотных документах, и сократите список версионируемых объектов.

Перед включением истории данных в рабочей базе включите её сначала на копии и прогоните типичную недельную нагрузку: обмены, перепроведения, загрузки. Так вы увидите реальный прирост объёма и влияние на скорость записи до того, как это коснётся пользователей.

FAQ: частые вопросы об истории данных в 1С

Можно ли хранить историю данных в отдельной базе или файле?

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

Сохранится ли история при выгрузке базы в .dt и загрузке в другую базу?

Да, версии входят в состав информационной базы и переносятся вместе с ней при выгрузке и загрузке .dt, а также при копировании базы средствами СУБД.

Что происходит с накопленной историей при отключении механизма?

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

Почему после удаления старых версий файл 1Cv8.1CD не уменьшился?

Файловая база не отдаёт освобождённое место операционной системе автоматически. Выполните тестирование и исправление с включённым сжатием таблиц информационной базы — после этого размер файла уменьшится.

Чем история данных отличается от версионирования объектов в типовых конфигурациях?

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

Влияет ли история данных на скорость работы базы?

Да. Каждая запись версионируемого объекта дополнительно формирует и сохраняет снимок, что увеличивает время транзакции. На массовых операциях — обменах, групповом перепроведении — эффект особенно заметен, поэтому версионирование стоит включать выборочно.