Здравствуйте, коллеги.
У меня имеется два двухузловых RAC кластера Oracle 10g, девелоперский и промышленный.
Файлы БД лежат на сетевых nfs ресурсах.
Возникла задача с минимальным простоем перенести пару баз с девелоперского кластера на промышленный.
Размер БД 20 и 400 Гб.

Прошу совета, как оптимально это сделать.

Вариант 1:
1) создам на промышленном кластере базы данных на временных сетевых ресурсах с теми же именами, параметрами и путями ко всем каталогам
2) корректно остановлю базы данных на девелоперском кластере
3) корректно остановлю базы данных на промышленном кластере
4) отмонтирую на девелоперском кластере ресурсы с реальными БД
5) отмонтирую на промышленном кластере временные ресурсы и подмонтирую ресурсы с реальными БД
После таких действий я смогу стартовать БД?
Или будет затык в том, что имена серверов кластера разные?
Нужно будет пересоздавать control-файлы?
Или еще какие действия?

Вариант 2:
Использовать не холодную фактически копию БД, а восстановить БД на промышленном кластере из горячей копии.
В таком случае у меня увеличится простой этих БД, так как после создания на промышленном кластере базы данных на временных сетевых ресурсах с теми же именами, параметрами и путями ко всем каталогам перестанут работать линки с кучи других промышленных БД на эти две переносимые базы. И они будут простаивать все время восстановления и накатки архивлогов.
А RMAN, как я понимаю, может восстановить из горячей копии только в БД с тем же именем и путями, так?

Заранее спасибо за любые советы по этой теме.

Спасибо за мнения.

Произвел тестовый перевод с промышленного кластера на девелоперский по варианту 1.
Проблем не возникло. Дополнительных действий не потребовалось.
После этого стал переводить две базы с девелоперского кластера на промышленный.
Одна база перевелась нормально, а другая нет.

При подключения к базе на новом местоположении с рабочей станции с верными tns посредством sqlplus выдавалось сообщение:
ORA-12520: TNS прослушиватель не может найти доступный обработчик для сервера запрошенного типа
Я так понимаю, что английский вариант сообщения таков:
ORA-12520: TNS:listener could not find available handler
Аналогичное сообщение было при проверке работы линков с промышленных баз, находящихся на тех же серверах, куда перенесены базы.
При непосредственном подключении на сервер удавалось авторизоваться "connect /as sysdba", пользователем sys с паролем, обычным пользователем.
Перезапускал процесс листенера, пересоздавал файл паролей.
Команды lsnrctl status и lsnrctl services показали, что сервис базы имеет 2 instance и 0 handler.
Перезагрузить сервера не мог, пришлось вернуть одну базу обратно.

Таким образом, у меня сложилась ситуация, что проблемная база запущена и работает на девелоперском кластере.
На промышленном кластере база с тем же именем опущена, отмонтированы ресурсы, на которых база создавалась, и ресурсы с реальными данными реальной базы. Tnsnames.ora скорректирован, убраны записи созданной базы, возвращены записи с указанием на девелоперский кластер.

Вопрос: я планирую подмонтировать на промышленный кластер ресурсы, на которых база создавалась, открыть эту пустую базу и пытаться заставить ее заработать. При этом в файле Tnsnames.ora оставить записи с указанием на девелоперский кластер, чтобы линки остальных промышленных баз продолжали работать с реальной базой на девелоперском кластере.
Не возникнет никаких проблем при этом?

Также буду рад любым советам по разрешению проблемы.
Заранее спасибо.

В alert.log никаких подозрительных записей старта нет.
Перестартовывал несколько раз.

Так как базы на новом размещении сейчас нет, не могу выполнить команду "SQL>show parameter listener"
Вечером или в обед попробую, если согласуют простой БД.

Еще вычитал команду "alter system register", думаю ее также попробовать.

Проанализировал еще раз вывод команды lsnrctl services (к счастью, он у меня сохранился)
Записи REMOTE SERVER для handler проблемной БД ссылались на старый HOST, девелоперского кластера.
Это очень странно, ведь tnsnames.ora я правил на обоих узлах промышленного кластера.
handler оттуда записи берет?

Победил командой:
SQL> alter system set local_listener=*запись из tnsnames.ora* scope=both sid='*';
Все заработало, всем спасибо.