Нередко разработчики 1С сталкиваются с ситуацией, когда после, казалось бы, незначительного изменения в конфигурации — например, удаления одного справочника — процесс обновления базы данных затягивается на часы. Система начинает выполнять реструктуризацию таблиц в несколько циклов, или "кругов", и каждый такой круг может занимать от 30 минут до нескольких часов. Рассмотрим, почему это происходит и что с этим можно сделать.
Основной вопрос, который возникает в такой ситуации: нормально ли это, что платформа запускает пересчет всех объектов несколько раз подряд? Как показывает практика, да, это штатное, хотя и очень неприятное, поведение платформы 1С. Проанализируем его причины.
Ключевая задача платформы при обновлении — сохранение ссылочной целостности данных — поможет диагностика и очистка регистров от битых ссылок. Когда вы удаляете объект метаданных, система должна гарантировать, что в базе не останется "битых" ссылок, а структура всех связанных таблиц будет приведена в соответствие с новой конфигурацией. Этот процесс усложняется и становится многоэтапным из-за нескольких факторов.
Реквизиты с составным типом ЛюбаяСсылка (AnyRef)
Это главная причина долгих циклических обновлений. Тип ЛюбаяСсылка позволяет хранить в одном поле ссылки на объекты совершенно разных типов (на все справочники, документы и т.д.). Когда вы удаляете из конфигурации, например, один справочник, состав типа ЛюбаяСсылка изменяется. Платформе необходимо проверить и перестроить структуру каждой таблицы в базе данных, где используется этот составной тип.
После перестройки одной такой таблицы платформа может обнаружить, что это изменение затрагивает другие, зависимые от нее таблицы (например, регистры или планы обмена). Это запускает новый цикл проверки и реструктуризации. Процесс повторяется итеративно, "круг за кругом", пока система не достигнет полностью консистентного, стабильного состояния, где все зависимости разрешены. Как отметил один из участников обсуждения, нужно понимать, как ЛюбаяСсылка устроена на уровне СУБД, чтобы осознать масштаб перестроений.
Удаление объектов, включенных в планы обмена
Если удаляемый объект был зарегистрирован хотя бы в одном плане обмена, платформа запускает реструктуризацию таблиц регистрации изменений. Причем перестройка может затронуть таблицы для всех объектов, входящих в эти планы, а не только для удаляемого. Это крайне длительная операция, особенно на больших базах, даже если фактических данных для обмена нет. В таких случаях часто требуется групповое изменение режима поддержки или предварительная очистка состава планов обмена.
Сложные взаимосвязи объектов
Удаление одного объекта может вызвать цепную реакцию. Например, вы удаляете справочник. Это приводит к изменению структуры регистра сведений, который на него ссылался. В свою очередь, изменение регистра может потребовать обновления отчета, который на него опирается, и так далее. Платформа проходит по этой цепочке зависимостей, и каждый проход может представлять собой отдельный "круг" реструктуризации.
Как показывает опыт из обсуждения, на файловой базе небольшого размера та же операция удаления справочника может пройти с первого раза, тогда как на большой клиент-серверной базе ERP процесс растягивается на 4 круга по 30 минут. Это подтверждает, что объем данных и сложность конфигурации напрямую влияют на длительность процесса.
Рассмотрим ситуацию, описанную на форуме, которая наглядно иллюстрирует проблему.
Автор исходного сообщения подтвердил, что его обновление завершилось на четвертом круге. Это означает, что платформе потребовалось именно четыре итерации для полного разрешения всех зависимостей, возникших после удаления объекта.
Хотя циклическая реструктуризация — это штатный механизм, его можно и нужно оптимизировать. Рассмотрим несколько подходов.
Начиная с версии платформы 8.3.11, доступен новый, значительно более быстрый механизм реструктуризации. Его главное преимущество в том, что он не создает полные копии таблиц (с суффиксом _NG), а делегирует операции по изменению структуры напрямую СУБД с помощью команд вроде ALTER TABLE. Это ускоряет процесс в разы, а иногда и на порядки.
Условия для его использования:
Если эти условия выполнены, платформа автоматически попытается использовать новый механизм, что может кардинально сократить время обновления.
Профилактика всегда лучше лечения. Некоторые практики разработки помогут минимизировать риски долгих обновлений.
ЛюбаяСсылка. Используйте этот тип только там, где он действительно необходим. В большинстве случаев можно обойтись более конкретными ссылочными типами или несколькими реквизитами разных типов.Если вы регулярно сталкиваетесь с долгими обновлениями и хотите точно знать, что является причиной, воспользуйтесь технологическим журналом (ТЖ). Настроив его на отслеживание события Restructuring, вы получите подробный лог, который покажет, какие именно таблицы перестраиваются и почему. Для более глубокого исследования системы можно выполнить замер производительности контура 1С и поиск узких мест, что позволит вам принять точечные меры для оптимизации структуры метаданных. Кроме того, качественный анализ конфигураций на наличие ошибок поможет заранее выявить проблемные места перед началом обновления.
В заключение, многократный пересчет объектов при реструктуризации — это цена, которую приходится платить за гибкость таких механизмов, как ЛюбаяСсылка, и гарантию целостности данных. Если вы столкнулись с этой проблемой, самое простое решение — дождаться ее завершения. А для будущих обновлений стоит рассмотреть возможность использования оптимизированного механизма реструктуризации и пересмотреть подходы к модификации конфигурации.