Генератор скриптов конвертации базы Axapta 3.0 в базу AX 2009

[gl00mie]

Некоторое время назад я принимал участие в переходе с Axapta 3.0 на AX 2009, причем переход осуществлялся с конвертацией рабочей базы (больше 600 Гб, работает все на Оракле). В ходе подготовки к конвертации базы штатная утилита конвертации и часть скриптов обновления данных показали свою полную несостоятельность. Вкратце я писал об это в теме Переход с Axapta 3.0 на AX 2009 - критика утилиты конвертации БД и скриптов обновления:

Цитата:

Сообщение от gl00mie

Если у компании достаточно большая база, и компания не хочет переходить лишь со справочниками и начальными остатками, то возможность конвертации такой большой базы стандартными средствами в приемлемые сроки может стать серьезным препятствием: обычно простой приемлем в течение выходных (т.е. в районе 60-и часов, включая вечер пятницы и утро понедельника), в то время как стандартный способ конвертации базы представляется, мягко говоря, далеким от оптимального.
Что предлагается сделать при штатной конвертации базы:

• перевести базу на левое выравнивание;
• удалить из базы данные, которые не предполагается переносить, т.е. затраты времени на перенос которых не оправданы (всякие там логи, параметрические таблицы для обработки заказов/закупок и т.п);
• с помощью отдельной утилиты создать слепок базы 3.0, подготовленный для AX 2009 (с данными, конвертированными в Unicode, с 64-битными полями под RecId, но со схемой от базы 3.0); утилита не разбирает, какие таблицы переносит, поэтому чтобы не переносить лишнее, нужен предыдущий шаг;
• с помощью скриптов конвертации:
  • перенести часть данных из удаляемых полей в новые (например, из createdTime/modifiedTime - в createdDateTime/modifiedDateTime);
  • заполнить часть новых полей константами либо значениями других полей той же записи (например, новые поля с MST-суммами могут заполняться из полей с валютными суммами при условии совпадения валюты проводки и основной валюты компании);
  • перебить значения некоторых enum'ов на новые (т.е. было значение 200, стало 5);
  • ну и выполнить какие-то нетривиальные преобразования.

Мне лично непонятно, зачем нужно тратить столько драгоценного времени на тупое перелопачивание одних и тех же данных, если кучу перечисленных действий можно было бы выполнить в рамках одного этапа - создания слепка базы 3.0, подготовленного для AX 2009. Ведь можно было бы на лету:

• переводить данные на левое выравнивание;
• заполнять поля типа UtcDateTime из имеющихся старых пар полей типа date + time (а это в скриптах конвертации реализовано офигенски неэффективно);
• перебивать значения enum'ов;
• заполнять новые либо незаполненные старые поля, если их значения можно легко и просто вычислить из других полей записи либо вообще задать константами;
• выбирать, какие таблицы не переливать вовсе;
• фильтровать переливаемые таблицы, чтобы не переливать лишние данные (всякие там отмененные/закрытые и т.п. записи либо записи с датой ранее заданной);
• и много чего еще...

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

Эти мысли возникли достаточно давно, после тестовой конвертации базы штатными средствами, так что было решено отказаться от штатной утилиты конвертации базы и части скриптов обновления, реализовав генератор скриптов переливки базы, за счет чего можно было бы выполнить максимум возможных преобразований данных на лету. Результат этой работы - во вложении, надеюсь, он пригодится еще кому-нибудь. В моем случае конвертация базы происходила с 31.12.10 по 01.01.11, о чем я писал вот тут, однако из-за загрузки на работе время на то, чтобы причесать код и по возможности "отвязать" его от других модификаций приложения, нашлось лишь недавно. Вот краткая инструкция по использованию генератора:

• полностью перенести словарь данных приложения Axatap 3.0 на приложение AX 2009;
• накатить прилагаемые проекты на приложения Axatap 3.0 и на приложение AX 2009;
• в AX 2009 запустить job ReleaseUpdateDB_FillSysUpgradeTimeZone для получения информации о заполнении полей типа UtcDateTime;
• в Axapta 3.0 в той базе (схеме), данные которой будут переливаться, либо в ее точной копии с точки зрения схемы данных и состояния конфигурационных ключей, запустить генератор с помощью прилагаемого пункта меню;
• ВНИМАТЕЛЬНО просмотреть все предупреждения, выводимые генератором по результатам работы и при необходимости изменить его "настройки". Многие из них будут относиться к усечению полей типа Filename с 260 до 259 символов, но часть может быть вызвана с неправильной настройкой конфигурационных ключей в AX 2009.

К часу "X":

• при необходимости перелить средствами СУБД данные исходной схемы (базы) в ту же базу (instance СУБД), где находится целевая схема (база) AX 2009. Теоретически можно было бы работать через dblink, но этот вариант слишком сильно снижает производительность и потому не поддерживается;
• в целевой схеме (базе) AX 2009 пройти список обновления до пресинхронизации не включительно;
• в целевой схеме (базе) AX 2009 отключить конфигурационный ключ DEV_Off (при этом конфигурационные ключи SysDeletedObjects40 и SysDeletedObjects41, очевидно, должны быть включены);
• для ускорения процесса перелвки данных рекомендуется drop'нуть все индексы на несистемных таблицах;

После этого в целевой схеме (базе) AX 2009 можно запускать скрипты переливки данных любым удобным способом.

Некоторые замечания:

1. Прилагаемый генератор - это коробочный продукт, он нуждается в адаптации под каждую конкретную инсталляцию и приложение; при этом я постарался вынести всю логику, специфичную для той или иной инсталляции/приложения, в отдельный класс DEV_SysDBMigrationKnowledgeBase. Перед запуском генератора скриптов следует внимательно изучить его и при необходимости подправить под свои нужды.
2. Хотя генератор писался под СУБД Oracle, я постарался абстрагировать его от используемой СУБД и вынести специфику Ms SQL Server в отдельный класс-наследник DEV_SysDBMigrationScriptsGenerator_SQL, однако, в этом классе, к примеру, не реализовано генерирование хранимки для конвертации на лету значений дата+время в UtcDateTime. Думаю, по оракловой реализации этот пробел будет несложно восполнить.
3. Исходным приложением было Axapta 3.0 EE SP5 FP1, поэтому в классах есть упоминания локализации из DIS-слоя для Восточной Европы.
4. Код генератора был портирован на AX 2009, в частности, были добавлены фрагменты условной компиляции; выгрузка проектов была сделана из "голого" приложения AX 2009 SP1 EE RU7 только из слоя usr, файл проекта для 3.0 был затем просто конвертирован в ANSI-кодировку, однако, на тестовом приложении 3.0 он успешно загружается.

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

PS. Некоторые заметки по обновлению приложения на AX 2009 можно найти здесь.