Переход с Axapta 3.0 на AX 2009 - критика утилиты конвертации БД и скриптов обновления

[gl00mie]

Думаю, в ближайшее время для многих компаний будет актуален вопрос перехода с версии 3.0 на 2009-ю. Если у компании достаточно большая база, и компания не хочет переходить лишь со справочниками и начальными остатками, то возможность конвертации такой большой базы стандартными средствами в приемлемые сроки может стать серьезным препятствием: обычно простой приемлем в течение выходных (т.е. в районе 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'ов;
• заполнять новые либо незаполненные старые поля, если их значения можно легко и просто вычислить из других полей записи либо вообще задать константами;
• выбирать, какие таблицы не переливать вовсе;
• фильтровать переливаемые таблицы, чтобы не переливать лишние данные (всякие там отмененные/закрытые и т.п. записи либо записи с датой ранее заданной);
• и много чего еще...

При всем при этом за счет сокращения числа промежуточных "переделов" базы можно также сократить число создаваемых по ходу конвертации резервных копий, что даст дополнительный выигрыш во времени. В общем, отсюда вопрос: почему стандартная конвертация сделана так неэффективно? Я уже молчу про скрипты перебивки енумов, которые зачем-то запускаются в разрезе компаний вместо выполнения одного прямого SQL-запроса, но зачем же столько ненужных промежуточных действий?..
Кто как боролся с этими проблемами - из тех, кому уже приходилось участвовать в переходе на 2009-ю с конвертацией имеющейся базы? Если верить недавнему семинару, кто-то для части таблиц отключает поля createdDate/modifiedDate, чтобы сэкономить время на их преобразовании в createdDateTime/modifiedDateTime, но это, по-моему, не выход... Какие еще есть варианты?

[Vadik]

Цитата:

• перевести базу на левое выравнивание;
• удалить из базы данные, которые не предполагается переносить, т.е. затраты времени на перенос которых не оправданы (всякие там логи, параметрические таблицы для обработки заказов/закупок и т.п);

Ничего же не мешает выполнить это заранее, а не в день Ч, правда ?

Цитата:

Ведь можно было бы на лету..

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

• над скриптами обновления как собственно и над отдельными модулями работают назависимые команды и люди
• отлаживать несколько простых скриптов им проще чем универсальный мегаскрипт (или получаем на выходе письмо дяди Федора)
• скрипты должны работать (или не работать) в зависимости от состояния конфигурационных ключей
• при апгрейде все равно где-то надо по каждой записи запускать бизнес-логику на X++ (те же расчеты AmountMST сумм и более сложную) зависящую от тех же enum-ов

Так что мегаскрипт тут не помощник
Что касается тормознутости отдельных скриптов, это частично компенсируется тем, что можно поиграть с количеством AOS-ов и параллельно выполняемых батчей

Цитата:

Если верить недавнему семинару, кто-то для части таблиц отключает поля createdDate/modifiedDate, чтобы сэкономить время на их преобразовании в createdDateTime/modifiedDateTime, но это, по-моему, не выход

Это один из выходов, кстати не самый плохой

Цитата:

Думаю, в ближайшее время для многих компаний будет актуален вопрос перехода с версии 3.0 на 2009-ю

Или уже на 6.0 ?

[Logger]

Цитата:

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

Или уже на 6.0 ?

На 6.0 никто не обещал автоматического перехода.

По поводу тормознутости конвертера - поддерживаю Gl00mie - по сути, инструмент вроде есть, но на реальной базе без серьезных переработок неприменим.

[someOne]

Совершенно согласен с вами, gl00mie.
Видимо, при создании этой процедуры руководствовались лишь чисто теоретической возможностью перехода, не думая о том с какими сложностями придется столкнуться разработчикам Аксапта при переходе.

Для себя решил проблему написанием собственного скрипта (на C#) по переносу данных из Ax 3.0 (Oracle) --> Ax2009 (MSSQL)

Удалось решить сразу ряд проблем
- Не нужна подготовка исходной базы данных
- Весь перенос данных происходит в один заход, при этом происходят все необходимые этапы (Преобразование Unicode, Выравнивание влево, конвертация DateTime, конвертация типов int--> int64, конвертация спец символов Orale пустой строки в "")
- Переносятся только те данные которые используются в новой версии.
Например ряд таблиц, типа DataBaseLog, Xref*, SalesParm* и так далее при переносе пропускаются, что так же экономит время.

Скрипт лишь наполняет "пустую", подготовленную заранее базу данных Ax2009 данными, в уже существующие таблицы Ax2009 из базы Ax 3.0 средствами SQL (Bulk Copy).

При этом происходит сравнивание таблиц SQLDictionary исходной и итоговой базы,
и переносятся данные в соответствии с кодами таблиц и полей, даже если они были переименованы в новой версии Аксапта.

После работы скрипта остается лишь реиндексировать базу (скрипт удаляет индексы для ускорения переноса данных), так как база до этого уже полностью была синхронизована.

Скрипт позволяет перенести базу 150 GB за
- 9 часов при одно поточном запуске
- 4 часа (ели запустить скрипт в 3-х потока одновременно на разных серверах.)

+ 4 часа на полную индексацию...

Не понятно почему в MS не могли написать "нормальную", удобную процедуру конвертации, с их возможностями разработки ?

Кстати, по поводу ENUM- ов. Вы имеете ввиду процедуру "последующей синхронизации" ?.
Что то про ENUM - ы я ничего не встречал в описании процедуры конвертации...

[ziva]

Цитата:

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

Для себя решил проблему написанием собственного скрипта (на C#) по переносу данных из Ax 3.0 (Oracle) --> Ax2009 (MSSQL)

А я написал DTS-ку на Integration Services, управляемую из базы-получателя (АХ2009) - имеется список таблиц из 2009 (и полей с их типами, выравниванием и пр.), а также список таблиц (и полей) из Ах30.
Средствами Аксапты это всё сопоставляется (делается нужное выравнивание, приведение, ...) и по сути для каждой таблицы генерим запрос вида:
INSERT INTO ... SELECT ...
А сама DTS обходит это дело по помеченным к переносу таблицам и выполняет для каждой таблицы подобный запрос.
Потом уже средствами AX2009 обновляем данные (запускаем нужные методы из ReleaseUpdateDB*)

Надеюсь что кому-нибудь такой подход тоже облегчит жизнь

[Ivanhoe]

А я бы еще про время перехода уточнил. Если система работает каждый день (про круглосуточно молчу), то выходных просто нет и для "стандартного перехода" придется все равно дополнительно переносить операционные данные за время конвертирования основной БД.