Upgrade de 46C a ECC 6.0

[Vizcayno]

Hola:
Daremos inicio al proceso de upgrade técnico de 46C a ECC 6.0.
Quisiera mostrarles el escenario que tengo para que en base a ello puedan ayudarme a resolver unas dudas.
-Servidor Actual (SA): SAP 46C con Oracle 8.1.7 y Solaris 8
-Servidor nuevo (SN): Sin SAP, 40% más de capacidad, con Oracle 10.2 y Solaris 10.
Quiero instalar SAP ECC 6.0 en SN y traer los datos de SA.

Cuál es la forma más fácil e tiempo y esfuerzo para conseguir esto? Los manuales de SAP son muy genéricos. Tengo dos ideas pero quisiera que me ayuden a validarlas:

1ra forma
---------
1. Copia homogénea de SA
2. Instalo ECC 6.0 en SN con la opción de importar los datos generados en 1.
3. Instalación terminada y configuraciones adicionales. Proceso terminado (Parece muy fácil no?)

2da forma
---------
1. Copia homogénea de SA
2. Instalo 4.6C en SN con opción de importar los datos generados en 1, aquí estoy en duda si 4.6C aceptará funcionar con Solaris 10 y Oracle 10.2. Además supongo que los niveles de parches que apliqué están inmersos en la copia homogénea que hice en el punto 1.
3. Repongo las capas de transporte y otras configuraciones.
4. Hago las pruebas de que todo va bien. Hasta aquí lo que habría logrado es migrar el 46C a un nuevo sistema operativo y base de datos.
5. Comienzo recién el upgrade en SN, del 46C a ECC 6.0
6. .... lo que el manual de SAP indica después.

Espero su ayuda.
Muchas gracias.

[h_rossi]

Hola:

Yo te doy mi punto de vista aunque a muchos no les guste. Lo que si te puedo decir, que de esta forma de resultado y con menor tiempo de implementación.

1. Tomar backup de la base de datos, motor, /sapmnt/<SID>, /usr/sap/trans, /usr/sap/<SID> de SA.
2. Trata de que los usuarios <SID>adm y ora<SID> queden con el mismo UID del servidor SA (/etc/passwd).
3. Trata de que los grupos sapsys y dba queden con el mismo identificador que en SA (/etc/group)
4. Hacer restore del motor, base de datos, /sapmnt/<SID>, /usr/sap/trans, /usr/sap/<SID> en SN.
5. Modificar los profiles de SAP con los nuevos nombres de host.
6. Hacer el upgrade del motor de la base de datos en SN.
7. Correr los scripts de oracle para pasar la base de 8 a 10.
8. Una vez que todo este en orden con la base (Que haya levantado oracle), hacer con el usuario <SID>adm R3trans -d. El codigo de retorno del comando deberia ser 0. Si es 12, hay que revisar el trans.log
9. Una vez que todo este en orden, proceder al prepare.

Exitos!!!

[Vizcayno]

Interesante secuencia, muchas gracias por la respuesta. A este punto permíteme por favor hacerte dos consultas complementarias:
1) En qué queda entonces el Oracle 10 que ya tengo instalado en SN? ¿No es posible que el backup de la base de datos hecha en el SA bajo Oracle 8.1.7 pueda ser importada por Oracle 10? ¿Debo instalar Oracle 8.1.7 en SN también?
2) ¿Con la solución que propones, es posible que pueda cambiar el ID del sistema SAP en SN -por ejemplo a DEV- antes del upgrade? Pregunto esto porque, debido a limitaciones de hardware, el servidor SN era antes el servidor SAP 46C de pruebas con SAP ID = DEV pero tuve que inicializarlo y prepararlo para recibir una copia del servidor SA e intentar garantizar un posterior upgrade seguro en el servidor de producción. En ambos casos, el obstáculo es que debo hacer un upgrade del Sistema operativo y el upgrade de la base de datos.
Muchas gracias de nuevo!!!

[johangonz]

La opción 1 no es viable ya que es imposible hacer.

Lo ideal es que copies el sistema al SN, ya sea con Oracle 8 o que le hayas hecho un upgrade a Oracle 10. Creo que no puedes llevar una base de datos de 8 a 10 a través de un Export/Import, pero de 9 a 10 sí, certificado por SAP y lo he hecho particularmente así que yo en tu caso haría lo siguiente:

Instalaria en el nuevo 4.6 con Oracle 8 para olvidarme del viejo server, y haria un export/import en vez de copia homogenea. Por qué Export/Import? porqué en este haría una reorganización de tablas, evitando el particionamiento y en el SN haria una redistribución de los datafiles en los filesystem para optimizar la distribución y mejorar performance, teniendo de manera mas ordenada el fs que con el tiempo se vuelve un poco desordenado. Luego me hago en SN el upgrade a Oracle 10 (no estoy seguro que se pueda, seria cuestion de buscar la documentacion) o en su defecto a Oracle 9 y luego a 10. Después de esto si inicio el proceso de Upgrade normal a 6.0, recuerda que un Upgrade es sobretodo upgrade funcional, por ende no vas a poder jamas tener un sistema en 6.0 e insertarle un schema de db de 4.6.

Valida que el SN tenga todos los parches de OS antes del upgrade de release de SAP, al igual que la bd con el ultimo patch + CPU + Interim.

[h_rossi]

Perdon por la demora en la respuesta, pero recien hoy volvi a tener contacto con internet.

Respecto de tus pregunta:

1) Deberias tener el mismo motor en SN y SA, para luego restorear la base y hacer el upgrade de ambas cosas (Motor y Base).

Recorda que para pasar de 8 a 10, debes hacer el upgrade de 8 a 9 y luego de 9 a 10. Cada paso con su respectivo procedimiento de corrida de scripts para subir el nivel de la base. Que quede claro que hablar del motor es ditinto a hablar de la base.

2) Cuando ya esta el upgrade del motor y base de datos, podes realizar el cambio de SID de la base, obviamente que los profiles de SAP y de usuarios de UNIX deben ser modificados desde el SID viejo al SID nuevo. NO olvidar que el script para levantar y bajar SAP, tambien deben ser modificados. EL SID de la base debe ser cambiado por un DBA o con un instructivo. No es muy dificil, pero tiene su complejidad.

Un comando muy facil para hacerlo es:

Desde Unix: vi <ARCHIVO>
Dentro del vi: :%s/DEV/QUA/g

DEV seria el SID viejo.
QUA seria el SID nuevo.

Creo que conteste todo, pero no tengas dudas de consultarme.

Saludos.

[Vizcayno]

Hola H_ROSSI:
Me apresto a realizar el proceso de copia al servidor de pruebas. Ya instalamos el nuevo sistema operativo solaris 10, incluí parches y el DBA está armando los file systems en SN basado en SA. A este punto surgieron tres consultas más:
1) En SN aparte de cambiar el nuevo nombre del sistema en los archivos de parámetros de SAP (en mi caso de PRO a DEV) también necesitaré cambiar el nombre de los directorios, ¿no es cierto? por ej: de /usr/sap/PRO a /usr/sap/DEV? En qué quedan los archivos que tengan como extensión .PRO? por ejemplo los archivos de transporte que se encuentran en /usr/sap/trans?
2) Qué cuidados debería tener con la capa de transporte DEV -> PRO?
3) Voy a necesitar pedir a SAP la nueva clave de la instalación?

Muchas gracias nuevamente!!

[johangonz]

Lo transparente es que ejecutes el proceso de copia Homogenea que SAP recomienda y que ya tiene documentado, no tiene complicación alguna y el sólo realiza todo junto a los pasos adicionales que se exigen realizar documentados en la guía que te comento.

No sé que procedimiento estés siguiendo, pero lo lógico es que los FS se llamen con el nuevo SID si es lo que deseas cambiar.

No veo por qué inventar la rueda si ya existe, sólo es seguir el manual y ponerla a rodar.

[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.

[h_rossi]

Bueno, vamos por partes:

1- Logicamente que hay que cambiar los nombres de los filesystems. /sapmnt/<SID NUevo> - /usr/sap/<SID Nuevo>. Respecto de los archivos con extensión .PRO, no te hagas problema, esos archivos deben ser los DATA y COFILES de los transportes. Estos mismos los podes agregar a la cola de transporte con un addtobuffer o desde la STMS.

2- En la capa de transporte deberias definir el nuevo dominio, para ello, deberas borrar la configuración antigua y redefinirla. Cualquier cosa me lo consultas y lo vemos en detalle.

3- Vas a necesitar una nueva licencia para el nuevo ambiente. En este caso, DEV.

Espero que haya sido de utilidad. Ademas, estoy de acuerdo con no utilizar la copia homogenea para bases grandes de verdad. En bases de 300 o 400 Gb puede aplicar, pero en bases de Teras, este es el metodo mas rapido y eficaz. Funciona porque lo hago habitualmente.

[Vizcayno]

Hola H_ROSSI:

Pude efectuar la instalación y levantar SAP en el nuevo servidor. Agradezco tu ayuda y consejos y del mismo modo a Johan.
Al final apliqué una solución mixta:
1) Dejé que el DBA utilice las herramientas más frecuentes que tiene a su alcance para lograr tener un servidor Solaris 10 con Oracle 10.2.0.4 conteniendo los datos de SAP producción. Armó los filessystems necesarios.
2) Terminado ese trabajo, tuve la necesidad de “actualizar” el CD Kernel de SAP para que acepte las nuevas versiones de Oracle e imagino que otras mejoras. La nota SAP 980981 y sus relacionadas me ayudó con esto.
3) Luego de usar el INSTTOOL.SH, comencé con R3SETUP –f CENTRAL.R3S y tipo de instalación “Copy on file System”
4) Terminada la instalación, inicié con startsap y la aplicación levantó. Efectivamente le asigné la clave de instalación y el sistema ya fue operable.
Lo siguiente que haré es establecer las rutas de transporte, necesito leer un poco más para aclarar unas dudas.
Tropecé con dos problemas inesperados, al menos para mí:
1) No logro acceder a la aplicación en idioma español. A pesar de que la trn SMLT me indica que el Language pack en español está presente (con luz verde), al momento de login por SAPGUI, lo considera como lenguaje inválido.
2) Cuando ingreso al RZ10, los nombres de los perfiles hacen referencia al servidor de producción y a nivel del FyleSystem los nombres de los archivos de perfiles hacen referencia al nuevo servidor. Seguramente debo hacer una sincronización pero en principio no se me ocurre una forma de hacerlo.
Será que puedes darme una mano con estos puntos?
Muchas gracias de nuevo.