Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
RENDIMIENTO DEL
SISTEMA SAP R/3
ÍNDICE
1. OBJETIVO 4
4.2.1. Conceptos 31
4.2.2. Uso de la memoria de los procesos de trabajo 32
4.2.3. Monitorización de la Memoria de SAP 33
Pág. 2
Estudio del rendimiento del sistema SAP R/3
4.3. SAP Cursor Cache 33
Pág.3
Estudio del Rendimiento del sistema SAP R/3
1. OBJETIVO
El objetivo de este documento es definir los procesos de monitorización del sistema SAP R/3,
usando las herramientas que proporciona SAP.
El gráfico que sigue muestra todos los factores que intervienen en el rendimiento del sistema. SAP
presenta una interficie para monitorizar cada uno de ellos.
A lo largo de este documento iremos viendo cada uno de estos apartados detalladamente,
extrayendo de ellos la información necesaria para comprender y solucionar los distintos problemas
de rendimiento que el sistema pueda llegar a tener.
Pág. 4
Estudio del rendimiento del sistema SAP R/3
2. OPERATIVIDAD DEL SISTEMA
Hay que verificar que el sistema SAP R/3 está operativo y disponible para los usuarios
realizando las siguientes labores de monitorización.
Hay que verificar que las diferentes instancias del sistema SAP R/3 están operativas siguiendo
los siguientes pasos:
Estos procesos se deben realizar varias veces al día usando las herramientas que proporciona el
CCMS (Computing Center Managment System) de SAP.
Transacción SM51
Pág. 5
Estudio del Rendimiento del sistema SAP R/3
Para cada instancia activa muestra el nombre, sobre que nodo está arrancada y que tipo de procesos
de trabajo tiene arrancados.
Hay que asegurarse de que aparecen por pantalla todas las instancias de nuestro sistema y que cada
una de ellas tiene arrancados los procesos de trabajo que le correspondan, sean de dialogo, update,
batch, spool, enqueue o update2.
Transacción SM50
- Status: Muestra el estado actual del proceso de trabajo. Los posibles estados son los
siguientes:
Pág. 6
Estudio del rendimiento del sistema SAP R/3
- Hora: indica el tiempo de ejecución para el paso de dialogo en curso. Si este campo
aparece sobreimpreso en color rojo, indica que ese paso está tardando mucho en ser
ejecutado. Esto lo entenderemos como una alarma y a partir de ese momento hay que
hacer un seguimiento detallado de ese proceso.
- Actividad: Tipo de operación que está realizando: lectura secuencial, lectura directa,
carga de programas, commit, rollback, etc.
- Botón CPU: Indica cuanta CPU ha consumido el proceso de trabajo desde que arrancó.
Si un determinado proceso de usuario consume mucha CPU puede ser indicativo de
problemas.
- Botón de Info Detallada: Seleccionando uno de los procesos de trabajo, muestra qué
acción está realizando, si está esperando por algún recurso, desde cuando y que recurso
es. También da detalles sobre los diferentes tipos de operaciones en la base de datos y
que uso está haciendo de la memoria.
- Ficheros de Trace: Por cada proceso de trabajo existe un fichero de trace en el que se
registra información de interés acerca de cada proceso. Es importante analizarlos con
frecuencia y siempre que haya un problema.
/usr/sap/FLP/DVEBMGS01/work/dev_w*
/usr/sap/FLP/DVEBMGS01/work/dev_disp
/usr/sap/FLP/DVEBMGS01/work/stderr
- Que no hay procesos con el campo Time en color rojo. Si lo hubiera, deberíamos
investigar lo que está haciendo ese proceso de trabajo.
Pág. 7
Estudio del Rendimiento del sistema SAP R/3
- Que los procesos de trabajo tienen una evolución normal, es decir, que procesan
peticiones de diferentes usuarios sin quedarse fijos en un estado determinado.
- Que mantiene un porcentaje de los procesos en estado Espera. Si todos los procesos de
trabajo estuvieran constantemente atendiendo peticiones entonces tendríamos un
problema de rendimiento por falta de procesos de trabajo.
Para poder analizar un problema en un proceso de trabajo hay que ponerse en contacto con el
usuario afectado para poder conocer mas a fondo la problemática de la actividad que está siendo
realizada.
En general, se recomienda ejecutar en fondo y en horas de baja actividad todos aquellos procesos
con tiempos de respuesta altos y que consuman muchos recursos, siempre y cuando esto sea
posible.
Transacción SM21
Pág. 8
Estudio del rendimiento del sistema SAP R/3
Criterios principales de selección para analizar el fichero de log:
- Fecha y hora a partir de la que se quiere analizar: Fecha del último chequeo.
- Usuario: Todos los usuarios (se deja en blanco).
- Tipo de mensaje que queremos visualizar: Todos.
Muestra todos los mensajes de la actividad del sistema que se han ido registrando. Seleccionando el
mensaje se obtiene información más detallada.
El administrador del sistema debe verificar que el R/3 ha arrancado correctamente y debe prestar
especial atención a los mensajes de error y advertencias analizándolos con más detalle.
La mejor fuente de información para el análisis de errores es el servicio OSS en el que podremos
hacer consultas a partir de los mensajes del fichero de log.
El fichero de log debe analizarse varias veces al día y siempre que se detecte cualquier anomalía en
la instancia.
2.1.4. Usuarios
Transacción SM04
Muestra el numero de usuarios que están trabajando en la instancia, desde qué terminal, que
transacción están ejecutando y a que hora se realizó la última acción.
Desde aquí se puede seleccionar un usuario y cancelar alguna de sus sesiones o depurar la sesión si
hubiera algún problema.
Es conveniente ver varias veces al día el número de usuarios que trabajan en cada instancia.
Pág. 9
Estudio del Rendimiento del sistema SAP R/3
2.2. Monitorización del sistema de actualizaciones
Los procesos de trabajo de dialogo y de fondo pueden realizar las actualizaciones a la base
de datos de forma síncrona o asíncrona. En el primer caso es el mismo proceso de trabajo quien
hace las modificaciones directamente en la base de datos, mientras que en actualizaciones
asíncronas, hacen uso de los procesos de trabajo de actualización, siendo estos los encargados de
realizar los cambios en la base de datos.
Si una transacción ha sido programada como actualización asíncrona, esta pasa los registros de
actualización a una cola. Estos registros contienen datos y las instrucciones para modificar la base
de datos. Además, tienen una cabecera creada por la transacción que solicita la modificación y que
sirve entre otras cosas para monitorizar y gestionar los procesos de actualización de SAP.
Un registro de actualización puede tener varios componentes. Dichos componentes pueden ser de
dos tipos:
- Tipo primario o tipo U1
- Tipo secundario o tipo U2
Los primeros realizan las modificaciones criticas. El dispatcher de SAP siempre les asigna mayor
prioridad para que se modifique el contenido de la base de datos cuanto antes. En un registro de
actualización, los componentes U1 siempre se procesan antes que los de tipo U2.
- Verificar si el sistema de actualizaciones está activo o no. Ante problemas graves como
puede ser un error fatal de la base de datos, SAP para automáticamente todas las
modificaciones en la base de datos.
- Volver a procesar si fuera necesario las actualizaciones que hayan acabado con error.
Esta es una labor critica que debe realizarse siempre de acuerdo con el usuario afectado.
Estas tareas hay que realizarlas varias veces al día y siempre que haya habido algún problema que
haya afectado a la base de datos. Por ejemplo un tablespace que no puede crecer más, tablas que no
se pueden ampliar, etc.
A continuación veremos como vamos a ejecutar las acciones definidas anteriormente dentro del
sistema R/3.
Transacción SM13
Pág. 10
Estudio del rendimiento del sistema SAP R/3
Esto lo podemos comprobar con el mensaje “La actualización esta activa” que aparece en la
pantalla de la transacción SM13.
Si el sistema está inactivo, normalmente es debido a un error en la base de datos. Después de
solucionar el problema debemos activar el sistema de actualizaciones de nuevo accediendo a las
opciones que vienen a continuación a partir de la transacción SM13.
Regs.actualización Actualización Activar
Debemos comprobar que no hay excesivos registros en este estado. Si esto ocurre, significa
que tenemos problemas de rendimiento en nuestro sistema que afectan al sistema de actualización.
A partir de aquí debemos estudiar la posibilidad de destinar más procesos de trabajo de tipo
actualización al sistema.
Pág. 11
Estudio del Rendimiento del sistema SAP R/3
Si tuviéramos registros de actualización en este estado, deberíamos analizarlo detalladamente
basándonos en la siguiente información:
Desde la transacción SM13 marcamos el registro erróneo y elegimos el botón Status. Obtenemos
los componentes que debieron ser procesados y su estado.
A partir de aquí:
Esta transacción permite volver a procesar directamente las modificaciones que han fallado
marcando el componente y seleccionando la opción:
El administrador nunca debe realizar esta acción sin consultarlo con el usuario y estudiar el caso
con él. Cuando una actualización acaba con error, SAP envía un mensaje al usuario, quién después
de analizar el problema, volverá a introducir los datos en el sistema. Si el administrador realizara las
modificaciones podrían aparecer inconsistencias en la Base de Datos.
Esta información puede ser de gran ayuda si el usuario no recuerda los datos que introdujo en el
sistema.
Pág. 12
Estudio del rendimiento del sistema SAP R/3
2.3. Monitorización del sistema de bloqueos
Las entradas de bloqueo son objetos de SAP que garantizan la integridad de los datos en la
Base de Datos y coordinan el acceso a los mismos evitando que varios usuarios puedan modificar
una misma información al mismo tiempo.
Para que el sistema de bloqueos trabaje correctamente, se debe cumplir la siguiente condición: Que
el servidor de Enqueue sea único.
Solo habrá un servidor de Enqueue por sistema SAP. Dicho servidor puede tener más de un proceso
de trabajo de enqueue.
El administrador de SAP debe verificar varias veces al día el buen funcionamiento del sistema de
bloqueos.
Normalmente, al finalizar la ejecución de una transacción o al acabar de manipular datos, los
bloqueos se liberan para dejar a ortos usuarios trabajar con los objetos bloqueados anteriormente.
En algunas ocasiones, debido a errores, dichos bloqueos no se liberan.
Las razones más frecuentes por las que un bloqueo permanece sin liberar son:
- SAPGUI Inactivo: A veces ocurre que un usuario que ha iniciado una transacción deja
olvidada una pantalla. Si la transacción ha puesto un bloqueo este permanecerá hasta que
alguien lo libere.
En cualquiera de estas situaciones puede haber usuarios que no puedan trabajar debido a que hay
bloqueos que no deberían existir. En estos casos, el administrador tiene que liberarlos manualmente.
Transacción SM12.
Pág. 13
Estudio del Rendimiento del sistema SAP R/3
· Md: Mandante.
· Usuario: Usuario que ha puesto el bloqueo.
· Instante: Momento en el que se creó la entrada de bloqueo.
· Shared: Indica si el objeto puede ser bloqueado por otro usuario a la vez.
· Tabla: Tabla cuyos datos están bloqueados.
· Arg. Bloqueo: Contiene los valores de los campos clave de la tabla a la que se está
accediendo.
El administrador debe prestar especial atención aquellos bloqueos que se hayan generado hace
mucho tiempo. La larga permanencia de un bloqueo no siempre es indicio de problemas, podrían
ser debidos a un proceso batch muy largo, usuarios que han dejado una pantalla olvidada, etc.
Para borrar manualmente una entrada de bloqueo debemos seleccionarla y acceder a la opción:
Entrada Bloqueo Borrar
Debemos ir con cuidado a la hora de borrar manualmente un bloqueo. Antes de proceder con el
borrado deberemos investigar el motivo por el que no fue liberado junto con el usuario responsable
del bloqueo.
El borrado de un bloqueo podría causar problemas en el sistema.
Para poder minimizar los riesgos de errores, es aconsejable hacer que el usuario afectado elimine
todas sus sesiones activas en SAP. Así, solo permanecerán aquellos bloqueos que no fueron
liberados correctamente.
Pág. 14
Estudio del rendimiento del sistema SAP R/3
2.4. Revisión de los procesos de fondo
Los procesos de fondo son aquellos procesos que se ejecutan sin necesidad de que un
usuario interactúe durante su ejecución. Los procesos de fondo usan procesos de trabajo de tipo
fondo (Batch) cuando se ejecutan.
Transacción SM37.
Seguidamente, obtendremos una pantalla con la información de los Jobs del sistema que cumplen
los criterios de selección que hemos insertado anteriormente.
Podremos chequear el estado del job (planificado, activo, liberado, terminado, listo o cancelado) y
acceder a la opción Log Job para obtener información más detallada sobre la ejecución del Job
seleccionado.
En caso de que un Job no haya sido ejecutado como estaba previsto podremos acceder a la opción
Steps para poder ver que Steps forman el Job y así poder estudiar más detalladamente la causa del
posible problema.
Pág. 15
Estudio del Rendimiento del sistema SAP R/3
El administrador, deberá comprobar que todos los Jobs planificados en el sistema se ejecutan
satisfactoriamente, deberá proporcionar al sistema de suficientes procesos de trabajo de tipo fondo
para que los Jobs planificados de ejecuten sin problemas y deberá ponerse en contacto con el
usuario responsable de la ejecución de un Job para resolver los problemas que puedan ocasionarse
debido a la mala ejecución de dicho Job.
SAP_REORG_JOBS
SAP_REORG_SPOOL
SAP_REORG_BATCH_INPUT
SAP_REORG_ABAPDUMPS
SAP_REORG_JOBSTATISTIC
SAP_COLLECTOR_FOR_JOBSTATISTIC
SAP_COLLECTOR_FOR_PERFORMANCE_MONITOR
Estos Jobs deben estar planificados y deben ejecutarse correctamente tal y como se indica en la nota
de la OSS nº 16083.
Un batch input es un proceso de carga masiva de datos en el sistema SAP R/3. Usa las
transacciones standard como si la información fuera cargada manualmente, haciendo los mismos
chequeos de consistencia de los datos. La carga de datos consta de dos fases:
Mediante el menú
Transacción SM35.
Pág. 16
Estudio del rendimiento del sistema SAP R/3
Desde la pantalla se selecciona que batch input queremos visualizar rellenando los criterios de
selección con la información que tengamos sobre el batch input que queremos visualizar.
Seguidamente pulsamos el botón Resumen y obtenemos información sobre la selección anterior.
Pág. 17
Estudio del Rendimiento del sistema SAP R/3
Por pantalla podemos ver los siguientes datos:
- Revisar el fichero de log de las sesiones que hayan acabado con errores y comunicarlo al
desarrollador o usuario responsable.
- Limpiar la cola de las sesiones, eliminando aquellas sesiones antiguas y borrar los
ficheros de log:
Una vez seleccionado el job, desde el menú: Juego de datos Borrar
Si hay log asociado, pide confirmación para borrarlo.
Si se desea borrar sólo el fichero de log, una vez seleccionado el job:
Pasar a Log Borrar Log
Siempre que haya un error durante la ejecución de un programa ABAP/4, el sistema nos
generará un fichero de Dump después de parar la ejecución del programa.
Dicho fichero contiene información detallada, siempre que el sistema posea información al
respecto, sobre lo sucedido.
Accediendo mediante el siguiente menú:
Transacción ST22.
Pág. 18
Estudio del rendimiento del sistema SAP R/3
Pág. 19
Estudio del Rendimiento del sistema SAP R/3
En la pantalla que aparece en la pagina anterior podemos observar el listado de dumps que se han
generado en el intervalo de tiempo seleccionado en la pantalla anterior.
Aquí podemos ver la fecha y hora en la que se generó el dump, la máquina en la que se produjo, el
usuario que lo provocó, el mandante dónde se ejecutó y una breve descripción del error que
ocasionó el fin de la ejecución del programa.
Obtenemos una pantalla con toda la información detallada que ha podido recoger el sistema.
Siempre que pueda el sistema incluso propondrá posibles soluciones al problema. El análisis de los
dumps de los programas ABAP/4 deben ser realizados por el usuario causante del error junto con la
colaboración del administrador del sistema.
del sistema deberá monitorizar varias veces al día los dumps que se generen en su sistema y
procurar su extinción para poder asegurar, en la medida de lo posible, el buen funcionamiento de los
programas dentro del sistema.
Hay que destacar que la gravedad de los ficheros de dump del sistema depende del papel que tome
el sistema R/3. En un sistema de desarrollo o test, será normal que hayan muchos ficheros de dump,
mientras que en un sistema productivo no podremos permitir que hayan errores en los programas.
Por tanto, el administrador del sistema deberá investigar y solucionar, junto con los programadores
y/o los usuarios afectados, todos aquellos errores que provoque la ejecución de un programa
ABAP/4.
Pág. 20
Estudio del rendimiento del sistema SAP R/3
3. MONITORIZACIÓN DEL SISTEMA OPERATIVO
SAP nos proporciona herramientas para monitorizar diversos aspectos del sistema operativo.
Esta información la podemos consultar en un momento especifico o podemos consultar históricos
que el sistema va almacenando para hacer análisis retrospectivos de la utilización de los recursos.
La labor del administrador del sistema es vigilar varias veces al día que todos los sistemas que
afectan a R/3 están usando correctamente los recursos de que disponen. Cuando haya algún
problema, el administrador deberá analizar la causa y buscar una solución lo antes posible para
restaurar el funcionamiento del sistema.
Para monitorizar el sistema operativo en el que reside SAP podemos acceder mediante la opción de
menú:
Transacción OS06
Pág. 21
Estudio del Rendimiento del sistema SAP R/3
3.1. Utilización de la CPU
Utilization user %: Indica que tanto por ciento de la CPU lo consumen procesos
de usuario de SAP.
Utilization system %: Indica el porcentaje del tiempo de CPU que se invierte para
ejecutar procesos del sistema operativo.
Utilization idle %: Indica el porcentaje de tiempo de CPU en el que esta está
parada.
Load Average : Indica el número medio de procesos que han estado esperando
para ser ejecutados por la CPU en el último minuto y en los
últimos cinco y quince minutos.
Una media de tres o más procesos esperando es indicativo de
un problema de rendimiento por falta de CPUs.
Para obtener más información acerca del uso de la CPU, accediendo a la opción Análisis Detallado
podemos extraer la siguiente información:
Pág. 22
Estudio del rendimiento del sistema SAP R/3
Una utilización intermitente del 100% de la CPU no es indicador de problemas siempre y cuando el
número de procesos a la espera de CPU no sea superior a tres.
Una causa muy frecuente de procesos de usuario con un elevado consumo de CPU son procesos que
han sido desconectados de forma inadecuada y que permanecen ejecutándose sin control en el
servidor. En general se aconseja hablar siempre con el usuario afectado para averiguar la causa del
problema.
En este apartado podemos ver la cantidad de memoria física de que dispone nuestro sistema
y que porcentaje de esta queda libre. Además obtenemos información sobre la paginación que sufre
el sistema.
Para obtener un buen funcionamiento, deberíamos tener al menos el 10 % de la memoria física total
libre aunque mientras tengamos al menos 2 Mbytes de memoria disponible el sistema funcionará sin
problemas.
En cuanto a la paginación, debemos tener en cuenta que el mismo concepto tiene un significado
distinto dependiendo de la plataforma en la que esté instalado el SAP R/3.
En caso de un plataforma Windows NT nos preocuparemos cuando la actividad de Pages in/s se vea
incrementada sustancialmente. Por el contrario, en plataformas UNIX nos preocuparemos cuando la
actividad de Pages out/s aumente considerablemente.
Como referencia, observaremos que el parámetro importante de paginación no supere el valor 200.
Podemos obtener información del uso de la memoria en las horas previas desde las opciones Detail
Info y Previous Hours Memory.
Al administrador de SAP, deberá monitorizar al menos una vez al día el estado de la memoria del
sistema. Si se llegase a observar algún problema con la memoria durante espacios de tiempo largos
entonces debería plantearse un aumento en la capacidad de memoria física del servidor o una
disminución del numero de procesos activos en el sistema.
3.3. SWAP
El espacio de SWAP es compartido por los procesos de SAP y cualquier otro proceso del
sistema operativo. Si se consume dicho espacio el sistema tendrá graves problemas de rendimiento.
Por tanto es importante vigilar con frecuencia el nivel de ocupación del SWAP. Como referencia,
miraremos que siempre queden libres al menos 400.000 Kbytes de espacio de SWAP. Si aparecieran
problemas, se debería aumentar el espacio de SWAP a nivel de sistema operativo.
Pág. 23
Estudio del Rendimiento del sistema SAP R/3
Aquí podemos ver información detallada sobre el disco duro que tiene un tiempo de
respuesta más alto.
Esta información nos sirve para determinar que disco es el que está más ocupado. No nos
preocuparemos por este apartado mientras el tiempo de respuesta del disco más ocupado no sea
mayor de 500ms.
En caso de que esto suceda, se deberá estudiar la posibilidad de adquirir un disco más rápido o
fraccionar el contenido del disco en varios discos para así distribuir la carga en varios discos.
Podemos obtener información desde las opciones Detail Info y Previous Hours Memory.
3.5. Red
Los problemas de red los detectaremos cuando la actividad de esta se vea incrementada
sustancialmente. Al existir un trafico muy intenso en la red, el valor de Packets in/s y de Packets
out/s aumenta. Esto hace que el número de colisiones y la probabilidad de que aparezcan errores de
comunicación aumente.
El administrador del sistema deberá monitorizar regularmente el estado de la red para asegurarse de
que esta no está saturada. Consideraremos que la red estará saturada cuando el número de colisiones
sea muy elevado (1000) y el número de errores tanto de entrada como de salida crezca por encima
de 500.
Además, para poder comprobar la comunicación entre el servidor y los clientes, podemos acceder al
siguiente menú:
Con esta opción podremos hacer in ping entre el servidor y los clientes y así comprobar el estado de
la conexión.
El programa saposcol proporciona los datos recogidos a SAP a través de las zonas de memoria
compartida. El proceso de fondo SAP_COLLECTOR_FOR_PERFMONITOR que se ejecuta cada
hora se encarga de leer los datos de las zonas de memoria y almacenarlos en la base de datos.
SAP proporciona una interficie para gestionar este programa a la que se accede mediante el menú:
Transacción OS06
Desde esta pantalla se puede arrancar o parar el programa saposcol. Se puede ver información sobre
como se ejecuta el programa, el fichero de log, etc.
El administrador de SAP deberá verificar al menos una vez al día que el programa se está
ejecutando correctamente.
Pág. 25
Estudio del Rendimiento del sistema SAP R/3
SAP presenta una interficie para monitorizar cada una de las instancias. Muestra información
sobre los buffers del sistema, el SAP Cursor Cache, estadísticas de acceso a tablas y el uso que los
procesos de trabajo hacen de las diferentes zonas de memoria: área de roll, área de paginación,
memoria extendida y memoria privada, también conocida como memoria heap.
El administrador del sistema deberá comprobar varias veces al día en cada una de las instancias si
se está haciendo un uso correcto de la memoria revisando los datos que presenta esta interficie.
Estos buffers contienen las definiciones de las tablas y campos activos del diccionario
ABAP/4. Cuando se activa una tabla o un campo en el sistema R/3 se añade una entrada en dichos
buffers.
La descripción de una tabla en el repositorio de R/3 se distribuye en dos tablas de la base de datos:
Los buffers IREC y SNTAB no están asociados a ninguna tabla de la base de datos. Su contenido se
deriva del contenido de las tablas DDNTT y DDNTF. Cuando se hace un acceso a una tabla,
primero se lee el buffer SNTAB para obtener información sobre la tabla, si esto no fuera suficiente
entonces se accede a los buffers TTAB y FTAB.
Este buffer contiene las versiones ejecutables de los programas ABAP/4. Cuando se genera
un programa, si este ya está en el buffer se invalida y se carga de nuevo desde la base de datos. Esto
causa fragmentación y formación de gaps en el buffer.
Existen dos buffers para manejar la interficie con el SAPGUI. Estos contienen elementos
gráficos tales como pantallas, menús, iconos, etc.
Pág. 26
Estudio del rendimiento del sistema SAP R/3
Este buffer contiene el calendario anual. Está asociado a dos tablas, la tabla TFACS que
marca el calendario de la empresa y la tabla THOCS que marca los días festivos.
Contienen entradas de las tablas. Dependiendo de que tipo de buffering de cada tabla sea
completo, genérico o individual, contendrán todos los registros de una tabla, un rango de registros o
registros individuales. Existen dos tipos de buffers de tablas:
Existen cuatro factores importantes que afectan al rendimiento de los buffers de SAP. Estos
factores deberían estar controlados en la medida de lo posible.
- Paradas de SAP : Las paradas de SAP implican el borrado de los buffers en memoria.
Esto hace que toda la información que los buffers contienen se pierda.
Pág. 27
Estudio del Rendimiento del sistema SAP R/3
En los buffers, una parte del espacio se dedica a la administración del buffer y otra a
almacenar datos. Así, el espacio total reservado es mayor que el espacio disponible para almacenar
datos. Hay que parametrizar el número de entradas de directorio del buffer y el espacio disponible
para almacenar la información propiamente dicha.
Buffer Parámetros
Table Definition Entradas de directorio : rsdb/ntab/entrycount
Tamaño para datos : 100bytes x rsdb/ntab/entrycount
Field Description Entradas de directorio : 2 x rsdb/ntab/entrycount
Tamaño de datos : rsdb/ntab/ftabsize
Short Nametab Entradas de directorio : 2 x rsdb/ntab/entrycount
Tamaño de datos : rsdb/ntab/sntabsize
Initial Record Entradas de directorio : 2 x rsdb/ntab/entrycount
Tamaño de datos : rsdb/ntab/irdbsize
Program Buffer Entradas de directorio : Se calcula a partir de abap/buffersize
Tamaño de datos (KB): abap/buffersize
Screen Buffer Entradas de directorio : zcsa/bufdir_entries
Tamaño de datos (KB): zcsa/presentation_buffer_area
CUA Buffer Entradas de directorio : rsdb/cua/buffersize / 2Kb
Tamaño de datos (KB): rsdb/cua/buffersize
Generic Key Buffer Entradas de directorio : zcsa/db_max_bufsize
Tamaño para datos : zcsa/table_buffer_area
Single Key Buffer Entradas de directorio : rtbb/max_tables
Tamaño de datos (KB): rtbb/buffer_length
Una vez aclarado el contenido de cada uno de los buffers que contiene R/3, veremos como
interpretar la información que nos da el sistema.
Accedemos mediante el menú:
Transacción ST02
Pág. 28
Estudio del rendimiento del sistema SAP R/3
- Allocated Size : Es el tamaño en Kbytes que ocupa el buffer. Es un poco mayor que el
tamaño disponible ya que parte de dicho espacio se usa para gestionar el propio buffer.
- Dir Size Entries : Contiene el número de entradas de directorio que puede haber en el
buffer. Puede ocurrir que el buffer tenga suficiente espacio libre y que los objetos no
puedan ser cargados debido a que no hayan entradas libres en el buffer.
- Swaps : indica el número de objetos que han sido sacados del buffer para liberar el
espacio necesario para meter otro objeto. El swapping ocurre cuando el buffer no tiene
suficiente espacio libre o suficiente número de entradas libres.
Cuando la instancia de SAP se arranca, todos los buffers excepto el Program Buffer están vacíos. La
primera vez que se accede a los objetos, estos se leen de la base de datos y se cargan después en el
buffer.
Pág. 29
Estudio del Rendimiento del sistema SAP R/3
El incremento en la calidad de los buffers depende del tipo de buffer y de la carga de trabajo de la
instancia. Después de un tiempo significativo de actividad, los buffers se estabilizan. Hasta entonces
no tiene mucho sentido estudiar la calidad de los buffers.
Un mal rendimiento en nuestro sistema puede ser debido a que los buffers sean pequeños o que sean
demasiado grandes en cuyo caso se estaría desperdiciando la memoria. Deben ajustarse a un tamaño
óptimo.
Se puede obtener información más detallada de cada buffer seleccionando el buffer desde la opción
Detail Analysis Menú.
Seguidamente, podemos ver una serie de valores óptimos de los buffers para obtener un buen
rendimiento del sistema.
El swapping a nivel de buffer puede ocasionarse por dos razones: por tamaño insuficiente del buffer
o por falta de entradas libres en el buffer.
En el primer caso deberemos aumentar el tamaño del buffer. En el segundo caso, aunque haya
espacio suficiente en el buffer no se pueden cargar más objetos porque se ha llegado al límite de las
entradas, por lo que habrá que aumentar el número de entradas de directorio.
Deberemos tener en cuenta que siempre que aumentemos el tamaño de un buffer, deberemos
aumentar en la misma proporción las entradas de directorio asociadas.
Si no es posible ajustar los buffers al tamaño deseado por falta de memoria física, es importante
conocer cuales son los buffers mas importantes y que prioridad debe seguirse a la hora de ajustarlos.
El orden de prioridades es el siguiente:
Pág. 30
Estudio del rendimiento del sistema SAP R/3
4.2. Memoria de SAP
4.2.1. Conceptos
- Contexto de usuario : Entendemos por contexto de usuario, los datos que tiene que guardar el
sistema para poder continuar procesando una transacción después de interrumpirla.
- Roll Area : Se usa para almacenar el contexto de usuario cuando un proceso de trabajo deja de
atender a un proceso de usuario (Roll out del proceso de usuario). El área de roll está dividida en
dos partes: la primera se usa para almacenar la parte inicial del contexto de usuario y la segunda
cuando la memoria extendida se agota.
- Paging Area : Contiene datos de la aplicación, como pueden ser tablas internas y listados.
- Buffers Roll y de Paginación : Son los buffers de trabajo de las áreas de roll y paginación. El
resto del área de roll y paginación están en disco. Cada vez que se ejecuta un paso de diálogo
tiene lugar una acción de roll entre el área de roll_first y el buffer de roll en memoria compartida
perteneciente a dicho proceso de trabajo. Estos buffers se dimensionan en el perfil de instancia
mediante los parámetros rdisp/PG_SHM y rdisp/ROLL_SHM
- Memoria Heap o Memoria Privada : Cuando el contexto de usuario requiere más memoria que
la proporcionada por el área de roll y la memoria extendida, el proceso de trabajo reserva un área
de memoria local y privada para él, conocida como Heap Memory y que no puede ser usada por
otros procesos de trabajo. A partir de este momento el proceso de trabajo no hará cambio de
contexto hasta que acabe la tarea que esté ejecutando.
Un proceso de diálogo se ejecuta en modo PRIV desde el momento en que empieza a usar la
memoria privada. No es deseable que los procesos entren en este modo. Si hubieran demasiados
procesos de diálogo en este modo podríamos tener problemas de rendimiento en nuestro sistema.
Podemos limitar el número de procesos que se ejecutan en modo PRIV concurrentemente mediante
el parámetro rdisp/wppriv_max_no.
Pág. 31
Estudio del Rendimiento del sistema SAP R/3
4.2.2. Uso de la memoria de los procesos de trabajo
El sistema de gestión de memoria reserva espacio para el contexto de usuario en tres áreas
diferentes: Área de Roll, memoria extendida y memoria Heap.
Los procesos de trabajo de diálogo gestionan estas tres áreas de la memoria de forma diferente el
resto de los procesos de trabajo.
- Se alcanza el límite de memoria extendida que el proceso puede usar, establecido por el
parámetro ztta/roll_extension.
- Se acaba el área de memoria extendida establecida para el total de los procesos y cuyo
valor se determina con el parámetro em/initial_size_MB.
3. Si todavía necesita más memoria, ésta la reserva del área de roll hasta que se llena. La
cantidad de memoria de roll que puede usar viene determinada por la diferencia entre el total
del área de roll para ese proceso y el área dedicada a los datos iniciales.
4. Si hiciera falta más memoria, ésta se consume del área de memoria privada. El proceso
puede seguir consumiendo esta memoria hasta que se llega a un o de los siguientes límites:
- Se llega el límite de memoria privada que ese proceso puede consumir y que está
establecido por el parámetro abap/heap_area_día.
- Se llega al límite de memoria privada para todos los procesos de trabajo y que está
establecido por el parámetro abap/heap_area_total.
- Se llega a un límite marcado por el sistema operativo.
1. Se usa el total de la memoria de roll que puede consumir un proceso de trabajo y que viene
definido por el parámetro ztta/roll_area.
2. Si se llena el área de roll, entonces se usa la memoria privada hasta que se da una de las
siguientes circunstancias:
Pág. 32
Estudio del rendimiento del sistema SAP R/3
4.2.3. Monitorización de la Memoria de SAP
Transacción ST02
En esta pantalla podemos ver el uso que se está haciendo de las diferentes zonas de memoria, su uso
actual, máximo y que cantidad de dicha memoria está en memoria principal y cuanta está en disco.
Desde Detail Analysis Menú Sap memory se obtienen más detalles sobre estos umbrales.
- Quotas : Muestra las cuotas disponibles de cada tipo de memoria para los procesos de
diálogo y para el resto de los procesos de trabajo.
- Extended Memory y Mode List : Muestra que uso hacen los usuarios de la memoria
extendida y la memoria heap.
- History : Muestra la historia del uso de la memoria extendida y memoria heap en los
días anteriores.
- Current Param : valores actuales de los parámetros que gestionan la memoria de SAP.
Seguidamente podemos ver una serie de valores indicativos de una buena gestión de la memoria.
Hay que vigilar que no se llenen las diferentes áreas de memoria.
La SAP Cursor Cache mejora el rendimiento del sistema reduciendo el número de veces que
se tiene que hacer el parsing para una sentencia SQL.
Existen dos tipos de Cursor Cache: Statement ID Cache y Statement Cache.
Pág. 33
Estudio del Rendimiento del sistema SAP R/3
Transacción ST02
Seguidamente vemos una serie de valores que indican un buen funcionamiento del sistema.
En esta sección se presentan estadísticas de acceso a los datos, que pueden residir en los
buffers de SAP o en la base de datos. Para cada tipo de acceso a las tablas (select single, select,
update, insert, delete) muestra el porcentaje de aciertos o Hitratio, el número de llamadas ABAP/4,
cuantas de estas llamadas se resuelven en los buffers y cuantas se resuelven con llamadas a la base
de datos.
Transacción ST02
Para obtener un buen funcionamiento del sistema, el Hitratio de los distintos tipos de operaciones
debería ser superior al 90%. En caso de no ser así, debería estudiarse la posibilidad de bufferizar
más tablas y/o modificar el tipo de bufferizado de las tablas ya existentes.
Pág. 34
Estudio del rendimiento del sistema SAP R/3
5. MONITORIZACIÓN DE LA BASE DE DATOS
SAP presenta su propia interficie para monitorizar la base de datos. La mayor parte de la
información se extrae de tablas de monitorización propias de Oracle.
El análisis se puede realizar indistintamente desde cualquier servidor de aplicación.
El administrador del sistema debe analizar estos datos diariamente realizando fundamentalmente las
siguientes tareas:
- Chequear el crecimiento de la base de datos y vigilar el tamaño de los tablespaces.
- Comprobar que no existen objetos críticos.
- Verificar que existen todos los índices, tanto en la base de datos como en el diccionario
de datos.
- Analizar los indicadores de rendimiento.
- Hacer estimaciones sobre la evolución del tamaño de la base de datos y dimensionar las
necesidades de almacenamiento de la información.
Transacción ST04.
Pág. 35
Estudio del Rendimiento del sistema SAP R/3
5.1. Data Buffer
La base de datos Oracle posee un buffer de datos donde mantiene una copia de los bloques
de datos más leídos del disco. Este buffer de datos actúa como una memoria cache de la base de
datos. Cada vez que un proceso de la base de datos necesita leer un dato primero accede a este
buffer. Si la información buscada no se encuentra en el buffer, el proceso deberá acceder a los
fichero de datos.
La calidad del buffer define la relación entre el número de veces que se encuentra la información y
el número total de búsquedas. Cuanto mayor sea la calidad del buffer mayor será la velocidad de
acceso a los datos y por consiguiente, mejor será el rendimiento del sistema.
Para poder asegurar un buen funcionamiento del buffer de datos deberemos tener un porcentaje de
aciertos superior al 95% y un número de esperas (Busy waits) inferior al 5% del número total de
lecturas del buffer.
La Shared Pool es una área de memoria compartida en la System Global Area en la que
Oracle guarda las siguientes estructuras de memoria:
Para obtener un buen funcionamiento los valores de los parámetros DD-Cache quality, SQL Área
getratio y SQL Área pinratio deberían se superiores al 90%.
Solo tiene sentido verificar estos valores cuando la base de datos ha llegado a un nivel de actividad
estable.
Pág. 36
Estudio del rendimiento del sistema SAP R/3
5.3. Redo Log Buffer
El Redo Log Buffer contiene información acerca de los cambios hechos a los datos y a los
objetos en la base de datos. Cada cambio genera una entrada en el buffer.
- Allocation retries : Indica el número de veces que Oracle intenta reservar espacio en el
Redo Log Buffer y no puede. Si ocurre esto, el proceso de usuario tiene que esperar
hasta que haya espacio disponible en el buffer.
- Alloc fault rate : Muestra la relación existente entre los fallos al reservar espacio en el
buffer y el número de entradas generadas en el mismo.
Deberemos asegurarnos periódicamente que el parámetro Alloc fault rate no supera el 1%. En caso
de que esto sucediera tendremos que aumentar el tamaño del buffer.
5.4. Calls
Esta sección muestra el número de accesos a la base de datos que hace el kernel de Oracle
desde que se arrancó la instancia.
- User Calls : Son las llamadas realizadas por los procesos de usuario desde que se
arrancó la base de datos.
- Commits : Número de transacciones en las que se ha hecho commit desde que arrancó la
base de datos.
- Rollbacks : Número de transacciones en las que se ha hecho rollback desde que arrancó
la base de datos.
- Recursive Calls : Son llamadas generadas por el mismo Oracle para resolver sus
operaciones internas.
- Parses : Número de veces que se ha hecho parsing de una sentencia SQL.
Deberemos vigilar que el numero de Rollbacks no sea muy alto. En caso de que esto suceda,
deberemos buscar las causas analizando el fichero de log, los ficheros de trace de los procesos de
trabajo y los ficheros de dump.
También deberemos mirar que la relación User/Recursive Calls sea superior al 5%. Idealmente,
buscaremos que este parámetro sea mayor que 10%.
La relación Parser/User Calls deberá ser inferior al 25%.
El número de llamadas recursivas puede ser muy alto debido a que el Data Dictionary Cache es
muy pequeño o que existen muchos extents en los objetos de la base de datos.
Pág. 37
Estudio del Rendimiento del sistema SAP R/3
En un sistema en el que se para la base de datos todos los días no es posible mantener el ratio
anterior en los valores adecuados. Si se hace el análisis del ratio hora a hora, se observa que el
principio es muy bajo y que se va acercando al valor adecuado según va subiendo el nivel de
actividad en la base de datos.
En esta sección podemos ver como se hacen los accesos a los datos.
La sección de Table Scans muestra información sobre tablas con acceso secuencial y la sección
Table Fetch muestra información sobre tablas accedidas mediante índices.
- Short Tables : Indica el número total de accesos secuenciales que se han hecho sobre
tablas cortas. Se entiende por tablas cortas aquellas cuyo tamaño no supera cinco bloques
de Oracle.
- Long Tables : Indica el número de accesos secuenciales sobre tablas largas (más de cinco
bloques).
- Rows Gotten : Número total de registros accedidos durante los accesos secuenciales a las
tablas.
- Blocks Gotten : Número de bloques de Oracle leídos durante los accesos secuenciales a
las tablas.
- Table Fetch by Rowid : Número de registros accedidos usando índices.
- Continued Row : Indica el número de registros cuyos datos se encuentran en más de un
bloque. Se conocen como Chained Data Records.
El administrador deberá comprobar que el número de accesos secuenciales sobre las tablas largas
sea pequeño. En caso de que no sea así, se deberán crear o regenerar los índices para las tablas
largas que se vean afectadas.
Un ratio elevado entre Blocks Gotten y Rows Gotten indica que existe mucho espacio vacío en la
tabla a la que accede, probablemente debido a operaciones de borrado. En este caso se aconseja
reorganizar.
Un número alto de accesos con índices es síntoma de un buen funcionamiento del sistema.
5.6. Sorts
En esta sección podemos ver el número de ordenaciones que se han efectuado en el sistema en los
niveles de memoria, disco y fila.
Deberemos vigilar que el parámetro Disk no sea superior al 5% del valor del parámetro Memory.
En caso de que no sea así deberemos aumentar el parámetro de Oracle sort_area_size en el
fichero init<SID>.ora.
Pág. 38