Basis Manual Rendimientos

ESTUDIO DEL
RENDIMIENTO DEL
SISTEMA SAP R/3
Ricardo Casanovas Ortego

Ana María Fernández Mañas
Estudio del Rendimiento del sistema SAP R/3
ÍNDICE
1. OBJETIVO 4
2. OPERATIVIDAD DEL SISTEMA 5
2.1. Monitorización de las instancias 5
2.1.1. Instancias arrancadas 5

2.1.2. Monitorización de los procesos de trabajo 6
2.1.3. Chequeo del fichero de log de la instancia 8
2.1.4. Usuarios 9
2.2. Monitorización del sistema de actualizaciones 10

2.3. Monitorización del sistema de bloqueos 13
2.4. Revisión de los procesos de fondo 15
2.5. Gestión de Batch Inputs 16
2.6. Verificación de los ficheros de Dump de ABAP/4 18
3. MONITORIZACIÓN DEL SISTEMA OPERATIVO 21
3.1. Utilización de la CPU 22

3.2. Utilización de la memoria 23
3.3. SWAP 23
3.4. Disco con mayor tiempo de respuesta 24
3.5. Red 24
3.6. Colector de estadísticas 25
4. MONITORIZACIÓN DE LA MEMORIA DE SAP 26
4.1. Buffers de SAP 26
4.1.1. R/3 Repository Buffers (Nametab buffers) 26

4.1.2. Buffer de programas 26
4.1.3. Buffers SAPGUI 26
4.1.4. Buffer de calendario 27
4.1.5. Buffers de Tablas 27
4.1.6. Factores que afectan la calidad de los buffers 27
4.1.7. Parámetros para manejar el tamaño de los buffers 28
4.1.8. Monitorización de los buffers 28
4.2. Memoria de SAP 31
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
4.3.1. Monitorización de la SAP Cursor Cache 34
4.4. Call Statistics 34
4.4.1. Monitorización de las estadísticas 34
5. MONITORIZACIÓN DE LA BASE DE DATOS 35
5.1. Data Buffer 36

5.2. Shared Pool 36
5.3. Redo Log Buffer 37
5.4. Calls 37
5.5. Table Scans / Table Fetch 38
5.6. Sorts 38
Pág.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
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.
2.1. Monitorización de las instancias
Hay que verificar que las diferentes instancias del sistema SAP R/3 están operativas siguiendo
los siguientes pasos:
- Verificar que todas las instancias están arrancadas.

- Revisar el fichero de log para cada una de las instancias.
- Chequear los usuarios.
- Monitorizar los procesos de trabajo de cada instancia.
Estos procesos se deben realizar varias veces al día usando las herramientas que proporciona el
CCMS (Computing Center Managment System) de SAP.
2.1.1. Instancias arrancadas
Herramientas  Gestión  Monitor  Supervisar Sistema  Servidor
Transacción SM51
Pág. 5
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.
2.1.2. Monitorización de los procesos de trabajo
Herramientas  Gestión  Monitor  Supervisar Sistema  Resumen procesos
Transacción SM50
Desde el punto de vista de análisis de rendimiento y seguimiento de problemas, interesan los

siguientes campos:
- Status: Muestra el estado actual del proceso de trabajo. Los posibles estados son los
siguientes:
· Procesa: El proceso está ejecutando algún programa.

· Espera: El proceso está ocioso esperando para atender alguna petición del
sistema.
· Esperando: El proceso está parado por el motivo indicado en el campo Razón.
· Finalizado: El proceso ha sido cancelado con la opción de Reanudar tras error a
no.
Pág. 6
- 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.
- Report: Es el programa que está ejecutándose, Nos fijaremos si cambia de programa o

no.
- Actividad: Tipo de operación que está realizando: lectura secuencial, lectura directa,
carga de programas, commit, rollback, etc.
- Tabla: Estructura a la que está accediendo.
- 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.
Como acceder: Seleccionar el proceso de trabajo y desde el menú:
Proceso  Trace  Visualizar Fichero
Herramientas  Gestión  Monitor  Traces  Traces Desarrollo
Estos ficheros se encuentran en el directorio local de cada instancia:
/usr/sap/FLP/DVEBMGS01/work/dev_w*
/usr/sap/FLP/DVEBMGS01/work/dev_disp
/usr/sap/FLP/DVEBMGS01/work/stderr
- Borrar modo: Permite cancelar el proceso de trabajo seleccionado.
Proceso  Cancelar con core

Proceso  Cancelar sin core
Podemos escoger entre estas dos opciones dependiendo de sí queremos un fichero de

dump o no. Lo aconsejable es hacerlo sin fichero de dump.
Que hay que vigilar en los procesos de trabajo:
- 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
- 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.
2.1.3. Chequeo del fichero de log de la instancia
Herramientas  Gestión  Monitor  Supervisar Sistemas  Servidor - Log Sistema
Transacción SM21
Pág. 8
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
Herramientas  Gestión  Monitor  Supervisar Sistemas  Servidor – Usuario
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
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.
Si un registro de actualización se procesa correctamente desaparece de la cola, pero si acaba con

error permanece aquí indicando que la modificación no se ha hecho y que habré que volver a
procesarla.
El Administrador de SAP debe monitorizar sistemáticamente el sistema de actualizaciones

realizando las siguientes funciones:
- 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.
- Analizar los registros de actualización cuyo proceso ha tenido errores.
- 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.
Herramientas  Gestión  Monitor  Actualización
Transacción SM13
Pág. 10
Como norma pondremos los siguientes criterios de selección:
· Mandante: Mandante que interese

· Usuario: *
· Status: Todo
· Fecha: Fecha desde la que se hizo la ultima monitorización
Debemos analizar los siguientes puntos:
1. El sistema de actualizaciones está activo:
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
2. Registros en estado Init esperando a ser procesados
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.
3. Registros en estado Err
Pág. 11
Si tuviéramos registros de actualización en este estado, deberíamos analizarlo detalladamente
basándonos en la siguiente información:
- Información del fichero de log de la instancia.

- Información detallada que ofrece la transacción SM13.
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í:
- Status Actualización: Muestra en que modulo de función se produjo el error, el

programa, la línea, el texto del error y si se ha generado un Dump también podemos
acceder a él.
- Cabecera Actualización: Muestra el usuario que hizo la modificación, sobre que
mandante, que transacción y que programa, clave del bloqueo generado y el servidor
sobre el que se ha ejecutado la modificación.
- Visualizar Datos: Muestra los datos de actualización. El nombre de la estructura y los
valores introducidos por el usuario.
Esta transacción permite volver a procesar directamente las modificaciones que han fallado
marcando el componente y seleccionando la opción:
Updated Records  Repeat Update
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.
Los datos de actualización se pueden ver desde las opciones:
Update Modules y Display Data
Esta información puede ser de gran ayuda si el usuario no recuerda los datos que introdujo en el
sistema.
Pág. 12
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:
- Error de SAPGUI: Si un usuario apaga su PC sin terminar correctamente su sesión de

SAP o si hay algún problema en la red de datos puede ocurrir que el proceso de trabajo
que ocupaba el usuario antes de perder la comunicación siga vivo en el servidor. Si esto
ocurre, puede darse el caso de que los bloqueos que tenía el usuario no se liberen
automáticamente.
- 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.
- Problemas en el proceso de actualización: Los procesos de actualización sólo liberan los

bloqueos cuando sus registros de actualización han sido completamente procesados o
cuando han acabado con error. Sólo los módulos de actualización con estado Init o Auto
pueden mantener bloqueos.
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.
Para poder gestionar los bloqueos desde SAP R/3 accederemos a
Herramientas  Gestión  Monitor  Entradas bloqueo
Transacción SM12.
Pág. 13
Una vez determinados los criterios de selección obtenemos lo siguiente:
· 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
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.
Accediendo por el menú:
Herramientas  CCMS  Jobs  Mantenimiento
Transacción SM37.
En esta transacción podremos realizar un seguimiento de los Jobs definidos en el sistema.

Entraremos los criterios selección que deseemos:
- Job : Nombre del Job del que queremos obtener información.

- Usuario : Nombre del usuario dueño del Job.
- Fecha inicio : Franja horaria que deseamos verificar o evento que espera el Job para
ejecutarse.
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
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.
El administrador deberá prestar especial atención a los Jobs de sistema siguientes:
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.
2.5. Gestión de Batch Inputs
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:
Generación del juego de datos.

Proceso del juego de datos.
El administrador de SAP puede realizar todas o algunas de estas tareas:
- Procesar batch inputs

- Depurar las sesiones de batch inputs
- Revisar los logs diariamente e informar a los usuarios de los errores.
- Bloquear y desbloquear las sesiones de batch input.
- Limpiar las sesiones y los ficheros de log.
Mediante el menú
Herramientas  Gestión  Monitor  Batch Input
Transacción SM35.
Pág. 16
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
Por pantalla podemos ver los siguientes datos:
- Juego de datos: Nombre de la sesión.

- Fecha y hora: Fecha y hora de la generación de la sesión de batch input.
- Bloqueado: Indica la fecha hasta la que está bloqueada la sesión.
- Autor: Usuario que generó la sesión.
- Trans.: Número de transacciones que procesará la sesión.
- Dynpro: Número de pantallas que serán procesadas en la sesión.
- Autorización: Si la sesión se ejecuta en fondo, lo hace como el usuario que esta
opción indique.
Además, esta transacción nos permite:
- Analizar el juego de datos: Muestra la transacción, el estado de la misma, el número de

pantalla y los datos asociados a la misma.
- Analizar estadísticas: Muestra cuantas transacciones han sido procesadas
correctamente, cuantas con error y cuantas están pendientes de procesar.
- Analizar los ficheros de log: Muestra el fichero de log de la ejecución.
Diariamente, el administrador del sistema deberá realizar las siguientes labores:
- 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
2.6. Verificación de los ficheros de Dump de ABAP/4
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ú:
Herramientas  Gestión  Monitor  Análisis Dump
Transacción ST22.
Obtenemos una pantalla con el número de dumps generados ayer y hoy.
Pág. 18
Deberemos seleccionar la opción que más nos convenga.
Pág. 19
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.
A partir de aquí procedemos a seleccionar el dump que queramos investigar seleccionándolo.
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
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ú:
Herramientas  Gestión  Monitor Rendimiento  Operating System  Local  Activity
Transacción OS06
Seguidamente, analizaremos cada una de las secciones que aparecen en la pantalla.
Pág. 21
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:
CPU Snapshot : Muestra los porcentajes de utilización de cada una de las

CPUs del sistema en el momento actual.
Top CPU Processes : Muestra los procesos que se están ejecutando en el sistema
ordenados por consumo de CPU.
CPU Previous Hours : Muestra los porcentajes de utilización de las CPU en las
diferentes horas del día.
Compare Recent Days : Muestra los porcentajes medios de utilización de la CPU de
los últimos 30 días para los diferentes servidores. Con los
botones Next Server o Previous Server nos movemos de un
servidor a otro. Seleccionando uno de los días nos aparecen
los porcentajes medios de ocupación de todos los servidores
en ese día.
Valores Adecuados Para Un Buen Funcionamiento

Utilization User % : Este valor debe ir oscilando. Si permaneciera
constantemente con un valor superior al 80% debemos
identificar que proceso de usuario es el causante.
Top CPU Processes desde Detail Analysis Menu muestra los
procesos ordenados por consumo de CPU.
Utilization System % : Este valor debe ir oscilando. Si permaneciera
constantemente con un valor superior al 80% debemos
identificar que proceso de sistema es el causante.
Top CPU Processes desde Detail Analysis Menu muestra los
procesos ordenados por consumo de CPU.
Load average 1 min. : Este valor debe ser menor o igual a 3.
Pág. 22
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.
3.2. Utilización de la memoria
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.
3.4. Disco con mayor tiempo de respuesta
Pág. 23
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
El buen funcionamiento de la red en la que se encuentra instalado el SAP es muy importante

a la hora de conseguir un buen funcionamiento del sistema.
Si las comunicaciones entre servidor y cliente fueran malas sufriríamos unos tiempos de respuesta
muy elevados mientras que observaríamos que nuestro servidor procesa rápidamente todas aquellas
peticiones que le llegan.
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.
Si existieran problemas de red, debería estudiarse la posibilidad de mejorarla, sea aumentando la

velocidad de transferencia o mejorando la calidad de las comunicaciones en el caso de haber
muchos errores de transmisión.
Además, para poder comprobar la comunicación entre el servidor y los clientes, podemos acceder al
siguiente menú:
Herramientas Gestión  Monitor  Rendimiento  Operating System  Local  Activity

Detail Analysis Menú – Lan Check by Ping
Con esta opción podremos hacer in ping entre el servidor y los clientes y así comprobar el estado de
la conexión.
3.6. Colector de estadísticas

Pág. 24
El colector de estadísticas o saposcol es un programa proporcionado por SAP que se ejecuta

a nivel de sistema operativo. Su función es recoger constantemente información de los recursos del
sistema operativo tales como CPU, memoria, SWAP, discos, red, etc.
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ú:
Herramientas  Gestión  Monitor  Rendimiento  Operating System  Local  Activity 

OS Collector
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.
4. MONITORIZACIÓN DE LA MEMORIA DE SAP
Pág. 25
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.
4.1. Buffers de SAP
4.1.1. R/3 Repository Buffers (Nametab buffers)
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:
- Tabla DDNTT, que contiene definiciones de tablas.

- Tabla DDNTF, que contiene definiciones de los registros.
El R/3 Repository está formado por los siguientes buffers:
TTAB Table definition Contiene definiciones de tablas. Está asociado a la

tabla DDNTT
FTAB Field Description Contiene la descripción de los campos. Está asociado
a la tabla DDNTF.
IREC Initial Record Layout Contiene la descripción del registro.
SNTAB Short Nametab Contiene un breve resumen de los buffers TTAB y
FTAB.
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.
4.1.2. Buffer de programas
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.
4.1.3. Buffers SAPGUI
Existen dos buffers para manejar la interficie con el SAPGUI. Estos contienen elementos
gráficos tales como pantallas, menús, iconos, etc.
Screen Buffer o Presentation Buffer Contiene pantallas generadas o DYNPROS.

CUA Buffer o Menú Buffer Contiene definiciones de objetos del SAPGUI.
4.1.4. Buffer de calendario
Pág. 26
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.
4.1.5. Buffers de Tablas
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:
Single Record Contiene registros individuales de las tablas.

Generic Key Contiene rangos de registros de una tabla o la tabla entera.
4.1.6. Factores que afectan la calidad de los buffers
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.
- Transportes : Cuando se realiza un transporte, todas las entradas del buffer de

programas se invalidan y se limpia el resto de los buffers (equivalente a $SYNC). El
comportamiento del buffer de programas difiere del resto. Mientras que los otros buffers
se inicializan y se comportan como buffers vacíos, el buffer de programa para cargar de
nuevo un programa tiene que buscar un área que tuviera previamente un programa del
mismo tamaño. Esto incrementará más la fragmentación. Es importante evitar en la
medida de lo posible el paso de transportes a un sistema productivo en horas de gran
actividad del sistema.
- Desarrollos : En un entorno de desarrollo se generan y se cambian programas con

mucha frecuencia, que serán invalidados en el buffer y recargados una y otra vez. Dado
que normalmente la nueva versión del programa no cabrá en el mismo espacio que la
vieja versión, se aumentará el nivel de fragmentación.
- Reset de Buffers : Pueden darse circunstancias que provoquen inconsistencias entre el

contenido de la base de datos y el de los buffers. Para resolver esta situación es necesario
inicializar los buffers. El comando $TAB se usa para inicializar los buffers de las tablas,
el comando $SYNC sirve para inicializar todos los buffers de SAP. Estos comandos sólo
afectan a los buffers del servidor de aplicación donde se ejecutan. La inicialización de
los buffers provoca una perdida muy importante de rendimiento hasta que los buffers
vuelvan a alcanzar los niveles de calidad óptimos.
- 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.
4.1.7. Parámetros para manejar el tamaño de los buffers
Pág. 27
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
4.1.8. Monitorización de los buffers
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ú:
Herramientas  Gestión  Monitor  Rendimiento  Setup/Buffers  Buffers
Transacción ST02
Pág. 28
- Hitratio : indica el porcentaje de veces que se ha encontrado la información en el buffer.

Si la información se encuentra en el buffer nos evitamos tener que hacer accesos a la
base de datos.
- 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.
- Free Space : Espacio disponible del 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.
- Free Directory Entries : Muestra el número y porcentaje de 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.
- Database Access : Indica el número de veces que se ha accedido a la base de datos

debido a que el objeto buscado no se ha encontrado en el buffer.
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
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.
Calidad de los Buffers > 95%

Swaps =0
Free Space > 25 %
Free Directory Entries > 25%
Program Buffer Gaps Hay que vigilar que el espacio libre del buffer no sea igual o
próximo al tamaño de los gaps. Puede darse el caso de que a
pesar de haber suficiente espacio libre, este esté formado por
gaps de tamaño insuficiente para cargar el nuevo programa.
Para acceder a estos detalles : Detailed Analysis Menú 
Program Buffer
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:
1. R/3 Repository Buffers

2. Table Buffers
3. Program Buffers
4. Roll File Buffer
5. Page File Buffer
6. GUI Buffers
Pág. 30
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 Extendida : Todos los contextos de usuario se encuentran en memoria principal y

pueden ser accedidos por todos los procesos de trabajo. Cuando hay un cambio de contexto, los
datos del contexto residentes en memoria extendida, no se copian a otro sitio (en contraste con
los datos del área de roll), sino que se asignan a otro proceso de trabajo a través de operaciones
de mapeo y reasignación de punteros. Dado que el cambio de contexto se realiza muy
frecuentemente, el uso de memoria extendida supone una gran mejora en el rendimiento del
sistema.
- 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
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.
1. Gestión de memoria de los procesos de diálogo:
1. Usa el área de roll determinada por el parámetro ztta/roll_first. Aquí guarda la

información inicial del contexto de usuario.
2. Si el contexto de usuario necesita más memoria, la reserva de la memoria extendida.
Consume memoria extendida hasta que se da una de las situaciones siguientes:
- 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.
2. Gestión de la memoria para el resto de los procesos de trabajo:
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:
- El proceso alcanza el límite de memoria privada que puede consumir

(abap/heap_area_nondia).
- Se alcanza el límite total de memoria privada para todos los procesos de trabajo
(abap/heap_area_total).
- Se llega a algún límite marcado por el sistema operativo.
3. Si todavía necesita más memoria, la reserva de la memoria extendida.
Pág. 32
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.
Roll Area Max use < In Memory + On Disk

Paging Area Max Use < In Memory + On Disk
Extended Memory Max Use < In Memory
Heap Memory Max Use < Dialog Session
4.3. SAP Cursor Cache
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.
Cada sentencia SQL asigna un identificador a la sentencia Open SQL/Native SQL

correspondiente. Este identificador incluye el nombre del report, el número de línea y la hora de
generación en ABAP/4. Así puede haber diferentes identificadores para la misma sentencia SQL de
diferentes programas. El analizador de sentencias eliminará más tarde dichas duplicidades quedando
un solo identificador por cada sentencia SQL nativa.
Todos los identificadores se almacenan en la Statement ID Cache y tienen una entrada
correspondiente en la Statement Cache. El número de entradas en la Statement ID Cache es varias
veces mayor que en la Statement Cache.
El hitratio nos da el número de aciertos al acceder a ambas Caches.

Los parámetros que establecen la SAP Cursor Cache, también afectan a otras áreas. Por eso se
recomienda no modificarlos sin la recomendación de Early Watch.
Pág. 33
4.3.1. Monitorización de la SAP Cursor Cache
Transacción ST02
Seguidamente vemos una serie de valores que indican un buen funcionamiento del sistema.
Servidor de la Base de Datos

ID’s Hit Ratio > 95 %
Statements Hit Ratio > 50 %
Servidor de Aplicación
ID’s Hit Ratio > 95 %
Statements Hit Ratio > 90 %
4.4. Call Statistics
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.
4.4.1. Monitorización de las estadísticas
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
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.
Accedemos mediante el menú:
Herramientas  Gestión  Monitor  Rendimiento  Database  Activity
Transacción ST04.
Pág. 35
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.
Dentro de este apartado podemos ver la siguiente información:
- Size : Muestra el tamaño del buffer de datos.

- Quality : Porcentaje de aciertos del buffer.
- Reads : Número de accesos de lectura realizados en el buffer. Este parámetro muestra la
importancia de este buffer.
- Physical reads/writes : Número de accesos a disco hechos por la base de datos. Estos
parámetros muestran los fallos del buffer.
- Busy waits : Número de veces que los procesos han tenido que esperar a que el buffer de
datos estuviera en estado consistente.
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.
5.2. Shared Pool
La Shared Pool es una área de memoria compartida en la System Global Area en la que
Oracle guarda las siguientes estructuras de memoria:
- Data Dictionary Cache : Contiene información de objetos Oracle (nombre, definición,

accesos) que es referenciada frecuentemente por la propia base de datos, por los
programas de aplicación y por los usuarios de la base de datos.
- Shared SQL Area : También se la conoce como Shared Cursor Cache. Contiene el árbol
de análisis y el algoritmo de ejecución para las sentencias SQL. La posibilidad de
reutilizar esa información para sentencias SQL idénticas, mejora el tiempo de las
transacciones y hace un mejor uso de la memoria. Los indicadores de rendimiento
muestran qué tanto por ciento de las veces que se accede al buffer se encuentran los
valores buscados.
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
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
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.
5.5. Table Scans / Table Fetch
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

Basis Manual Rendimientos

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Basis Manual Rendimientos

Transféré par

Droits d'auteur :

Formats disponibles

ESTUDIO DEL

Ricardo Casanovas Ortego

2. OPERATIVIDAD DEL SISTEMA 5

2.1. Monitorización de las instancias 5

2.1.1. Instancias arrancadas 5

2.2. Monitorización del sistema de actualizaciones 10

3. MONITORIZACIÓN DEL SISTEMA OPERATIVO 21

3.1. Utilización de la CPU 22

4. MONITORIZACIÓN DE LA MEMORIA DE SAP 26

4.1. Buffers de SAP 26

4.1.1. R/3 Repository Buffers (Nametab buffers) 26

4.2. Memoria de SAP 31

4.3.1. Monitorización de la SAP Cursor Cache 34

4.4. Call Statistics 34

4.4.1. Monitorización de las estadísticas 34

5. MONITORIZACIÓN DE LA BASE DE DATOS 35

5.1. Data Buffer 36

2.1. Monitorización de las instancias

- Verificar que todas las instancias están arrancadas.

2.1.1. Instancias arrancadas

Herramientas  Gestión  Monitor  Supervisar Sistema  Servidor

2.1.2. Monitorización de los procesos de trabajo

Herramientas  Gestión  Monitor  Supervisar Sistema  Resumen procesos

Desde el punto de vista de análisis de rendimiento y seguimiento de problemas, interesan los

· Procesa: El proceso está ejecutando algún programa.

- Report: Es el programa que está ejecutándose, Nos fijaremos si cambia de programa o

- Tabla: Estructura a la que está accediendo.

Como acceder: Seleccionar el proceso de trabajo y desde el menú:

Proceso  Trace  Visualizar Fichero

Herramientas  Gestión  Monitor  Traces  Traces Desarrollo

Estos ficheros se encuentran en el directorio local de cada instancia:

- Borrar modo: Permite cancelar el proceso de trabajo seleccionado.

Proceso  Cancelar con core

Podemos escoger entre estas dos opciones dependiendo de sí queremos un fichero de

Que hay que vigilar en los procesos de trabajo:

2.1.3. Chequeo del fichero de log de la instancia

Herramientas  Gestión  Monitor  Supervisar Sistemas  Servidor - Log Sistema

Herramientas  Gestión  Monitor  Supervisar Sistemas  Servidor – Usuario

Si un registro de actualización se procesa correctamente desaparece de la cola, pero si acaba con

El Administrador de SAP debe monitorizar sistemáticamente el sistema de actualizaciones

- Analizar los registros de actualización cuyo proceso ha tenido errores.

Herramientas  Gestión  Monitor  Actualización

Como norma pondremos los siguientes criterios de selección:

· Mandante: Mandante que interese

Debemos analizar los siguientes puntos:

1. El sistema de actualizaciones está activo:

2. Registros en estado Init esperando a ser procesados

3. Registros en estado Err

- Información del fichero de log de la instancia.

- Status Actualización: Muestra en que modulo de función se produjo el error, el

Updated Records  Repeat Update

Los datos de actualización se pueden ver desde las opciones:

Update Modules y Display Data

- Error de SAPGUI: Si un usuario apaga su PC sin terminar correctamente su sesión de

- Problemas en el proceso de actualización: Los procesos de actualización sólo liberan los

Para poder gestionar los bloqueos desde SAP R/3 accederemos a

Herramientas  Gestión  Monitor  Entradas bloqueo

Una vez determinados los criterios de selección obtenemos lo siguiente:

Accediendo por el menú:

Herramientas  CCMS  Jobs  Mantenimiento

En esta transacción podremos realizar un seguimiento de los Jobs definidos en el sistema.

- Job : Nombre del Job del que queremos obtener información.

El administrador deberá prestar especial atención a los Jobs de sistema siguientes: