gifts2017

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

Опубликовал Babys (babys) в раздел Администрирование - Распределенная БД (УРИБ, УРБД)

Цель. Восстановить целостность пространства данных в распределенных информационных базах.

Задачи. Найти ссылки на несуществующие объекты (далее "битые" ссылки).
Получить восстановленный объект из распределенной ИБ.

Постулат к решению. В удаленных ИБ присутствуют объекты не пришедшие в ЦБ (или др. удаленную ИБ), но имеющие в них ссылки на себя.

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

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

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

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

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

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

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

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

 

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

 

- Поиск "битых" ссылок на регистраторы.

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

 

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

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

 

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

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

 

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

 

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

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

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

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

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

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

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

 

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

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

 

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

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

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

 

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

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

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

 

 

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

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

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

 

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

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

 

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

 

Файлы:

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

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

 

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

Скачать файлы

Наименование Файл Версия Размер Кол. Скачив.
Обработка
.epf 28,80Kb
06.02.13
19
.epf 28,80Kb 19 Скачать
Код модуля
.txt 3,51Kb
06.02.13
32
.txt 3,51Kb 32 Скачать

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Игорь Иванов (ketr) 29.10.13 10:40
добрый день.будет ли работать под 8.2?
2. Babys (babys) 05.11.13 13:22
Непроверялось.

ЗЫ: У заказчика на 8.2 таких проблем не возникало.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа