2. Tabla de Contenidos
0-OBJETIVO................................................................................................................................................3
1-ALCANCE................................................................................................................................................3
1.1-A QUIEN VA DIRIGIDO?.............................................................................................................................3
2-PRE REQUISITOS..................................................................................................................................4
2.1-BASE DE DATOS.......................................................................................................................................4
2.1.1-¿Para que utilizamos LOGs Transaccionales?...........................................................................5
2.1.2-Ajuste de la base de datos PRE COPIA......................................................................................5
2.1.3-Ajuste de LOGs de la base de datos PRE COPIA.......................................................................9
2.2-INSTANCIA SAP....................................................................................................................................12
2.3-CONEXIONES RFC.................................................................................................................................16
2.4-BACKUP...............................................................................................................................................21
3-CONFIGURACIÓN DE LA COPIA DE MANDANTE.....................................................................23
3.1-PROCESOS PARALELOS............................................................................................................................24
3.2-PREVER JOB DE FONDO............................................................................................................................25
4-MONITOREO DE LA COPIA DE MANDANTE..............................................................................28
4.1-MONITOREO PUNTUAL............................................................................................................................30
4.2-LOG DE FINALIZACIÓN DE COPIA DE MANDANTE..........................................................................................31
5-TAREAS POST COPIA DE MANDANTE..........................................................................................32
Página 2 de 34
3. 0-Objetivo
Desarrollar una guía paso a paso para utilizarla como apoyo ante la solicitud de
una copia de mandante.
1-Alcance
El siguiente documento detalla de punta a punta la configuración para la
realización de una copia de mandante. Este documento aplica para todos los sistemas.
Se verán aspectos básicos de la copia, hasta detalles en los parámetros de la
instancia.
1.1-A quien va dirigido?
A todos aquellos administradores del sistema SAP R/3.
Página 3 de 34
4. 2-Pre requisitos
El sistema SAP R/3 esta compuesto básicamente por dos partes
fundamentales.
Instancia SAP
Base de datos
En el momento de tener que realizar una copia de mandante, debemos tener
en cuenta aspectos tanto de base de datos como de instancia de SAP. A continuación
veremos que debemos tener en cuenta a la hora de realizar una copia de mandante.
2.1-Base de datos
La base de datos esta compuesta básicamente de dos componentes
esenciales.
Motor de base de datos
Instancia de base de datos (Ej.: DEV)
Cuando se tiene una instancia de base de datos, los datos son guardados en
una serie de archivos denominados DATAFILES, y los datos que no han sido
confirmados, se mantienen en uno o varios archivos denominado LOGS
Transaccionales.
Todas las transacciones que se realizan en la base de datos pasan
básicamente por seis (6) estados antes de llegar a ser almacenados en los
DATAFILES. Los estados son:
Creación del/los dato/s
Procesamiento del dato/s
Guardado del/los dato/s
Confirmación del/los dato/s (COMMIT)
Rechazo del/los dato/s (ROLLBACK)
Almacenado del/los dato/s
Página 4 de 34
5. Todos aquellos datos que no hayan sido confirmados “COMMIT”, se
mantendrán en los LOGS transaccionales. Una vez confirmados los datos, se bajaran
los mismos a los DATAFILES liberando el LOG transaccional.
2.1.1-¿Para que utilizamos LOGs Transaccionales?
Los LOGs Transaccionales cumplen una función vital en los sistemas de base
datos dado que ante una posible caída de la misma, todas aquellas transacciones que
no hayan sido confirmadas y/o procesadas no podrían recuperarse si estos archivos
no existieran.
Al recuperar una base de datos, se deben restaurar los archivos de datos
(DATAFILES) y los LOGs transaccionales, para que la base de datos quede con los
datos al mismo momento de la caída.
Estos LOG estarán en funcionamiento mientras que el administrador de la base
de datos así lo mantenga. Existe otro modo de configuración de los mismos que se
denomina “AUTO OVERWRITE”. Este modo no mantiene los logs transaccionales en
un archivo, sino que están en memoria y luego son bajados o no a los DATAFILES.
Las bases de datos que están funcionando en sistemas productivos, no debería tener
configurada esta opción, dado el gran riesgo de perdida de datos que puede ocasionar
la caída del sistema. En sistemas de desarrollo puede llegar a tolerarse este modo,
pero lo recomendable es que este configurado de igual modo que en el sistema
productivo.
2.1.2-Ajuste de la base de datos PRE COPIA.
Como mencionábamos anteriormente, debemos realizar una serie de ajustes
en la base de datos antes de realizar la copia de mandante.
Antes que nada, debemos hacer una análisis de la base de datos FUENTE vs
la DESTINO (PRD to DEV). Para ello debemos ver en primera instancia los espacios
reservados “DATAFILES” en ambas bases y el espacio libre que tenemos en los
mismos.
Página 5 de 34
6. El software a utilizar para realizar dicha verificación es el “DATABASE
MANAGER” cuyo icono es el siguiente:
Veamos un ejemplo:
Base de datos DEV:
Figura 1
Base de datos PRD:
Figura 2
Hagamos un análisis de las bases de datos:
Figura 3
Página 6 de 34
7. En este caso, ambas bases de datos tiene los mismo valores tanto de
asignación de espacio como de ocupación, por lo tanto, una copia de mandante bajo
este esquema no requerirá demasiados cambios. No obstante, podemos suponer que
la base de datos de desarrollo tiene menos espacio asignado, debiendo realizar tareas
de mantenimiento para la copia. Veamos el escenario planteado.
Figura 4
Para el escenario planteado en la figura 4, debemos hacer que la base de
datos crezca en tamaño total con el fin de poder realizar la copia sin que los
DATAFILES se llenen como consecuencia de la copia.
Para ello, debemos utilizar la herramienta de gestión de base de datos
denominada “DATABASE MANAGER”. Veamos paso a paso la asignación de un
nuevo datafile.
Figura 5
En la figura 5 vemos la pantalla inicial del gestor de base de datos, donde en la
parte de la derecha de la pantalla encontramos los datos relevantes al estado de la
base de datos. A la izquierda de la pantalla, se observa un menú vertical donde
seleccionaremos la opción CONFIGURACION.
Página 7 de 34
8. Figura 6
Como se observa en la figura 6, seleccionando la opción VOLUMES,
visualizamos los DATAFILES que tenemos actualmente en la base de datos.
A continuación, agregaremos un datafile para incrementar el total de la base de
datos. Este proceso se puede realizar con la base de batos funcionando.
De la figura 6, seleccionaremos DATA0003 y haremos doble clic con el botón
izquierdo del Mouse. Una vez realizada esta acción se abrirá la siguiente pantalla.
Figura 7
Si observamos con detenimiento, el sistema nos propone un tamaño de datafile
igual a los preexistentes. En nuestro caso, modificaremos el tamaño a 5 GB dado que
Página 8 de 34
9. no se requiere espacio extra. Una vez seteado este valor, pulsaremos la opción OK.
NOTA: Cabe destacar que para bases de datos de gran espacio, el proceso puede
demorar varios minutos.
Figura 8
Como vemos en la figura 8 observaremos que se ha añadido un nuevo datafile
siendo, en conjunto con los existentes, suficiente para que la copia no cancele por falta
de espacio.
2.1.3-Ajuste de LOGs de la base de datos PRE COPIA.
Cuando se efectúan trabajos de larga duración tales como: Copias de
mandante, incremento masivo de datos en la base de datos, aplicación de support
package, etc, los logs de la base de datos deben estar en modo AUTO OVERWRITE.
Como decíamos anteriormente, los logs de la base de datos, tanto en DEV, QUA y
PRD deben estar en modo de escritura en fichero. En el caso de que comencemos
una de las tareas antes mencionadas sin realizar el switch de los logs a AUTO
OVERWRITE, lo más probable es que los mismos lleguen al máximo de su capacidad
y por ende, la base de datos quede congelada.
Con el fin de evitar esta situación, se presenta un detalle paso a paso para
realizar el switch.
Página 9 de 34
10. Figura 9
En la figura 9 observamos la pantalla inicial del administrador de base de datos
“DATABASE MANAGER”, donde debemos seleccionar la opción “CONFIGURATION”.
En ella, seleccionaremos la opción “LOG SETTINGS” para realizar el switch a AUTO
OVERWRITE. Una vez seleccionado, se despliega una pantalla que nos ofrece tres
opciones, nosotros solo nos concentraremos en una. En la figura 10 se ve en detalle.
Página 10 de 34
11. Figura 10
Seleccionada la opción “Overwrite Mode for the Log Area”, pulsamos OK para
que la base de datos tome los cambios. En la figura 11 se ven ambos estados.
Modo normal de operación
Modo espacial de operación (SWITCH DE BASE DE DATOS)
Una vez configurada la base de datos, nos queda revisar los parámetros de
instancia de SAP. Los mismos serán revisados en el apartado siguiente.
Página 11 de 34
12. 2.2-Instancia SAP
La instancia de SAP tiene una serie de parámetros que son estáticos y otros
que son dinámicos.
En el caso de una copia de mandante, debemos realizar el cambio de un
parámetro dinámico de instancia, cuya función es la de establecer un limite máximo de
utilización de las sesiones de dialogo (DIA). Para realizar dicha modificación, debemos
utilizar la transacción RZ11, tanto en el servidor destino como en el fuente (PRD y
DEV). En el caso de existir múltiples APPLICATION SERVERS, dicho parámetro
deberá ser modificado en cada uno de ellos dado que los mismos tienen parámetros
independientes.
El parámetro a modificar es: rdisp/max_wprun_time
El mismo, puede estar configurado con diversos valores, aunque sea ha visto
que el común denominador es entre 600 y 1200. Para el caso de una copia de
mandante, este valor deberá ascender a 4400 con el fin de extender el TIME OUT a
una posible lectura a una tabla. En muchas ocasiones, este parámetro no es
modificado y las copias terminan exitosamente. Igualmente, y con el fin de evitar
posibles cancelaciones de copia de tablas extremadamente grandes, debemos
cambiar este parámetro al valor sugerido.
A continuación veremos en detalle como modificar este parámetro.
Figura 11
Página 12 de 34
13. En la figura 11 observamos la pantalla inicial de la transacción RZ11 con el
parámetro a modificar. Pulsando el botón veremos una pantalla similar a
la de la figura 12.
Figura 12
Como podremos observar, el parámetro esta configurado para que el límite
máximo sea de 600. Independientemente de ello, por definición veremos que el
parámetro esta configurado en 600, vale decir que, si el servidor se llegara a reiniciar,
la instancia tomara el valor por defecto (600).
Para modificar el valor actual del parámetro de instancia, debemos pulsar el
botón situado en la parte superior de la pantalla. En ese instante, el
sistema presentara una pantalla tal como se ilustra en la figura 13
Página 13 de 34
14. Figura 13
Si observamos con detenimiento, la pantalla presenta solo un campo editable,
cuya función principal será la de setear el valor del parámetro al que nosotros le
designemos. En nuestro caso, dicho valor será de 4400.
Una vez seteado el nuevo valor al parámetro en cuestión, el sistema nos
presentara una advertencia tal como lo ilustra la figura 14.
Figura 14
Ante la advertencia que nos presenta el sistema, debemos aceptarla y
continuar con el proceso de preparación para la copia.
En la figura 15, veremos el resultado de los cambios efectuados en el
parámetro, confirmando que el mismo se encuentra vigente.
Página 14 de 34
15. Figura 14
Una vez que estamos seguros que los cambios fueron realizados con éxito,
debemos realizar la verificación de las conexiones RFC entre los sistemas FUENTE y
DESTINO.
Página 15 de 34
16. 2.3-Conexiones RFC
En esta sección veremos la importancia de la configuración de las conexiones
RFC, para la realización de la copia de mandante.
La misma será verificada desde la transacción SM59, cuya función es la de
crear, modificar y realizar pruebas de las conexiones RFC. En la figura 15 veremos la
pantalla inicial de la transacción.
Figura 15
Como vemos, hemos desplegado el ítem “CONEXIONES R/3”, donde dentro
del mismo se encuentran las conexiones RFC configuradas por el sistema y por los
usuarios. En este caso, realizaremos pruebas sobre la conexión PRD400, y
mostraremos en detalle el desarrollo de la misma.
A continuación, seleccionaremos la conexión PRD400 haciendo doble clic
sobre la misma.
Página 16 de 34
17. Figura 16
En la figura 16, se presentan datos básicos de la conexión tales como:
Destino RFC.
Tipo de conexión.
Nombre de host destino.
Dirección IP del equipo destino.
Dentro de la misma pantalla, encontramos tres (3) solapas cuyos datos
solicitados, algunos de los cuales fueron detallados anteriormente, son el usuario y
contraseña del sistema destino, mandante e idioma.
En la figura 17, veremos los datos de la siguiente solapa, donde nos presentara
los datos antes mencionados.
Página 17 de 34
18. Figura 17
Con las configuraciones de las figuras 16 y 17, solo restaría realizar las
pruebas de conectividad con el sistema destino. Para ello, utilizaremos las
herramientas suministradas por la transacción, cuyos botones son:
En primer termino, pulsaremos el botón , donde el sistema
presentara una pantalla tal como la de la figura 18.
Página 18 de 34
19. Figura 18
En función de la figura 18, vemos que la conexión con el sistema destino esta
en perfecto estado, debiendo realizar la ultima prueba correspondiente al login remoto.
El mismo deberá ser probado con el botón . En la figura 19
veremos la pantalla en el caso de que el login remoto sea exitoso.
Figura 19
En el caso de que el login remoto no funcione correctamente, la pantalla que
ilustrara el sistema será como lo muestra la figura 20.
Figura 20
Página 19 de 34
20. En el caso de que la prueba de conexión remota finalice como la figura 20,
debemos verificar que el usuario y contraseña existan en el sistema destino. En el
caso de que existan, se deberá ingresar al sistema remoto de modo normal
(SAPLOGON) y reconfigurar la contraseña.
Una vez solucionado el tema de la conectividad, podremos comenzar con la
configuración de la copia de mandante.
Página 20 de 34
21. 2.4-Backup
El sistema SAP R/3, generalmente, es sometido a un backup diario on-line de
su base de datos, por lo tanto, debemos revisar el dia y horario en que se ejecuta el
job, de manera tal de poder suspender todas las tareas que puedan entorpecer la
copia de mandante.
Para revisar dichos jobs, debemos ingresar a la transacción DB13, donde
veremos el plan mensual de los backup.
Figura 21
En nuestro caso, pulsaremos con el botón derecho del Mouse sobre los
trabajos que están programados para el día de la copia, mostrando el siguiente menú
de opciones.
En el menú que a continuación veremos, debemos seleccionar la opción
“Delete action” por cada uno de los jobs que estén programados para ese día. No
olvidar tomar nota de los mismos para efectuar la reprogramación posterior a la
finalización de la copia de mandante.
Página 21 de 34
23. 3-Configuración de la copia de mandante.
Una vez finalizadas las configuraciones de los pre requisitos, debemos
comenzar con la configuración de la copia de mandante. Para realizar dicha
configuración, debemos ingresar a la transacción SCC9 (Mandante destino), donde
planificaremos la misma como proceso de fondo. En la figura 23, veremos la pantalla
inicial de la transacción mencionada.
Figura 23
Como vemos en la figura 23, hemos definido el mandante fuente (De quien
queremos copiar), con un perfil SAP_ALL para hacer una replica exacta, y al
mandante 220 como destino final. Las copias de mandante pueden ser de distintos
modo, cuya definición se realiza en el perfil. El mismo puede variar según lo ilustra la
figura 24.
Figura 24
Página 23 de 34
24. 3.1-Procesos paralelos
Una vez seleccionado el perfil de copia de mandante, procederemos a definir la
cantidad de procesos paralelos que utilizaremos para realizar lo mismo. Este
parámetro debe definirse en función del hardware que tengamos en el momento de la
copia. En nuestro caso, hemos definido que la cantidad de procesos paralelos serán
ocho (8).
Para realizar dicha configuración, debemos seguir los pasos de la figura 25.
Figura 25
Una vez seteada la cantidad de procesos paralelos procederemos a salvar los
cambios pulsando el botón con la imagen del diskette de la figura 25 volviendo a la
figura 23 como consecuencia de esta acción.
Página 24 de 34
25. 3.2-Prever job de fondo
Pulsando el botón , el sistema nos ilustra la pantalla
de la figura 26, que nos guiara para prever el job de fondo.
Figura 26
En la misma, debemos definir cual será el servidor de fondo, el cual será el
responsable de correr el proceso de copia de mandante. Pulsando el match code, el
sistema nos ofrecerá los servidores disponibles para dicha tarea. En la figura 27
veremos el servidor seleccionado.
Figura 27
En la figura 28 veremos como se completara la pantalla de la figura 24,
indicando en la misma los pasos a seguir.
Página 25 de 34
26. Figura 28
Una vez seleccionado el servidor de fondo, debemos pulsar el botón
, donde el mismo nos presentara una pantalla para la planificación del job que
ejecutara la copia. En la figura 29 visualizaremos la misma.
Figura 29
Página 26 de 34
27. Una vez planificado el job, el sistema nos dará un resumen de los parámetros
configurados para su verificación final. En el caso de que los datos sean correctos,
debemos aceptar el mensaje para dejar planificada la tarea. Si por algún motivo,
vemos que los datos no son correctos, debemos cancelar inmediatamente el mensaje
y corregir los parámetros deseados.
En la figura 30 ilustraremos el resumen final de la planificación del job.
Figura 30
Como podemos observar en el resumen de la figura 30, la copia será desde el
mandante 400 de producción al mandante 220 de desarrollo, con perfil SAP_ALL y con
ocho (8) procesos paralelos tal se había definido anteriormente.
Página 27 de 34
28. 4-Monitoreo de la copia de mandante.
El monitoreo de la copia de mandante es vital para realizar tareas sobre la
marcha ante un problema inesperado. El mismo, se realiza desde la transacción
SCC3, donde en la misma, veremos el desarrollo de la copia paso a paso.
A continuación presentamos la pantalla inicial de dicha transacción.
Figura 31
En la figura 31, observamos que la pantalla inicial de la transacción SCC3 nos
informa acerca de las copias del mandante 210. Esto se debe a que la misma fue
ejecutada desde el mandante 200, ya que el mandante 220 se encontrara bloqueado a
lo largo del proceso de la copia.
Para poder ver el proceso en otros mandantes, debemos pulsar el botón
, donde tendremos una vista ampliada de los mandantes.
Figura 32
Página 28 de 34
29. En la figura 32, observamos el status del estado de las copias en todos los
mandantes, pudiendo ver que han finalizado con éxito. En el caso de que quisiéramos
mas detalles, debemos realizar un doble clic en el mandante en el que deseamos ver
cual es el avance. Para nuestro caso, el mandante será el 220.
Figura 33
Página 29 de 34
30. 4.1-Monitoreo puntual
En la figura 33 vemos todas las copias que se han realizado en el mandante
220 con sus status de finalización. Para nuestro caso, nos focalizaremos en la ultima
copia realizada en día 05/05/2007. Por lo tanto, realizaremos un doble clic en el mismo
para ver los detalles del mismo.
Figura 34
En la figura 34 vemos una pantalla típica de monitoreo del proceso de copia de
mandante. En este caso, figura como finalizado con éxito, pero en el caso de que el
mismo estuviese corriendo, nos presentaría información acerca de las tablas que se
encuentra copiando, la líneas insertadas y borradas y la cantidad de tablas copiadas
hasta el momento.
Página 30 de 34
31. 4.2-Log de finalización de copia de mandante
Finalizado el proceso de copia, el sistema nos presentara la pantalla de la
figura 34, pudiendo, en el caso de que sea necesario, revisar el log de la copia
pulsando el botón , presentado la pantalla de la figura 35.
Figura 35
El log nos da información acerca de cómo finalizar el proceso de copia,
ejecutando un reporte de una transacción que veremos mas adelante.
Página 31 de 34
32. 5-Tareas post copia de mandante.
Una vez finalizada la copia de mandante, debemos correr un reporte
denominado RGUGBR00 desde la transacción SE38.
A continuación, se presenta la pantalla inicial de dicha transacción.
Figura 36
En la figura 36, en el campo “PROGRAMA”, indicaremos el reporte mencionado
anteriormente, finalizando el proceso pulsando el botón ó la tecla de función “F8”.
En ese mismo instante, el sistema nos ofrecerá múltiples opciones para la ejecución
del mismo, debiendo seleccionar los indicados en la figura 37.
Página 32 de 34
33. Figura 37
Una vez seleccionadas las opciones de la figura 37, pulsaremos nuevamente el
botón ó la tecla de función “F8”. Luego del evento anteriormente explicado, el
sistema informara los resultados del reporte, finalizando el proceso de copia de
mandante. En la figura 38, vemos dicha pantalla.
Figura 38
Página 33 de 34
