Многие специалисты 1С сталкиваются с дилеммой: нужно оперативно внести изменения в рабочую базу в середине дня, но останавливать работу пользователей и выгонять всех из системы проблематично. В таких ситуациях часто прибегают к динамическому обновлению (в народе его иногда называют «демоническим»). Однако последствия могут быть самыми разными: от безобидных глюков интерфейса до критических сбоев, таких как «Нарушена целостность структуры конфигурации» или «Ошибка формата потока». Давайте подробно разберем, в каких случаях применение динамического обновления безопасно, какие изменения категорически нельзя применять "на лету" и как спасти базу, если она все-таки "легла".
Проанализируем базовые ограничения платформы 1С. Технически динамическое обновление возможно только тогда, когда изменения не затрагивают структуру таблиц базы данных (СУБД) и системе не требуется процедура реструктуризации.
Что разрешено обновлять динамически:
Что вызовет отказ в динамическом обновлении:
Платформа автоматически заблокирует динамическое обновление при добавлении, удалении или изменении любых метаданных, хранящих информацию. Вы физически не сможете обновиться без монопольного доступа, если добавили новый документ, справочник, регистр, изменили тип существующего реквизита или константы. Кроме того, платформа не позволит обновить "на лету" регламентные задания. Как отмечают пользователи в обсуждении, если кто-то утверждает, что база "упала" из-за динамического обновления после изменения типа реквизита, то здесь кроется ошибка в оценке ситуации: платформа просто не пустит такое обновление.
Разберем основные причины, почему динамическое обновление считается рискованным инструментом и может привести к нестабильной работе информационной базы.
Config (отвечает за актуальную структуру) и ConfigSave (хранит сохраняемую основную конфигурацию). Если во время применения динамического обновления происходит сбой сети, зависание сервера или экстренное отключение, в таблицу Config могут записаться "битые" или неполные данные. Именно это провоцирует массовые отказы и появление «Ошибки формата потока».Если после очередного динамического обновления база начала вести себя нестабильно или кого-то из пользователей перестало пускать в систему, применим следующие проверенные методики восстановления.
1. Очистка кэша на клиенте и сервере
Регулярная очистка кэша помогает избежать эффекта "накопления глюков". Для клиентов можно использовать параметр запуска /ClearCache (добавляется в дополнительные параметры запуска базы). В более сложных случаях потребуется ручное удаление папок с временными файлами (каталоги Config, ConfigSave, DBNameCache, SICache в профиле пользователя ОС). Эту процедуру полезно выполнять и на сервере 1С.
2. Перекрытие монопольным обновлением
Если в конфигурацию было внесено много динамических правок и появились странности, рекомендуется провести одно стандартное монопольное обновление (с отключением пользователей). Для этого можно фиктивно добавить и сразу удалить произвольный реквизит или комментарий. Это заставит платформу выполнить реструктуризацию, "схлопнуть" накопленные временные таблицы и очистить внутренний мусор.
3. Перезапуск службы сервера и очистка SQL
Радикальным решением серверных проблем (когда применяется старый кэшированный код) является полный перезапуск службы Агента сервера 1С. Если же Конфигуратор намертво зависает при попытке нового обновления, администраторам баз данных приходится очищать содержимое таблицы ConfigSave напрямую через SQL-запросы или удалять поврежденные записи.
Рассмотрим современные штатные механизмы платформы, которые позволяют безопасно обновлять систему, не прерывая работу всего предприятия.
Использование Расширений конфигурации. Это наиболее правильный подход для "горячих" исправлений (hotfix). Механизм расширений позволяет перехватывать выполнение процедур (через аннотации перед, после, вместо), дорабатывать интерфейс форм и даже добавлять новые объекты, не снимая основную конфигурацию с поддержки. Изменения применяются безопасно, а при плановом монопольном обновлении эти патчи можно перенести в основную конфигурацию и удалить из расширений.
Фоновое обновление конфигурации базы данных. Для крупных клиент-серверных баз платформа предоставляет механизм фоновой реструктуризации. Вы можете добавить новые реквизиты или регистры, и система будет подготавливать новую структуру таблиц в фоновом режиме, пока люди работают. Монопольный доступ потребуется только на пару минут — на самой последней фазе (смене поколений базы данных).
Подводя итог, можно сказать, что динамическое обновление не является абсолютным злом, если использовать его редко и только для мелких исправлений в коде или макетах. Однако для серьезных доработок и стабильной работы серверов лучше использовать расширения конфигурации или планировать технологические окна для монопольного обновления.