Механизм восстановления логической целостности данных ИБ для РИБ.

Описание алгоритма.

Механизм обеспечивает поиск «битых» ссылок во всей ИБ. Найденные «битые» ссылки классифицируются объектом, в котором они обнаружены.

В конфигурацию добавляется объект — регистр сведений «МеханизмВосстановленияСсылок»: Измерения: Филиал (тип делителя по филиалам), ссылка (тип-любая ссылка). 

Механизм позволяет сформировать набор записей в регистре сведений по каждому филиалу (представленному как узел обмена).

Соответственно в каждый узел распределенной ИБ формируется посылка-«запрос» с «битыми»ссылками.

При загрузке посылки в филиале (узле) механизм определяет восстановление ссылки и формирует посылку-«отклик» узлу-отправителю, содержащую восстановленный объект.

При этом строка с восстановленным объектом в наборе регистре сведений очищается.

Алгоритм очищения записи с восстановленным объектом также заложена при формировании посылки-«запрос», т.о. исключается повторный запрос на восстановление.

 

Описание алгоритма поиска «битых» ссылок.

 

— Поиск «битых» ссылок на регистраторы.

Выполняется по регистрам, имеющих подчинения регистратору. Путем запроса к измерению Регистратор, у которого пометкаУдаления есть Null.

 

— Общий поиск по справочникам, документам и остальным регистрам.

общий поиск К каждому реквизиту объекта ссылочного типа формируется запрос, где у ссылки ПометкаУдаления = Null.

 

Полный поиск является трудозатратной операцией. На время выполнения операции влияет архитектура решения и объем рабочих данных.

К примеру, основным замедлителем являются реквизиты с типом «Любая ссылка» (а это в большинстве случае — это необоснованное решение), т.к. запрос вынужден формировать соединения со всеми входящим таблицами. 

 

Поэтому предусмотрены следующие способы оптимизации:

 

1. «Не включать в поиск реквизиты, тип которых состоит из ссылок на количество таблиц более, чем заданное количество». Ограничение. Игнорирование поиска в реквизитах, количество типов которого превышает заданное количество.

 Примечание. Как правило, именно в таких реквизитах чаще всего встречаются «битые» ссылки. Низкая эффективность оптимизации.

2. «Количество обрабатываемых таблиц в одном запросе не более, чем заданное количество». Обязательно к заполнению — отражает количество таблиц к соединению в одном запросе.

Является отражением ограничения MS SQL — «в одном запросе не может использоваться более 256 таблиц».

Оптимальным (опытным путем проверено) являются значения от 70-ти до 100.

3. «Вести отбор по типам «битых» ссылок». Возможность сразу указать каких типов будет искать «битые» ссылки. Наиболее эффективная оптимизация. По сути решает проблему «ЛюбыхСсылок».

4. «Поиск по выбранному типу — источника». Ограничивает поиск до рамок указанного типа, объекты которого имеют «битые» ссылки. 

 

Формирование списка найденных «битых» ссылок.

1. «Свернуть результат по «битым» ссылкам».

 

Автоматическое распознавание филиала-источника «битой» ссылки.

Описание алгоритма. В объекте, в котором обнаружена «битая» ссылка ищется реквизит с типом ФилиалаИсточника (задается при запуске). Значение попадает в результирующий список.

Соответственно при «сворачивании» автоматическое распознавание работает только для первого объекта.

 

Начальные настройки.

Тип Филиала Источника — задается тип филиала — делителя по узлам ИБ.

Тип Плана обмена- задается тип плана обмена через который будет производиться операция «запрос-отклик».

 

 

Рекомендуемая методика запуска механизма.

1. Первичный запуск. Наиболее трудоемкая операция. Но необходимая, чтобы понять объем «битых» ссылок в ИБ. Запускается в ЦБ во вне рабочее время как служебная процедура.

Результат обязательно сохраняется. В виде наборов записи в регистре.

 

2. Повторный запуск. Т.к. типы «битых» ссылок уже определены, то с большой степенью вероятности можно сказать, что при нормальной функционировании системы новые «битые» ссылки могут возникнуть также именно этого типа.

Есть возможность использовать 3-й способ оптимизации. На закладке «дополнительно» — «Загрузить по найденным».

 

П.С., если 1С доработает операцию тестирования ИБ и будет возвращать текст ссылок на несуществующие объекты, то возможно импортировать этот список как результат поиска.

 

Файлы:

«МеханизмВосстановленияБитыхСсылок_8.epf» — внешняя обработка с алгоритмикой.

«РегистрСведений.МеханизмВосстановленияСсылок.txt» — выгрузка файлов конфигурации в текстовом формате.

 

ЗЫ: на 8.2 не было необходимости делать такое 🙂