[Vizcayno]

Hola:
Lo que sucede es que el tiempo que el el R3Copy se toma para bajar los datos de SAP es prohibitivo, tengo varios terabytes que con un backup utilizando herramientas no SAP me toma menos de un día y con
R3copy varios días y el sistema productivo no puede estar parado tanto tiempo, ni siquiera en fin de semana :-(
Por ese motivo me gustó la solución de H_Rossi, pero por otro lado veo que tengo que hacer cambios no muy elegantes a nivel de la base de datos y SAP.
Creo que hasta el momento del backup con "herramientas no SAP" todo iría bien.
Junto con un administrador de sistema y un DBA logramos tener un sistema Solaris 10, instalar 10.2.0.2 y luego restaurar la base de datos de SAP de SA a SN y hacer que Oracle 10.2.0.2 reconozca los datos de la base 8.1.7.4. En este momento ya tengo un clon de la base de datos de SAP sobre Solaris 10 y Oracle 10.2.0.2. Solo falta amarrar esa base de datos a SAP 4.6C; siento que estamos a un paso de la gloria.
Ahi es donde debo decidir dos caminos:
1) Copiar /sapmnt/<SID>, /usr/sap/trans, /usr/sap/<SID> de SA a SN y aplicar los pasos de H_Rossi
2) Pretender ejecutar R3SETUP y, cuando me pida el tipo de instalación pueda indicarle que se asocie a la nueva base de datos. Aprovecho para preguntar si eso es posible y si además el R3SETUP podría permitirme cambiar el ID de la la base de datos de PRO (con el que se encuentra) a DEV.

Muchas gracias por la atención y la ayuda. Por mi lado sigo leyendo y viendo alternativas para reducir los tiempos de upgrade que es nuestra mayor preocupacion; por lamentablemente no solo es upgrade de SAP, es también upgrade de sistema operativo y Base de datos.