Администрирование · 12 мин
Как очистить историю данных в 1С
Как очистить историю данных в 1С: отключение версионирования, удаление версий объектов, настройка хранения и сжатие базы. Пошаговые инструкции и меры безопасности.
История данных (версионирование объектов) в платформе 1С:Предприятие 8.3 фиксирует, кто, когда и что изменил в документах и элементах справочников. Механизм полезен для аудита, но при активной работе таблицы истории разрастаются: база замедляется, резервные копии увеличиваются, а регламентные операции занимают больше времени. Очистка истории — штатная операция, но выполнять её нужно осознанно, с резервной копией и пониманием того, что удалённые версии восстановить штатными средствами нельзя.
Под «очисткой истории» обычно понимают три разные задачи: удаление накопленных версий объектов, полное отключение механизма истории данных и уменьшение физического размера файла базы после удаления. Это разные действия с разными последствиями, и ниже они разобраны отдельно. Также рассмотрен смежный случай — очистка истории в записях регистра сведений «История данных», если версионирование велось средствами типовой подсистемы БСП «Версионирование объектов».
Перед любыми действиями убедитесь, что у вас есть права администратора в информационной базе, монопольный доступ (для части операций) и свежая выгрузка базы в файл .dt или резервная копия на уровне СУБД. Без копии очистку выполнять нельзя: ошибка в настройках или сбой в процессе приведут к безвозвратной потере данных об изменениях.
Что такое история данных и где она хранится
Механизм истории данных появился в платформе 1С:Предприятие начиная с версии 8.3.11. Он работает на уровне платформы, а не конфигурации: для выбранных видов объектов (документы, справочники, планы видов характеристик и другие) система автоматически сохраняет версию при каждой записи. Версия содержит значения реквизитов, автора изменения, дату и комментарий, если он был указан.
Физически версии хранятся в служебных таблицах информационной базы. В файловом варианте это часть файла 1Cv8.1CD, в клиент-серверном — таблицы в базе данных MS SQL Server, PostgreSQL или Oracle. Важно понимать: удаление версий не уменьшает файл базы автоматически — освобождённое место остаётся зарезервированным внутри файла, пока не выполнено сжатие.
Отдельно существует подсистема «Версионирование объектов» из Библиотеки стандартных подсистем (БСП), которая используется в типовых конфигурациях («Управление торговлей», «ERP», «Бухгалтерия предприятия» и др.). Она хранит версии в регистре сведений «Версии объектов». Если вы не знаете, какой механизм используется, проверьте оба: настройки платформенной истории данных и настройки версионирования в разделе администрирования конфигурации.
Подготовка: резервная копия и оценка объёма
Первый шаг — резервная копия. Для файловой базы выполните выгрузку через конфигуратор: меню «Администрирование» → «Выгрузить информационную базу». Для клиент-серверной базы сделайте копию средствами СУБД (например, полный backup в MS SQL Server). Выгрузка .dt надёжнее копирования файла 1Cv8.1CD, так как гарантирует целостность данных.
Далее оцените, сколько места занимает история. Быстрый способ — открыть список версий любого активно изменяемого объекта и посмотреть глубину хранения. Для точной оценки в клиент-серверном варианте можно запросить размеры таблиц средствами СУБД. Если версии хранятся годами по всем документам, объём истории нередко сопоставим с объёмом самих данных.
Определите требования к хранению: во многих организациях внутренние регламенты или требования аудита обязывают хранить историю изменений за определённый период. Удалять версии глубже этого срока нельзя, даже если технически это возможно. Согласуйте срок хранения с руководителем или ответственным за учёт до начала очистки.
Как удалить накопленные версии объектов
Штатный путь для платформенной истории данных — настройка хранения версий. В конфигураторе откройте дерево конфигурации, выберите нужный вид объектов (например, «Документы» → конкретный документ), откройте свойства и перейдите на вкладку, связанную с историей данных, либо используйте общую настройку: «Администрирование» → «Настройка истории данных» в режиме предприятия, если конфигурация предоставляет такую обработку.
В настройках истории данных для каждого типа объектов можно задать срок хранения версий: например, хранить версии только за последние 90 или 365 дней. После установки срока платформа автоматически удаляет устаревшие версии — это самый безопасный способ очистки, так как он не требует прямого вмешательства в таблицы и выполняется системой контролируемо.
Если используется подсистема БСП «Версионирование объектов», очистка выполняется через регламентное задание или вручную: в типовых конфигурациях предусмотрена настройка срока хранения версий в разделе «Администрирование» → «Общие настройки» → «Версионирование объектов». Устаревшие версии удаляются регламентным заданием по расписанию. Для разового удаления большого объёма запустите задание вручную в нерабочее время.
- 1Сделайте резервную копию базы (выгрузка .dt или backup на СУБД)
- 2Определите, какой механизм используется: платформенная история данных или версионирование БСП
- 3Согласуйте срок хранения версий с ответственными за учёт
- 4Установите срок хранения в настройках истории данных или версионирования
- 5Дождитесь автоматического удаления устаревших версий или запустите регламентное задание вручную
- 6Проверьте результат на нескольких объектах и выполните сжатие базы
Как полностью отключить историю данных
Если версионирование не нужно вовсе, его можно отключить. Для платформенного механизма откройте конфигуратор, в дереве конфигурации найдите нужные объекты и в свойствах снимите признак использования истории данных. Альтернатива — настройка в режиме предприятия через обработку управления историей данных, если она есть в конфигурации.
Учтите: отключение истории данных не удаляет уже накопленные версии автоматически. Сначала выполните очистку по сроку хранения, дождитесь удаления версий и только потом отключайте механизм. Иначе старые версии останутся в базе «мёртвым грузом» — их больше не будет видно в интерфейсе, но место они продолжат занимать.
Для версионирования БСП отключение выполняется в настройках подсистемы: снимите флажок использования версионирования для нужных типов объектов. Ранее записанные версии останутся в регистре «Версии объектов», пока их не удалит регламентное задание очистки или ручная обработка.
Сжатие базы после удаления версий
Удаление версий освобождает страницы внутри файла базы, но не уменьшает сам файл. Чтобы вернуть место на диске, нужно сжатие. Для файловой базы откройте конфигуратор с монопольным доступом и выполните «Администрирование» → «Тестирование и исправление», отметив пункт «Сжатие таблиц информационной базы». Процедура на больших базах занимает заметное время — планируйте её на нерабочие часы.
Для клиент-серверной базы сжатие выполняется средствами СУБД: в MS SQL Server это операции shrink для файлов базы данных, в PostgreSQL — VACUUM FULL или pg_repack. Предварительно оцените, есть ли свободное место на диске: операции сжатия требуют дополнительного пространства для временных структур.
После сжатия проверьте размер файла базы и сравните с исходным. Если размер почти не изменился, возможные причины: версии фактически не удалились (не отработало регламентное задание), сжатие не выполнено до конца из-за ошибки, либо основной объём занимают не версии, а сами учётные данные.
Как проверить результат
Версии старше заданного срока отсутствуют, свежие на месте
Версии не удалились или пропали все, включая нужные
Файл заметно уменьшился относительно исходного
Размер не изменился — сжатие не выполнено или версии не удалены
Документы и справочники открываются, записываются без ошибок
Ошибки при записи или открытии объектов — нужна проверка целостности
Очистка истории в клиент-серверном варианте: особенности
В клиент-серверном варианте объёмы истории обычно больше, а средств контроля — шире. Администратор СУБД может напрямую посмотреть размеры таблиц истории и оценить эффект очистки до и после. Однако удалять записи из таблиц платформы напрямую через SQL-запросы категорически не рекомендуется: это нарушает целостность метаданных и лицензионные условия, а также может привести к неработоспособности базы.
Правильный подход: очистка выполняется штатными средствами платформы (срок хранения, регламентные задания), а на уровне СУБД делается только сжатие файлов и обслуживание индексов. После массового удаления версий полезно обновить статистику и перестроить индексы — это ускорит работу базы.
Если база большая и удаление версий идёт медленно, разбейте процесс на этапы: сначала установите большой срок хранения (например, два года), дождитесь удаления, затем уменьшайте срок постепенно. Так нагрузка на сервер распределяется, и регламентные задания не конфликтуют с работой пользователей.
Когда историю очищать нельзя: ограничения и альтернативы
Есть ситуации, когда очистку истории нужно отложить или заменить другим решением. Если по базе идёт расследование расхождений в учёте, аудиторская проверка или спор с контрагентом, история изменений — доказательная база, и удалять её нельзя. То же относится к периодам, по которым ещё не закрыта отчётность.
Если цель очистки — ускорение базы, сначала убедитесь, что проблема именно в истории. Часто замедление вызвано отсутствием обновления статистики на СУБД, фрагментацией индексов или неоптимальными запросами в доработках. Очистка истории в таких случаях даст лишь косвенный эффект.
Альтернатива полному удалению — выборочное версионирование: оставьте историю только для критичных объектов (ценовые справочники, договоры, ключевые документы) и отключите для массовых и малозначимых. Это снижает прирост объёма без потери контроля над важными изменениями.
Как выбрать действие
FAQ: частые вопросы по очистке истории данных
Можно ли восстановить удалённые версии объектов?
Штатными средствами — нет. После удаления версий восстановить их можно только из резервной копии базы, сделанной до очистки. Поэтому копия обязательна, а срок хранения версий стоит выбирать с запасом.
Почему файл базы не уменьшился после удаления версий?
Удаление освобождает место внутри файла, но сам файл не сжимается автоматически. Для файловой базы выполните «Тестирование и исправление» с включённым сжатием таблиц, для клиент-серверной — сжатие средствами СУБД (shrink, VACUUM FULL).
Чем история данных платформы отличается от версионирования БСП?
История данных — механизм платформы 8.3.11 и новее, работает на уровне ядра и не требует доработки конфигурации. Версионирование БСП — подсистема типовых конфигураций, хранит версии в регистре сведений «Версии объектов». В одной базе могут работать оба механизма, очищать их нужно по отдельности.
Нужен ли монопольный доступ для очистки истории?
Для установки срока хранения и работы регламентных заданий монопольный доступ не требуется. Он нужен для сжатия таблиц через «Тестирование и исправление» и для изменения настроек истории в конфигураторе.
Как часто нужно очищать историю данных?
Если задан срок хранения версий, очистка происходит автоматически и постоянно — отдельные регламентные мероприятия не нужны. Разовая ручная очистка требуется только при первичной настройке или после длительной работы без ограничения срока хранения.
Влияет ли очистка истории на обмены данными и синхронизацию?
История данных не участвует в планах обмена и не передаётся между базами, поэтому её удаление не влияет на синхронизацию. Однако на время массового удаления и сжатия лучше приостановить обмены, чтобы избежать конкуренции за ресурсы сервера.
Что важно запомнить
Очистка истории данных в 1С выполняется через настройку срока хранения версий — штатно и безопасно. Сначала удаляйте версии, потом отключайте механизм, затем сжимайте базу. Резервная копия перед очисткой обязательна: удалённые версии не восстанавливаются. Прямое удаление записей через SQL недопустимо.