Data migration AX 3.0 SP3 Oracle 9.1 -> AX 4.0 SP2 SQL 2005

[dacom]

Привет всем,

На проекте возникла задача миграции данных с AX 3.0 SP3 Oracle 9.1 в AX 4.0 SP2 SQL 2005.

Задача имеет ограничение в 48 часов downtime и размер клиентской базы около 200 Гб.

В ходе изучения вопроса остановился на подходе в два этапа:
1. AX 3.0 Oracle -> AX 3.0 SQL 2005 (SQL скриптами, DTS, спец тулзами)
2. AX 3.0 SQL 2005 -> AX 4.0 SQL 2005 (стандартными средствами upgrade)

Прошу озвучить идеи и мнения по поводу решения и поделится практическим опытом. Т.к. существует ограничение по времени, критичны следующие моменты: время выполнения upgrage скриптов, hardware.
Буду признателен за любые примеры реальной жизни.

Спасибо за помощь!

[if_maks]

извините за встречный вопрос, а если система доработана (уверен почти везде так или иначе доработана), стандартные средства обновления работают крректно?
Как при этом переносятся данные в поля созданые в usr слое?

[mazzy]

Цитата:

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

Привет всем,

На проекте возникла задача миграции данных с AX 3.0 SP3 Oracle 9.1 в AX 4.0 SP2 SQL 2005.

Задача имеет ограничение в 48 часов downtime и размер клиентской базы около 200 Гб.

В ходе изучения вопроса остановился на подходе в два этапа:
1. AX 3.0 Oracle -> AX 3.0 SQL 2005 (SQL скриптами, DTS, спец тулзами)
2. AX 3.0 SQL 2005 -> AX 4.0 SQL 2005 (стандартными средствами upgrade)

Прошу озвучить идеи и мнения по поводу решения и поделится практическим опытом. Т.к. существует ограничение по времени, критичны следующие моменты: время выполнения upgrage скриптов, hardware.
Буду признателен за любые примеры реальной жизни.

Спасибо за помощь!

0. почистить базу http://axapta.mazzy.ru/lib/dbgrowthsolution/
1. после чистки любым удобным для вас инструментом (скорее всего данных у вас гиг на 30, а остальное ненужные логи)
1.5. оттестировать переход с 3.0 на 4.0 на тестовой базе до того, как объявлять час Х
2. да

[dacom]

Спасибо большое за ответ!

0. Таблицы логов занимают около 20Г. Таблицы истории заказчик удалят не желает. В лучшем случае думаю выйдет сократить БД до 100Г.

Mazzy, есть ли данные о временных затратах на выполнение скриптов upgrade и данные о hardware. Согласен, что каждый случай уникален, но хочется представлять общие затраты по времени.

Спасибо.

[mazzy]

Цитата:

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

0. Таблицы логов занимают около 20Г. Таблицы истории заказчик удалят не желает.

Это как он хочет. Но это не повод переносить старые логи в критическое время downtime, не так ли? Разбейте данные на две части - обязательные и прочие. Сначала перенесите обязательные.

Цитата:

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

В лучшем случае думаю выйдет сократить БД до 100Г.

Видите, волевым решением сократили количество переносимых данных вдвое

Если у вас жесткое ограничение по времени, то думайте и сокращайте дальше.

Цитата:

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

Mazzy, есть ли данные о временных затратах на выполнение скриптов upgrade и данные о hardware. Согласен, что каждый случай уникален, но хочется представлять общие затраты по времени.

Уникален.

Обратите внимание, что при переходе с SQL2000 на SQL2005 может придется менять collation данных. Это сходу около получаса на 10 гигабайт данных.

скрипты апгрейда по стандартной функциональности могут идти очень долго, если это какие-нибудь @#$% таблицы типа Facture*, а у вас какой-нибудь старый сервис-пак. А про доработки вообще ничего сказать не могу - это вы должны сами оценить на тестовой базе.

[dacom]

Цитата:

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

извините за встречный вопрос, а если система доработана (уверен почти везде так или иначе доработана), стандартные средства обновления работают крректно?
Как при этом переносятся данные в поля созданые в usr слое?

Должны работать корректно, если вы выполняете переход пошагово согласно Implementation Guide).

По крайней мере у меня получилось сделать такой переход на локальной АХ с несколькими таблицами на usr

[egorych]

Заморочка в переносе MS-Ora (и наоборот) возникает на полях CBLOB (IMAGE) и TEXT.
Я пробую переход MS->Ora - данные нормально, а вот для image пока приемлимого решения не нашел. Думаю, что и при Ora->MS nj-же самое будет.

[gl00mie]

Цитата:

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

На проекте возникла задача миграции данных с AX 3.0 SP3 Oracle 9.1 в AX 4.0 SP2 SQL 2005. Задача имеет ограничение в 48 часов downtime и размер клиентской базы около 200 Гб.

Цитата:

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

Должны работать корректно, если вы выполняете переход пошагово согласно Implementation Guide). По крайней мере у меня получилось сделать такой переход на локальной АХ с несколькими таблицами на usr

К слову, о переходе на 4-ку. Помнится, одним из этапов является перебивание на всех строковых EDT правого выравнивания на левое. На 200-гиговой и даже на 100-гиговой базе это может занять немало времени, хотя такое изменение можно произвести предварительно в несколько этапов на исходной системе. Плюс еще надо помнить о том, что DAX4 хранит строки в базе в юникоде, в результате чего при переходе база вырастет раза в полтора.

[dacom]

Цитата:

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

Заморочка в переносе MS-Ora (и наоборот) возникает на полях CBLOB (IMAGE) и TEXT.
Я пробую переход MS->Ora - данные нормально, а вот для image пока приемлимого решения не нашел. Думаю, что и при Ora->MS nj-же самое будет.

Спасибо, не знал.
Если проблема возникнет и будет найдено решение - обязательно отпишусь.

[dacom]

Цитата:

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

К слову, о переходе на 4-ку. Помнится, одним из этапов является перебивание на всех строковых EDT правого выравнивания на левое. На 200-гиговой и даже на 100-гиговой базе это может занять немало времени, хотя такое изменение можно произвести предварительно в несколько этапов на исходной системе. Плюс еще надо помнить о том, что DAX4 хранит строки в базе в юникоде, в результате чего при переходе база вырастет раза в полтора.

На стандартной демо дате вырастает в 2 раза
Спасибо, выпустил это из внимания.

[Aleck]

А вот эту штуку не смотрели?

https://mbs.microsoft.com/partnersou...igrationax.htm
Sure Step Migration Tool for Microsoft Dynamics AX

The tool can help you and your customers migrate data from competing business management systems and legacy systems to Microsoft Dynamics AX 4.0 Service Pack 1.

In addition, the tool’s repeatable methodology could be used across multiple customers with the same source system. Further, it could be used across customers with different source systems. By decreasing the time and expense of the customer’s implementation, you can increase the value of your services and solution to your customers, and gain a competitive advantage.

Source adapters provided with the download include:

* ....
* Microsoft Axapta 2.5 SP4

Additional source adapters may be made available by partners or ISVs on an Open Source community such as http://www.codeplex.com or PartnerSource in the future.

[arnold]

Microsoft Business Solutions – Axapta 2.5
A source adapter for Microsoft Business Solutions – Axapta 2.5 (now part of Microsoft Dynamics), is included in this release. The adapter can be used to migrate master data to the following Microsoft Dynamics AX areas:

Basic (Users, Zip codes, Countries, Currency, Exchange Rates)


Financials (General Ledger)

A Microsoft Business Solutions – Axapta 2.5 database backup is included with the Sure Step Migration Tool. Restore the database from the backup to use with the Microsoft Business Solutions– Axapta 2.5 source adapter.

[Aleck]

мдя... издевательство просто, а не адаптер ))