При внесении изменений в структуру метаданных через Конфигуратор разработчики нередко сталкиваются с системным сообщением: «Информационная база. Ошибка изменения конфигурации базы данных». Данная ситуация прерывает процесс реструктуризации таблиц и может привести к зависанию базы или невозможности входа пользователей.
Разберем детально, почему возникает эта ошибка, какую роль в этом играют регламентные задания и веб-сервисы, а также проанализируем пошаговые методы восстановления корректной работы информационной базы.
Проанализируем механику работы платформы «1С:Предприятие». Любое структурное изменение метаданных (добавление реквизита, изменение типа данных, создание новых регистров или справочников) требует выполнения реструктуризации физических таблиц СУБД. Этот процесс требует монопольного доступа к изменяемым объектам и системным таблицам Config, ConfigSave и Params.
Если в момент применения изменений система сталкивается с параллельной активностью, монопольный захват срывается. Основными источниками проблемы выступают:
snccntx).NULL в непустых полях.tempdb при масштабной перестройке больших объемов информации.Рассмотрим случай из практики: настроен интенсивный обмен между информационными базами через web-сервисы под управлением веб-сервера Apache. В очереди обмена накапливаются пакеты изменений. В момент запуска обновления Apache передает объемные порции данных, процесс начинает потреблять оперативную память, СУБД падает по таймауту блокировки, а регламентные задания перезапускают обмен снова и снова.
Чтобы успешно завершить реструктуризацию в таких условиях, выполним следующие шаги:
Обновить конфигурацию базы данных (клавиша F7). После монопольного применения структуры запускаем базу в режиме «Предприятие».Если блокировки исключены, но ошибка сохраняется, проанализируем состояние кэша платформы. Накопленные временные файлы часто приводят к ложным сообщениям о невозможности обновить конфигурацию БД.
1cv8.exe и 1cv8c.exe на рабочем месте разработчика.
%LOCALAPPDATA%\1C\1cv8
%APPDATA%\1C\1cv8
1C:Enterprise Server Agent и очистим содержимое каталогов с расширением .snccntx в рабочем каталоге кластера, после чего запустим службу заново.Рассмотрим ситуацию, когда в результате динамического обновления или аварийного прерывания реструктуризации таблица ConfigSave оказалась в несогласованном состоянии с таблицей Config.
Разберем последовательность действий для безопасного сброса зависших изменений:
Конфигурация -> Сохранить конфигурацию в файл... (получаем .cf-файл).Конфигурация -> Конфигурация базы данных -> Вернуться к конфигурации БД. Это действие очистит некорректные временные изменения из системных таблиц.Конфигурация -> Загрузить конфигурацию из файла....Если реструктуризация спотыкается о физические или логические повреждения данных, выполним внутреннюю диагностику средствами платформы:
chdbfl.exe, расположенной в каталоге bin установленной версии платформы.Администрирование -> Тестирование и исправление....Когда графическая оболочка Конфигуратора не отображает конкретную причину падения, запустим процесс обновления в пакетном режиме с выводом детального журнала:
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /IBConnectionString "Srvr=Server1C;Ref=BaseName;" /UpdateDBConfig -WarningsAsErrors /Out "C:\temp\update_log.txt"
Проанализируем сформированный лог-файл update_log.txt: пакетный режим выводит подробное описание ошибки с указанием конкретной таблицы или реквизита, на котором споткнулась СУБД, что позволяет точно локализовать проблемный объект метаданных.