← На главную

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

Жизненный цикл устаревших объектов метаданных

Проанализируем, почему разработчики типовых решений 1С не удаляют устаревшие объекты сразу, а сначала переименовывают их, добавляя префикс Удалить:

1. Обеспечение плавного перехода: Перенос накопленной информации из старых структур в новые (например, объединение регистров или переход на новые справочники) не всегда происходит мгновенно при реструктуризации базы данных.
2. Поддержка пропуска релизов: База данных пользователя может обновляться через несколько релизов подряд. Наличие переходных объектов позволяет алгоритмам обновления корректно мигрировать данные независимо от глубины пропуска промежуточных версий.
3. Автоматическое удаление платформой: Когда объект окончательно перестает использоваться и исключается из состава конфигурации разработчиком в очередном релизе, платформа 1С автоматически удаляет соответствующую таблицу и все данные из СУБД в процессе применения обновления.

Риски и последствия ручной очистки объектов с префиксом Удалить

Рассмотрим, почему методически и технически ручная очистка данных из таблиц с префиксом Удалить не рекомендуется и может привести к критическим сбоям:

1. Незавершенные фоновые и отложенные обработчики: В современных конфигурациях на базе Библиотеки стандартных подсистем (БСП) миграция данных выполняется асинхронно в фоновом режиме после первого запуска обновленной базы. Если вручную очистить устаревший регистр или документ до полного завершения этих обработчиков, алгоритмы переноса не найдут исходные данные, и новые структуры останутся пустыми, что приведет к безвозвратной потере информации. Перед любыми операциями всегда проверяйте обработку РезультатыОбновленияПрограммы.
2. Нарушение ссылочной целостности: Если принудительно очистить справочник или документ без контроля ссылочных связей, в других связанных таблицах базы останутся битые ссылки вида <Объект не найден...>. Это приведет к ошибкам при формировании регламентированной отчетности и сбоям тестирования базы.
3. Сбои в планах обмена и распределенных базах (РИБ): Массовая очистка данных приводит к созданию огромного количества записей регистрации изменений в планах обмена. Если узлы-приемники еще не были обновлены до соответствующей версии конфигурации, чтение пакетов синхронизации завершится аварийной ошибкой.
4. Обращения типового кода и расширений: В ряде случаев типовой программный код продолжает считывать исторические данные из объектов с префиксом Удалить для закрытия старых периодов или формирования ретроспективной отчетности. Кроме того, к этим таблицам могут обращаться сторонние внешние отчеты, обработки или установленные расширения.
5. Нагрузка на СУБД и отсутствие освобождения места: Массовое удаление миллионов строк создает колоссальный объем транзакционных журналов (LDF в MS SQL Server или WAL в PostgreSQL). При этом физический размер файлов базы данных на диске не уменьшается автоматически — для этого требуется дорогостоящая операция сжатия базы (Shrink / VACUUM FULL), которая приводит к фрагментации индексов.

Методические рекомендации: как правильно поступать

Выясним правильный порядок действий при сопровождении информационной базы:

1. Оставить объекты без ручного вмешательства: Стандартная методика разработки и сопровождения 1С предполагает, что таблицы с префиксом Удалить остаются в базе до тех пор, пока разработчик конфигурации полностью не удалит их из состава метаданных.
2. Контролировать регламентные процедуры обновления: Убедитесь, что все отложенные задания обновления БСП успешно выполнены без ошибок.
3. Предупреждать инициаторов ручной чистки: Если руководство или системные администраторы настаивают на принудительном удалении данных ради экономии места, необходимо зафиксировать риски потери данных и сбоев интеграций, а перед любыми манипуляциями обязательно создавать полную резервную копию базы данных.