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.

[h_rossi]

Hola:

Vamos por puntos:

1- Para verificar que el lenguaje este bien instalado, debes revisar un par de cosas.

Desde la trx SE38 ejecuta el reporte RSCPINST y verifica que el lenguaje español este registrado. De estar registrado, este punto queda sin efecto, sino, debes agregarlo con el boton AGREGAR +.

El otro punto es verificar si los paramentros de instancia son correctos, para ello debes ir a la trx RZ10 -> Utilities -> Import Profiles -> Of Active Servers. Una vez finalizado este proceso, debes seleccionar el profile (Desde el matchcode) DEV_DVEBMGS00_<Nombre de host> -> Extended maintenance -> Change. Cabe aclarar que estos fueron modificados desde el sistema operativo como te comentaba en respuestas anteriores.

Ya dentro de los paramentros, pulsas F5. En el campo PARAMETER NAME ingresas el siguiente paramentro: zcsa/installed_languages y pulsas la tecla ENTER del teclado. En el campo parameter value deberia figurar DES (D=Aleman - S=Español - E=Ingles). Si llegara a faltar la letra "S", ingresala y luego pulsa el boton COPY (SHIFT+F4), luego F3 y nuevamente F3. Cuando pida salvar los cambios seleccionas SI o YES y luego pulsas el boton con forma de Diskette para activar el perfil. Por ultimo queda realizar desde el sistema operativo con el usuario devadm un stopsap y luego un startsap.

2- En la RZ10 puede que aparezcan los nombres de los profiles viejos. Si quieres que estos no esten mas, debes limpiar dos tablas de la base de datos.

Las tablas son: TPFET y TPFHT. Si estas en oracle, con el usuario oradev haces: sqlplus -> username: sapr3 o sapsr3 -> password: La deberia saber el DBA.

Ya dentro del sqlplus: delete from TPFET;
delete from TPFHT;
commit;

Luego, como te comente en el punto 1, debes importar nuevamente los profiles: debes ir a la trx RZ10 -> Utilities -> Import Profiles -> Of Active Servers.

Ahi estaria listo estos temas.

Exitos!!!!

[Vizcayno]

Hola H_ROSSI:
Nuevamente gracias por las indicaciones, las seguí con precisión. Efectivamente el lenguaje español no estaba incluido, una vez agregado lo activé.
Al momento de efectuar el starsap luego de efectuar los cambios en los perfiles no hubo inconvenientes, pero cuando intenté ingresar por SAPGUI me mostró una pantalla en blanco y el error: "Error when generating text environment". hasta ese momento una parte del archivo DEV_DVEBMGS00_mercurio era:
[/INDENT]zcsa/installed_languages = DSE
zcsa/system_language = S
[INDENT]eu/iwb/installed_languages = ES
eu/iwb/path_win32 = \\enfile\Sap\Help_SAP\HTMLHELP\HELPDATA
luego, puse un comentario en zcsa/system_language = S
Luego de bajar, volví a levantar SAP y ya me mostró la pantalla de login, siempre en inglés. Intenté efectuar el login ingresando los datos correspondientes y en lenguaje puse 'ES' pero me emite un error: Language Environment can not be configured.
Volví a verificar las configuracions del lenguaje comparando con el sistema productivo y no encuentro nada anormal.

Pregunto si no se tratará de un tema de configuración del sistema de transportes, eso aún no lo tengo resuelto.

[h_rossi]

Dos cosas:

1- El idioma supongo que no estaba incluido en el reporte que te mencione y lo incluiste. De ser asi, vas a tener que configurar la STMS y luego reimportar el lenguaje. Esto ultimo desde la trx SMLT

2- El sistema de transportes debes configurarlo en el mandante 000 con el usuario DDIC.

Haz esto y cuentame.

Salutes

[Vizcayno]

Los colegas que ven el sistema operativo está analizando el tema del idioma en el Solaris 10, al parecer el "locale es" (español) situado en /usr/lib/locale no está correctamente configurado o está incompleto, creo que el problema del lenguaje puede ir por ahí también.

En cualquier caso, estoy comenzando a configurar el sistema de transportes. No estoy muy firme con este tema pero claro, lo estoy haciendo en un entorno de desarrollo. Sin embargo, el solo hecho de que luego debo integrarlo con Producción ya me asusta porque además existe riesgo de perder información (según indican algunos documentos).

Ruego paciencia en este tema porque tengo unas consultas fruto de mis lecturas que me ayudarán a estar más afianzado:
1) Ejecuté la trn SE06 con la opción "Database Copy or migration option", luego hice click en “Post-installation Processing”, Cuando pregunta “Do you want to re-install the CTS? Le respondí con con “Yes”, cuando pregunta “for the Source System of Database Copy?”, seleccioné el sistema de producción (PRO). Luego me pregunta “Change originals from PRO to DEV?” y respondí con “Yes”, a la pregunta “Delete TMS Configuration?” presioné “Yes”, a la pregunta “Delete old TMS configuration?” también presioné “Yes” y finalmente me preguntó “Delete Old Versions of transport routes?” a lo que respondí con “No”

Ahí me quedé sin aliento para seguir porque necesito resolver las siguientes dudas:
1) Entiendo que debo “compartir” la carpeta /usr/sap/trans a nivel del sistema operativo en DEV, ¿no es cierto?
2) En DEV, el sistema existente está como Domain Controller, en PRO tengo a los sistemas de transporte DEV que no es domain controller y a PRO que es es Domain Controller, el sistema DEV que se halla descrito en PRO está apuntando a la base de datos antigua que había antes de DEV, en todos los casos están activos y up-to-date. Tengo dos preguntas: (1) Está bien que hayan 2 domain controller? Y (2) debo modificar el sistema DEV en el servidor de Producción? como hago eso?
3) En algunos documentos cita que el sistema DEV de transportes que tengo en el servidor DEV necesito ingresarlo al “grupo de transporte” pero con otro nombre porque si lo mantengo como sistema de transporte llamado DEV colicionaría con el DEV que se halla en Producción y perdería datos porque las órdenes de transporte que se vayan a crear solaparían las anteriores que hicimos. Es así?
4) Luego del SE06 que hice cuales serían los siguientes pasos teniendo en cuenta el escenario en el que me encuentro?
Creo que ya son las últimas consultas, espero tu ayuda de nuevo.
Muchas gracias.

[h_rossi]

Por puntos:

1- Si, es cierto. Yo te recomendaria que lo compartas de igual forma que el antiguo servidor.

2- Mira, puede haber dos sistemas de transportes, pero en un mismo landscape, lo ideal seria que solo haya un solo domain_controler. Lo que vas a tener que hacer es lo siguiente: En el servidor PRO trx STMS -> EXTRAS -> DELETE TMS CONFIGURATION. Lo mismo debes realizar en el servidor DEV.

Luego, debes ir a la trx RSPFPAR en DEV y PRO y en el campo de selección ingresar: DIR_TRANS (Pulsar F8). Tomar nota de los resultados. En ambos sistemas ingresar a la trx RZ10 y modificar el profile DEV_DVEBMGS00_mercurio y PRO_DVEBMGS00_<hostname>. Revisar el parametro DIR_TRANS y en DEV, asignar la ruta completa de transporte, por ejemplo:c:\usr\sap\trans y en PRO asignar \\mercurio\trans (Esto va depender de como se realice la compartición de los directorios. Obviamente que esa carpeta compartida debe poder ser accedida por el usuario <SID>adm y ora<SID>.

Despues de haber realizado estos cambios, debes reiniciar las instancias SAP (DEV y PRO) para que tome los cambios de paramentros.

Ahora, una vez levantados los ambientes, debes configurar las rutas de transportes, para ello, primero deberas ir al sistema DEV, a la trx STMS. Por defecto, debe proponerte que sea DOMAIN_CONTROLER ya que anteriormente has borrado la configuración. Lo aceptas y dejas a DEV como controlador de domino de transportes del landscape.

Luego, en el sistema PRO, vas a la trx STMS y deberia detectar que hay un domino de transporte y te propone sumarte a él. SI ALGUNO DE ESTOS PASOS NO FUNCIONA, ENVIA EL ERROR ASI LO VEMOS. Suponiendo que todo marcha viento en popa, y te has sumado al dominio de transportes, ahora restaria aceptar al nuevo integrante a la ruta, para ello, deberas ir nuevamente a DEV, a la trx STMS -> Pulsar (SHIFT+F6) y te aparecerauna grilla con los sistemas DEV y PRO donde en la columna STATUS, en la linea de DEV deberia haber un FOSFORO y en PRO un simbolo con tres cuadrados (System waiting for inclusion in domain). Lo aceptas y distribuyes la configuración. TODO ESTO DEBERIA REALIZARSE CON EL USUARIO DDIC en el MANDANTE 000.

3- Si haces bien el punto 2, este no deberia aparecer mas.

4- La SE06 por ahora no la toques.

[Vizcayno]

Hola H_Rossi:
Nuevamente gracias por los consejos.

El error persistente del idioma español se debió a que no incorporamos el driver del idioma español en Solaris 10. Ahora el idioma va bien.

En cuanto al sistema de transportes, en realidad el controlador de dominio es PRO, al menos así se ve con el STMS. Así que eliminé el sistema del nuevo servidor DEV (que también estaba como domain controller) y pedí juntarme a PRO. Al final, tengo dos sistemas que visualizando con STSMS -> System Overview están con sus fósforos activos y en el servidor PRO está con luces verdes en la columna de "status de configuración", supongo que eso indica que todo el sistema de transportes anda bien ¿verdad?. Probaré con unos cuantos "transport requests".

De nuevo y de verdad muchísimas gracias por la ayuda brindada.

[h_rossi]

Notable!!!. Cualquier duda, aqui estamos para ayudarte.

[Agustin Rodriguez]

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.

Hola Rossy , vi tu respuesta y me atrevo a hacer una consulta no creo que sea el tema pero ojala y me puedas dar una orientacion , la pregunta consiste en lo siguiente " Habra alguna manera de hacer un comparativo/reporte de las variaciones que tiene la version 4.7 contra la version 6.0 de SAP?", esto porque vamos a hacer el Upgrade de la version 4.7 a la 6.0 y me preguntan las diferencias entre versiones (por modulo) .

Ojala tubieras algun comentario.

Saludos


Agustin Rodriguez
sataray60@hotmail.com

[nenengo]

Un Saludo Colegas,

Les Consulto A Los Que Hallais Tenido La Oportunidad De Trabajar En Estas Versiones; Con Miras A Documentarme Respecto A Los Cambios O Mejoras Aplicadas Con La Nuva Version.
En Los Modulos:

Sd.
Mm.
Le.
Pp.

Gracias X Sus Aportes