Всем доброго дня!
Есть некий ландшафт в котором все как положено, разработка, тестовая, продуктив, помимо центральной инстанции продуктива есть еще 2 диалоговые инстанции. Предположим продуктив зовется РРР. БД Оракл работает совместно с центральной инстанцией на одном сервере. Необходимо перенести на новый сервер и на новый дисковый массив центральную инстанцию и БД. Кто сталкивался с этой проблемой прошу помочь и описать подводные камни, которые будут попадаться на пути к прогрессу:). Ну и отправить читать нужные мануалы.
Установка новой системы, установка патчей, обновление ядра, системная копия, это не проблема.
1 Проблема пока с именами и лицензиями, как лучше поступить с именем новой инстанции, если ставить новое имя, то хотелось бы потом переименовать, чтобы не было путаницы, если оставлять старое имя, то как работать с лицензиями, будет дубль.
2 Что делать с диалоговыми инстанциями, все заново инсталить или можно перенастроить?
Хочется меньше проблем, поэтому прошу описать кто как видит решение этих задач.

1. заказать новые лицензии (дубля не будет. т.к. различаются HW ключи)
2. перенастроить

Сделать системную копию продуктива , оставив все имена и IP прежними. Диалоги по идее должны сами подцепится , но если что переустановите , 5 минут делов то.
С какими лицензиями проблема, какой дубль? Регистрируете просто новое оборудование (hardware key) по тому же самому имени на marketplace, с этим проблем нет.
Недавно переносили так целые ландшафты в новый ЦОД. Проблемы возникают , но они локальные и разрешимые.

Если есть время на downtime и дисковое пространство для выгрузки - сделайте гетерогенную копию системы.
Если попросту, - то это выгрузка данных в формате, пригодном для импорта инсталлятором.
При импорте можете выбрать другой SID для системы.
С лицензиями, точнее ключами, все просто. Новое железо - новый ключ. Он завязан на MAC сетевой карточки. Как минимум
Диалоги можно перенастроить, не является это принципиальной проблемой. Лень перенастраивать - переустановите, там недолго

P.S. Как все одновременно просыпаются...

вот прям из недавнего опыта,
отстраиваете сервак (он получает свой IP адрес), ставите пустышку аналогичную по версии оракла, патчам и версии ядра.

копируете существующую базу на новое место любым доступным методом, хоть scp
ставите базу в докат (без alter database open)
копируете архайвлоги и периодически докатываете базу.

как только решаете, что час Х настал, гасите боевой продуктив, копируете оставшиеся архайвлоги, докатываете и открываете базу.

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

при условии что у сервака сменился IP-адрес, у всех кто с ним контачит, надо сбросить буфер имен хостов в SMGW.

вуаля...
чтоб не быть голословным:
был опыт миграции прода ERP на новое место за 7 часов, включая все пост-обработки интеграции и смежных систем.
технически миграция заняла всего 4 часа, с учетом обязательного пункта по резервному копированию на новом месте.
база была примерно 300Гб.

Шрам , а что слабо было айпишник то поменять на прежний (продуктивный) ? Проблем на много меньше (если учесть что у пользаков иногда IP-ник прописан в saplogon).

SergoB
а там на новом месте другая подсеть была выделена (все уже украдено до нас (с)), поэтому вариантов не было

Ну если только так ... А так по возможности уж желательно все сохранить (это я к автору сообщения).
Там и с восстановлением проблем не будет никаких (без смены имени хоста).

всем большое спасибо за ответы

А еще иногда пользаки идут через логон-группу, и IP сервера, куда они попадут, им глубоко до фонаря А централки там вообще может и не быть... (в логон группе )

Да я же пример привел на все случаи жизни , в каждой организации по своему изначально настроено , я понимаю что логон группы это правильный путь , и отвязка от IP, но
на разных клиентах по разному.

Доброго дня всем,
перенос состоялся, в целом все прошло успешно, но не подключились диалоговые инстанции.
При старте на диалоговых вываливается: ABAP Database KEP must be started on remote server.
Еще ошибка:
R3trans -d: 2EETW169 no connect possible: "DBMS = ORACLE.
Где еще что забыл, не представляю

Сначала убедитесь что листенер на сервере БД запущен и нормально функционирует.
Потом смотрите на диалоговых в /sapmnt/SID/profile/oracle/tnsnames.ora все ли там в порядке. Включая момент, что это должен быть расшаренный с центральной инстанции каталог.
В итоге R3Trans -d должен на диалогах отрабатывать без ошибок.

Альтернатива - переустановить диалоги

Можно еще, ради интереса, посмотреть на параметр в DEFAULT профиле.
SAPDBHOST