При переходе на новые релизы 1С:Бухгалтерия 3.0 пользователи часто сталкиваются с ситуацией, когда обновление конфигурации в режиме «Конфигуратор» проходит успешно, но запуск в пользовательском режиме прерывается на этапе выполнения дополнительных процедур обработки данных. Одной из самых коварных проблем является сбой на отметке 7%, связанный со справочником ИдентификаторыОбъектовМетаданных. В этой статье мы подробно разберем, почему возникает эта ошибка, как диагностировать причины падения процесса rphost и какими методами можно восстановить работоспособность базы.
Справочник ИдентификаторыОбъектовМетаданных (ИОМ) является частью Библиотеки стандартных подсистем (БСП). Он предназначен для хранения уникальных идентификаторов (UUID) всех объектов конфигурации: справочников, документов, регистров и т.д. Эти идентификаторы используются для связи данных в распределенных информационных базах, в механизмах расширений и при настройке прав доступа.
Проанализируем ситуацию: при обновлении система выполняет сопоставление текущей структуры метаданных (то, что задано в дереве конфигурации) с записями в этом справочнике. Если в процессе сопоставления обнаруживается критическое рассогласование — например, ссылка в ИОМ указывает на объект, который был некорректно удален или изменен расширением, — платформа может войти в бесконечный цикл или аварийно завершить работу процесса rphost. Это приводит к вылету всех пользователей, работающих в данный момент с сервером предприятия.
Если стандартное Тестирование и исправление падает на проверке логической целостности справочника, нам необходимо выяснить, на каком конкретно объекте спотыкается система. Рассмотрим, как это сделать с помощью инструментов мониторинга СУБД. Проанализируем последние запросы к базе данных перед падением процесса. Чаще всего проблема локализуется в конкретном регистре или справочнике, который претерпел значительные изменения в новом релизе (например, РегистрСведений.РасчетСебестоимостиПродукции).
Если мы используем MS SQL Server, запустим SQL Server Profiler и настроим фильтр по нашей базе данных. Нам нужно отловить последнее событие перед ошибкой. Если платформа «зависает» на чтении таблицы справочника _ReferenceID (системное имя справочника идентификаторов), значит, в таблице присутствуют «битые» записи, которые не может переварить объектная модель 1С.
Иногда проблема кроется не в самих данных, а в кэшированной конфигурации, которая хранится в служебных таблицах SQL. Разберем последовательность действий для глубокой очистки:
ConfigSave, если в ней остались записи после неудачного обновления.DBSchema (делать это нужно крайне осторожно и только на копии базы!), чтобы заставить платформу заново пересчитать структуру базы данных при следующем запуске.Важный момент: если мы добавили в конфигурацию ОбщийРеквизит, платформа перестраивает структуру почти всех таблиц базы. Если в этот момент произошел сбой, справочник идентификаторов может начать ссылаться на несуществующие колонки. Попробуем временно исключить использование общего реквизита для тех объектов, на которых стопорится обновление.
Если справочник очищен, но форма списка все равно не открывается, а обновление виснет, мы можем попробовать вызвать процедуры БСП принудительно через внешнюю обработку. Выясним причину, почему стандартный механизм не справляется. Попробуем выполнить следующий код в режиме «Толстый клиент (обычное приложение)» или через обработку с серверным вызовом:
ПараметрыОбновления = Справочники.ИдентификаторыОбъектовМетаданных.ПараметрыОбновленияДанных();
ПараметрыОбновления.ВызыватьИсключениеПриНаличииДублей = Ложь;
ПараметрыОбновления.ЗаписыватьТолькоИзменения = Ложь;
Справочники.ИдентификаторыОбъектовМетаданных.ОбновитьДанныеСправочника(Истина, Истина, ПараметрыОбновления);
Параметр Истина, Истина указывает системе на необходимость полной перезаписи данных и игнорирование признака «обновление не требуется». Это позволяет принудительно сопоставить UUID объектов конфигурации с записями в справочнике, даже если система считает, что данные актуальны.
Проанализируем влияние расширений. В версиях платформы 8.3.10–8.3.12 была замечена ошибка: если объект был добавлен в расширение, а затем расширение было удалено, запись в справочнике ИОМ могла остаться, помеченная как предопределенная. Это создает «фантомный» объект, который блокирует работу справочника. Рассмотрим алгоритм исправления:
ИдентификаторыОбъектовМетаданных программно.ПараметрыРаботыПодсистем, так как он хранит настройки, привязанные к ID объектов./C СтартОбновленияИБ.Если падение rphost происходит при простом обращении к таблице, это может свидетельствовать о физическом повреждении страниц данных в SQL-базе. Посмотрим на пример команды для проверки базы в MS SQL Server:
DBCC CHECKDB ('ИмяВашейБазы') WITH NO_INFOMSGS, ALL_ERRORMSGS;
Если обнаружены ошибки, необходимо выполнить восстановление базы средствами SQL или использовать процедуру выгрузки в .dt файл и загрузки в новую чистую базу. Процесс выгрузки-загрузки часто пересобирает индексы и устраняет логические нестыковки, которые мешают платформе корректно прочитать справочник идентификаторов.
Подводя итог, отметим: проблема со справочником ИдентификаторыОбъектовМетаданных в БП 3.0 — это всегда следствие рассинхронизации между реальной структурой метаданных и их программным представлением в БСП. Наиболее эффективным методом решения является сочетание очистки кэша на сервере, программного перезаполнения справочника с параметром принудительной записи и, в крайнем случае, физического исправления таблиц на уровне SQL. Проанализировав все шаги, мы сможем успешно завершить обновление и восстановить штатную работу системы.