01.01.2011, 21:28 | #1 |
Участник
|
Переход с Axapta 3.0 на AX 2009 - критика утилиты конвертации БД и скриптов обновления
Думаю, в ближайшее время для многих компаний будет актуален вопрос перехода с версии 3.0 на 2009-ю. Если у компании достаточно большая база, и компания не хочет переходить лишь со справочниками и начальными остатками, то возможность конвертации такой большой базы стандартными средствами в приемлемые сроки может стать серьезным препятствием: обычно простой приемлем в течение выходных (т.е. в районе 60-и часов, включая вечер пятницы и утро понедельника), в то время как стандартный способ конвертации базы представляется, мягко говоря, далеким от оптимального.
Что предлагается сделать при штатной конвертации базы:
Кто как боролся с этими проблемами - из тех, кому уже приходилось участвовать в переходе на 2009-ю с конвертацией имеющейся базы? Если верить недавнему семинару, кто-то для части таблиц отключает поля createdDate/modifiedDate, чтобы сэкономить время на их преобразовании в createdDateTime/modifiedDateTime, но это, по-моему, не выход... Какие еще есть варианты? |
|
|
За это сообщение автора поблагодарили: Logger (5). |
02.01.2011, 10:22 | #2 |
Модератор
|
Цитата:
Цитата:
Ведь можно было бы на лету..
Что касается тормознутости отдельных скриптов, это частично компенсируется тем, что можно поиграть с количеством AOS-ов и параллельно выполняемых батчей Цитата:
Если верить недавнему семинару, кто-то для части таблиц отключает поля createdDate/modifiedDate, чтобы сэкономить время на их преобразовании в createdDateTime/modifiedDateTime, но это, по-моему, не выход
Цитата:
Думаю, в ближайшее время для многих компаний будет актуален вопрос перехода с версии 3.0 на 2009-ю
__________________
-ТСЯ или -ТЬСЯ ? |
|
02.01.2011, 14:15 | #3 |
Участник
|
|
|
02.01.2011, 19:19 | #4 |
Участник
|
Совершенно согласен с вами, 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 - ы я ничего не встречал в описании процедуры конвертации... Последний раз редактировалось someOne; 02.01.2011 в 19:26. |
|
|
За это сообщение автора поблагодарили: ziva (2), gl00mie (2). |
02.01.2011, 20:34 | #5 |
Иван Захаров
|
Цитата:
Средствами Аксапты это всё сопоставляется (делается нужное выравнивание, приведение, ...) и по сути для каждой таблицы генерим запрос вида: INSERT INTO ... SELECT ... А сама DTS обходит это дело по помеченным к переносу таблицам и выполняет для каждой таблицы подобный запрос. Потом уже средствами AX2009 обновляем данные (запускаем нужные методы из ReleaseUpdateDB*) Надеюсь что кому-нибудь такой подход тоже облегчит жизнь |
|
|
За это сообщение автора поблагодарили: Logger (3), gl00mie (2). |
02.01.2011, 23:37 | #6 |
Участник
|
А я бы еще про время перехода уточнил. Если система работает каждый день (про круглосуточно молчу), то выходных просто нет и для "стандартного перехода" придется все равно дополнительно переносить операционные данные за время конвертирования основной БД.
__________________
Ivanhoe as is.. |
|
Теги |
ax2009, upgrade, конвертация базы данных, полезное |
|
|