5.2.Миграция данных из версии 4.0.х2 5.2.1.Порядок выполнения миграции
Для миграции базы данных из версии 4.0.х необходимо воспользоваться скриптами, которые приложены к дистрибутиву Системы.
Выполните следующие действия:
Отредактируйте скрипт создания чистой БД Системы - файл \bin\create-initial-target-db.sh. В таблице приведены изменяемые параметры:
Таблица 4.2. – Параметры скрипта \bin\create-initial-target-db.sh
Параметр
|
Значение по умолчанию
|
Описание параметра
|
user
|
postgres
|
имя пользователя подключения к СУБД Системы
|
host
|
127.0.0.1
|
host СУБД Системы
|
port
|
5432
|
port СУБД Системы
|
targetDbName
|
migration_new
|
имя создаваемой БД Системы
|
logFile
|
../logs/restore_initial_target_db.log
|
Файл записи логов миграции
|
Выполните настроенный скрипт \bin\create-initial-target-db.sh
Отредактируйте скрипт переноса данных БД версии 4.0 в Систему - файл \bin\migrate.sh. В таблице приведены изменяемые параметры:
Таблица 4.2. – Параметры скрипта \bin\migrate.sh
Параметр
|
Значение по умолчанию
|
Описание параметра
|
user
|
postgres
|
имя пользователя подключения к Системе
|
host
|
127.0.0.1
|
host СУБД Системе
|
port
|
5432
|
port СУБД Системе
|
targetDbName
|
migration_new
|
имя БД Системе
|
r_user
|
postgres
|
имя пользователя подключения к СУБД версии 4.0
|
r_pass
|
postgres
|
пароль подключения к СУБД версии 4.0
|
r_host
|
192.168.1.148
|
host подключения к СУБД версии 4.0
|
r_port
|
5432
|
port подключения к СУБД версии 4.0
|
r_dbName
|
rgu_stand_2
|
имя БД версии 4.0
|
r_region
|
63
|
код региона, данные которого должны мигрироваться (00 – для федерального уровня)
|
Выполните настроенный скрипт \bin\migrate.sh
Для переноса версий для сравнения изменения объектов реестра (сравнение, которое открывается из истории изменения объекта), отредактируйте скрипт bin\migrate_xml_data.sh (исполнение скрипта не является обязательным, выполняется при необходимости).
Таблица 4.2. – Параметры скрипта bin\migrate_xml_data.sh
Параметр
|
Значение по умолчанию
|
Описание параметра
|
user
|
postgres
|
имя пользователя подключения к Системе
|
host
|
127.0.0.1
|
host СУБД Системы
|
port
|
5432
|
port СУБД Системы
|
targetDbName
|
migration_new
|
имя БД Системы
|
r_user
|
postgres
|
имя пользователя подключения к СУБД версии 4.0
|
r_pass
|
postgres
|
пароль подключения к СУБД версии 4.0
|
r_host
|
192.168.1.148
|
host подключения к СУБД реестра 4.0
|
r_port
|
5432
|
port подключения к СУБД версии 4.0
|
r_dbName
|
rgu_stand_2
|
имя БД версии 4.0
|
r_region
|
63
|
код региона, данные которого должны мигрироваться (00 – для федерального уровня)
|
Выполните настроенный скрипт bin\migrate_xml_data.sh.
В случае, если приложения Системы и приложения версии 4.0 лежат на разных серверах, необходимо перенести папку, указанную в параметре STORAGE_ROOT_DIRECTORY_PATH таблицы system_properties, на сервер, где размещено приложение Системы.
5.2.2.Контроль полноты и корректности миграции данных
После завершения миграции (выполнения действий, описанных в п. 5.2.1) для контроля полноты и корректности данных, перенесенных из версии 4.0, необходимо воспользоваться журналом логирования, сформированным в ходе миграции, а также типовыми запросами к БД и проверками ее целостности.
Показателями полноты и корректности миграции служат количественные показатели переданных записей по ключевым таблицам сущностей, а также структурная целостность базы данных после миграции.
Журнал логирования содержит секции в соответствии со сценарием проведения миграции.
Секция миграции данных представляет собой записи следующего вида:
3,"(4.0) (user_notification_statuses): contains 77 entity","2016-11-25 11:55:38.003299",user_notification_statuses,NULL
4,"(4.1) (user_notification_statuses): inserted 77 entity","2016-11-25 11:55:38.084691",user_notification_statuses,NULL
5,"(4.0) (service_2_work_document): contains 249884 entity","2016-11-25 11:56:27.998037",service_2_work_document,NULL
6,"(4.1) (service_2_work_document): inserted 249884 entity","2016-11-25 11:56:52.507768",service_2_work_document,NULL
где
первое значение – уникальное значение строки логирования;
(4.0) или (4.1) [наименование таблицы, записи которой мигрированы] – номер версии, указывающий на принадлежность информации к записям БД источника или целевой БД, куда переносятся данные. Если строка содержит (4.0), то строка описывает количество записей, взятых из таблицы БД версии 4.0; если (4.1), то количество вставленных записей в таблицу целевой БД Системы;
[количество обработанных записей таблицы];
[дата-время начала процесса];
[наименование таблицы, записи которой были мигрированы].
Для контроля полноты необходимо проследить за соответствием количества записей таблиц основных сущностей (услуги, функции, ОГВ, офисы). Анализ НПА и рабочих документов не относится к простому сопоставлению количества записей, поскольку они мигрируются и затем обрабатываются по принципу участия в услугах (функциях)3, поэтому полноту данных по этим сущностям можно проверить только с помощью выполнения запроса к БД источника и целевой БД.
Для анализа полноты миграции НПА необходимо осуществить следующие действия:
Выполните запрос к БД версии 4.0:
«SELECT count(DISTINCT la.id)
FROM legal_act la
LEFT JOIN LEGAL_ACT_SERVICE las ON la.id = las.legal_act_id
LEFT JOIN service_2 s ON s.id = las.service_id
LEFT JOIN tkmv t ON la.id = t.legal_act_id
LEFT JOIN adm_regulation ar ON la.id = ar.legal_act_id
WHERE s.id IS NOT NULL OR t.id IS NOT NULL OR ar.id IS NOT NULL;»,
возвращающий количество НПА, связанных с услугами и функциями, в Типовой реестр 4.0.
Выполните запрос к БД Системы:
«SELECT count(DISTINCT la.id)
FROM legal_act la
LEFT JOIN LEGAL_ACT_SERVICE las ON la.id = las.legal_act_id
LEFT JOIN service_2 s ON s.id = las.service_id
LEFT JOIN tkmv t ON la.id = t.legal_act_id
LEFT JOIN adm_regulation ar ON la.id = ar.legal_act_id
WHERE s.id IS NOT NULL OR t.id IS NOT NULL OR ar.id IS NOT NULL;»,
возвращающий количество НПА, связанных с услугами и функциями, в Системе.
Сравните количество НПА, полученное в результате выполнения первого и второго запроса. Оно должно совпасть.
Для анализа полноты миграции рабочих документов необходимо осуществить следующие действия:
Выполните запрос к БД Типового реестра версии 4.0:
«SELECT count(1)
FROM (
SELECT DISTINCT wd.id
FROM _work_document wd
INNER JOIN service_2_work_document s2wd ON wd.id = s2wd.work_document_id
INNER JOIN service_2 s ON s.id = s2wd.service_id
) inn;»,
возвращающий количество рабочих документов, связанных с услугами и функциями, в БД версии 4.0.
Выполните запрос к БД Системы:
«SELECT count(1)
FROM (
SELECT DISTINCT wd.id
FROM _work_document wd
INNER JOIN service_2_work_document s2wd ON wd.id = s2wd.work_document_id
INNER JOIN service_2 s ON s.id = s2wd.service_id
) inn;»,
возвращающий количество рабочих документов, связанных с услугами и функциями, в БД Системы.
Сравните количество рабочих документов, полученное в результате выполнения первого и второго запроса. Оно должно совпасть.
Для оценки целостности структуры мигрированных данных необходимо провести анализ на отсутствие строк с ошибками в секциях лога «RESTORE INDEXES» и «RESTORE CONSTRAINTS».
|
