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

[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*, а у вас какой-нибудь старый сервис-пак. А про доработки вообще ничего сказать не могу - это вы должны сами оценить на тестовой базе.