Всем доброго времени суток. Стоит цель: миграция продуктивной системы ERP 6.0 с IBM AIX 5.3 на HP-UX 11.31. Система ERP 6.0 одностековая, (ABAP часть). Объем базы 750 GB. Главный трабл: простой допускается не больше 4 часов.
Как нибудь возможно это осуществить? Были прецеденты?

очень сомнительно, еслиб в пределах одной платформы, то о 4 часах еще можно былоб говорить и то с натяжкой.... а вот... сомнительно

Может сначала попытаться провести реорганизацию базы и только затем миграцию...?

А есть ещё системы (железки) куда можете поставить IBM AIX 5.3 ? Можно будет сделать туда гомогенную копию, а оттуда на HP-UX гетерогенную. Но это так, для тестовых целей ... (перед любой миграцией нужно делать тестовую)

Экспорт/импорт? Тоже может вылезти за пределы 4-х часов.
Сначала сделайте первый этап гетерогенного копирования - экспорт базы. Вас время в данном случае не лимитирует, в любой момент все можете остановить, если увидите, что за допустимое время простоя уходите, и стартовать систему "как и было раньше". И узнаете, сумеете уместиться в 4 часа или нет.
Чтобы успеть за 4 часа, надо чтобы экспорт шел не более полутора часов. Причем надо предусмотреть, чтобы он шел именно туда, откуда будете его потом доставать при импорте, чтобы избежать лишнего шага копирования файлов данных.
Но, соглашусь с вышесказанным, очень сомнительно успеть

за 4 часа просто нереально
Возможно файлы данных БД двоично совместимы, попробуйте поднять базу на чпуксе, просто скопировав (восстановив из бэкапа).

Ну двоично то они точно совместимы
4102 Big Endian IBM 390, AS/400, PowerPC (AIX),
Linux on zSeries (S/390), Linux on Power,
Solaris_SPARC, HP PA-RISC, Itanium (HP-UX)
Но поможет ли .... ?

Если времени 4 часа - это единственный вариант. Ставим систему на аиксе, копируем файлы БД, правим контрол файл, пересоздаем базу и вперед...

Но для начала нужно все смоделировать в тестовом режиме, если получится, погонять получившуюся систему - посмотреть на логи и пр... бывают косяки, которые на первый взгляд не видны, а потом получается непредвиденный простой системы...

Удачи

Читайте библию: Note 82478 - SAP system OS/DB migration; Note 857081 - Unicode conversion: downtime estimate может также дать представление о времени необходимом для миграции.

В вашем случае необходимо говорить о полноценном OS/DB Migration проекте т.к. операционные системы разные. Вашу продуктивную систему можно мигрировать только с благославления САП после успешной генерации Migration Key (Note 317096 - Migration Key Generation for ABAP Systems;) и только в присутствии SAP OS/DB Migration сертифицированного конультанта, каковым я и являюсь (andrew_scherbina@hotmail.com).

Теперь о проекте: За 4 часа даже с использованием всех компьютеров Восточного побережья США 'в одной упряжке' (изучайте Distribution Monitor SAP Note 855772 ) выгрузить 750GB из одной БД (AIX) и загрузить в новую БД (HP-UX) просто нереально из за Disk I/O ограничений. Посему готовьтесь как минимум к 24 часам (зависит от производительности ваших серверов, подходу к архивированию данных и т.д.) outage for parallel Export-Import procedure которая хорошо объяснена в любом NetWeaver Heterogeneous System Copy Guide.

Существует также Advanced Migration Technique под названием Incremental Migration (IMIG) для ну ОЧЕНЬ ДОРОГИХ КЛИЕНТОВ САП С ОГРОМНЫМИ БД и с минимально допустимым простоем - требует создания параллельной продуктивной системы с последующим '"переползанием" синхронизированных таблиц со старой на новую инстанцию в несколько этапов. Проект дорогой, требует специальных знаний и навыков и полного вовлечения САП т.к. постоянно находится в пилотной стадии и даже они вам 4 часа не гарантируют! https://www.sdn.sap.com/irj/scn/go/port ... daf8439309

Не буду вдаваться в подробности но не всегда при это полноценная OS/DB Migration, посмотрите хотя бы на примере MAX DB. Главное чтобы в этом случае Endian совпадал как минимум.

хм.... а у меня возникла идея:) а нельзя standby гетерогенный развернуть? - надо бы с DBA посоветоваться:) если это решение имеет право на существование - то останов будет минимальный. Даже меньше четырех часов.

И да кстати мне знающие люди рассказывали, что в Oracle 10 есть фишки, позволяющие копирование гетерогенное базы данных - на уровне файлов. Смотрите в эту сторону. Сразу говорю сама не пробовала. Но если есть необходимость - могу помочь с привлечением серьезных DBA:) - а там как договоритесь. Да кстати если база данных Oracle конечно:) про это нигде не сказано.

Хотелось бы увидеть обоснование этого утверждения.
По моим прикидкам, для выгрузки 750 Gb данных (если мы имеем в виду ограничение по Disk I/O) за 1 (один) час требуется пропускная способность около 200 Mb/s (750x1024/3600)
Это не запредельные значения даже для не сильно дорогих SAS контроллеров.

меня всегда такое умиляло:) особенно про присутствие сертифицированного консультанта и благословение SAP AG... Благославляю дети мои - шандарах ключем миграции

Это не я выдумал - читайте библию и не философствуйте. SAP Note 82478 - SAP system OS/DB migration says:

To support OS/DB migrations, SAP offers the OS Migration Service. The elements of services, tools and documentation form the basis for successfully executing the migration. The tools support the R3load procedure. This R3load procedure is generally the procedure we recommend. For some database systems, SAP also uses database-specific procedures. These are described in the relevant migration guide. Different procedures are also possible but they are not supported by SAP . As a result, the executing user is entirely responsible for these procedures and SAP cannot provide support for these procedures.

Therefore, we offer services that support you in all phases of the migration project. The project plan check ensures that the time frame for the project is appropriate.

To execute an OS/DB migration, the following are required:

1. A technical consultant, specially certified for OS/DB migrations, executes the migration locally, irrespective of whether you are migrating a development system, a test system or a productive system. This ensures that the required "know-how" is available to deal with the complexity of the situation.

2. You use the migration check service for the operating system or the database to migrate production systems.

SAP can provide hotline support for the migration only if both of these prerequisites are met, you use a copying technique that is supported by SAP, and you use the correct migration tools.

Пожалуйста: Миграция SAP системы в случае принципиально разных операционных систем (как в нашем случае) или БД осуществляется с помощью SAP утилиты R3load. Сначала надо оптимизировать Source IBM DB на чтение, а Target HP DB на запись, придется иметь дело не только с индексированными transparent tables но и с highly compressed scrambled data out of pool and cluster R/3 tables like BSIS, CDCLS, RFBLG, EDI40 etc. обычно они достаточно большие и их надо уметь правильно открыть, прочитать и выгрузить на OS level в независимом формате, загрузить на другую платформу в заранее приготовленную новую БД, снова проиндексировать, стартовать SAP, cгенерить ABAP Loads, cделать full back-up на новой платформе и лишь затем отдать систему бизнес-пользователям. Нельзя забывать и правильно отрежессированой Production cut-over procedure и заботы об интерфейсах - на всё нужно время!

Я имел дело с миграцией клиентских БД от 1 до 8 ТБ с использованием достаточно мощных серверов (48 quad core CPU, 96GB Memory, fastest SAN) и о потенциальной возможности полноценной миграции 750 GB за 4 часа никогда не не мечтал . Подготовка cut-over weekend занимает от 3х до 6ти месяцев, Downtime варьировался от 12 -24 часов до недели. Обычно Экспорт занимает в три раза больше времени чем Импорт (c опцией - loadprocedure fast) Размер выгруженных дамп файлов ~ 30% от размера БД. Чаще всего в подобных проектах Storage I/O это главный bottleneck с которым практически невозможно бороться

Для любознательных: SAP специально разработал advanced Migration Monitor (MIGMON) Socket Method когда данные транспортируются с одной платформы на другую через систему сокетов по TCP/IP протоколу без промежуточной выгрузки в дамп-файл, но исходную БД все равно приходится крутить по-старинке.

С использованием Distribution Monitor количество 'участников' вносящих свой посильный вклад в OS/DB миграцию теоретически неограничено; множество R3load процессов может работать на множестве разномастных боксов параллельно, процессов рекомендуется не более двух-трёх на CPU ядро, но они запускают corresponding Oracle процессы на source and target DB серверах, а на них ресурсы ограничены! . Вот и считайте теперь базируясь на вашем реальном опыте оптимизации expensive SQL statements

Поверьте мне на слово - 4 часа с 750GB БД это ПРАКТИЧЕСКИ НЕРЕАЛЬНО, ести у вас не Super Dome с террабайтом памяти на борту. На вопрос менеджмента какой Downtime надо планировать есть очень простой практический ответ - TEST RUN, и не один... End of story.