Procedimiento Tuning a Sistemas R/3

1. Aplicación Reglas Generales y Monitoreo para Tuning

2. Tuning orientado a DB Informix

3. Monitoreo de Procesos con alto tiempo de Respuesta

4. Table Buffers en R3

5. Notas Importantes sobre Tuning

APLICACION REGLAS GENERALES Y MONITOREO PARA TUNING

 UTILIZACION TRANSACCION SM50

Como una primera aproximación al sistema se puede consultar esta transacción (nos
interesa que sea en las horas con problemas de performance) en donde podemos observar
varios puntos:

Por ejemplo, en esta pantalla se observa que todos los procesos de diálogo se
encuentran ocupados por lo que algo que se podría hacer es aumentar el número de work
processes de diálogo (antes de hacer esto necesitamos consultar con otras herramientas de R3
si esto es posible, es decir que tengamos memoria suficiente).; pero inicialmente podríamos
suponer que aquí faltan WP de diálogo.

Igualmente podemos observar que la mayoría de las acciones son lecturas secuenciales.
Si al seguir monitoreando, observamos que las lecturas secuenciales son constantes, es posible
hacer un tuning. Una lectura secuencial se debe probablemente a un problema de ABAP (falta
de algún índice por ejemplo, o que no se están usando los índices indicados) o probablemente a
un problema de disco (esto se corrobora con otras herramientas de R3).

En la parte izquierda tenemos el botón CPU con el cual podemos refrescar

constantemente la pantalla con los tiempos de ocupación de cpu por el workprocess. En un
sistema bien configurado es normal que los primeros workprocess de diálogo tengan tiempos
altos, pero los últimos deben tener casi 0 ocupación ( o mínima), es decir que son ocupados
esporádicamente. Si constantemente, todos los workprocess de diálogo tienen altos tiempos de
cpu, esto es indicativo de que nos faltan procesos de diálogo.
Para poder agregar mas procesos de diálogo debemos comprobar que no tenemos problemas
de memoria ( cada workprocess de diálogo definido ocupa unos 12 MB y atiende
aproximadamente a 5 usuarios), y además se debe comprobar que no tenemos problemas de
cpu ( transacción OS06 )

En esta transacción podemos observar que el porcentaje de tiempo en que el CPU está
desocupado (idle) es del 1% (al menos debe haber un 20% libre en forma constante) además de
que el sistema cuenta con 2 cpus. En esta misma transacción, podemos observar que el espacio
configurado de swap es de 4 GB de los cuales se están usando la mitad (Usar el 50% o mas es
un indicio de alto swapeo de disco).

Cuál es el riesgo de añadir mas workprocesses de diálogo?

Como hemos visto, el añadir mas workprocesses de diálogo puede mejorar el

performance del sistema; sin embargo se requiere contar con la memoria suficiente para los
workprocesses y la cantidad de actividad de los cpu’s se puede incrementar (por lo que el
performance se puede decrementar). En este último caso conviene ir pensando en añadir CPU.

Cuánta Memoria ocupa R3?

Imaginemos que tenemos un sistema con problemas de performance y que

monitoreando la transacción SM50, vemos que sería conveniente aumentarle procesos de
diálogo, pero “…….hay suficiente memoria para definir mas dialog work process?”

Como primer paso debemos saber la cantidad de memoria RAM en el sistema, si no la

conocemos, lo podemos determinar en la transacción OS06:
 Por ejemplo, en este sistema observamos que se tiene 1 GB de memoria RAM con 4 GB
de swap configurado.

Mediante la transacción ST02, podemos observar la memoria que ocupa R3:

Si sumamos el espacio ocupado por los buffers de R3 (primer recuadro ) tenemos que el espacio
de memoria ocupado es de 369 880 KB (Aprox 370 MB).

Por otro lado, si observamos la cantidad de memoria ocupada por SAP (segundo recuadro: SAP
memory), vemos dos cosas:

1. El área de Roll y el área de paginación se encuentran definidas en la memoria del

sistema y no en disco duro.

2. La suma de las áreas de Roll, Paginación y memoria extendida es aproximadamente

de 1.5 GB.

Además, conocemos la memoria total que ocupa el motor de la base de datos mediante la
transacción ST04. En el caso de Informix, se tratará del tamaño total de la memoria compartida
(Total Size - Shared Memory) que en este caso se trata de 190.6 MB.

Sabemos por otro lado (mediante la transacción SM50) que este sistema cuenta con 24
workprocess ( y si cada uno ocupa aproximadamente 12 MB), esto ocupa aproximadamente 288
MB. La cantidad de memoria total ocupada por el sistema es la siguiente:

Memoria Buffers R3 ( aprox 370 MB) + SAP Memory ( aprox 1.5 GB) + Memoria ocupada
por los Wokprocess (aprox 288 MB) + Memoria DB (aprox 190 MB) + Memoria Sistema
Operativo.
Sin tomar en cuenta la memoria del Sistema Operativo, esto es aproximadamente 2.328 GB.

Conclusiones:

1. La cantidad de memoria RAM demandada por el sistema (2.328 GB) es superior

a la cantidad de memoria RAM física en el sistema (1 GB), lo cual conduce a un
mayor swapeo en el sistema (que de hecho se observa en la transacción OS06
al ver la cantidad de swapeo definido y ocupado).

2. Se tienen dos opciones: la primera crecer la cantidad de memoria RAM en el

sistema. La segunda consiste en tratar de adecuar los parámetros de memoria
de R3 a la memoria existente (en lo que llega mas memoria)

Qué parámetros de memoria se pueden modificar?

En la transacción ST02 observamos que la cantidad de memoria definida para SAP

(SAP Memory) para el área de Roll y paginación es de 262 y 236 MB respectivamente. Sin
embargo la cantidad de memoria utilizada por R3 es de 28.992 y 19.552 MB respectivamente.

Esto quiere decir que se encuentra definida la memoria de Roll y Paginación mucho mas
grande de lo que en realidad se está usando, por lo que se puede disminuir el valor de estos
parámetros para ajustarlos a lo que realmente está utilizando el sistema. Lo único que hay que
asegurarse, es que la utilización de estos buffers realmente haya sido la misma a lo largo del
tiempo. Para esto utilizamos el botón HISTORY de la transacción ST02 con lo cual vemos:
 En este caso vemos que hasta el día 7 de Abril la cantidad de memoria de Roll y
Paginación era de 262 MB definidos y la cantidad de memoria utilizada permanecía constante.
Después de esa fecha se cambiaron los parámetros del system profile para reducir su tamaño a
64 MB (se observa a partir del día 8 de Abril)

Los parámetros que definen el área de roll y de paginación en memoria son:

rdisp/PG_SHM y rdisp/ROLL_SHM. Los parámetros que definen el área de roll y de
paginación total (es decir en memoria y en disco) son los siguientes: rdisp/PG_MAXFS y
rdisp/ROLL_MAXFS. En este ejemplo los valores para dichos parámetros son los siguientes:

Rdisp/PG_SHM = 3000
Rdisp/PG_MAXFS = 3000

Rdisp/ROLL_SHM = 8000
Rdisp/ROLL_MAXFS = 8000

Es por esta razón que en la transacción ST02 la cantidad de memoria SAP en disco es 0. En
este caso se recomienda aumentar los valores de rdisp/PG_MAXFS y rdisp/ROLL_MAXFS para
que haya una definición en disco.

Además de disminuir los parámetros del área de Roll y de Paginación en memoria Ram,
se definen los parámetros para establecer el área de Roll y Paginación en Disco

Estos parámetros en este caso son DIR_ROLL y DIR_PAGING que por default apuntan al
directorio /usr/sap/<SID>/DVEBMGS00/data y deben tener al menos permisos 666 y pertenecer
al usuario <sid>adm/sapsys, así como los parámetros:

rdisp/rpag_file = /usr/sap/PRO/DVEBMGS00/data/PAGFIL00
rdisp/rrol_file =/usr/sap/PRO/DVEBMGS00/data/ROLLFL00

Cómo saber qué parámetros del system profile modificar?

En el presente ejemplo, nosotros ya sabemos que debemos decrementar los parámetros

de memoria de Roll y de Paginación; además sabemos que al menos en este caso particular,
nos conviene definir la paginación y memoria de Roll en disco duro (por la memoria limitada) en
lugar de memoria RAM.

Para encontrar estos valores, en la transacción ST02 seleccionamos el botón Current

Parameters .

TIP: Para buscar los parámetros se puede utilizar el comando %SC en el cuadro de
transacciones.
En la anterior pantalla observamos que los valores que afectan el tamaño de la memoria de Roll
y paginación (en bloques de 8 KB) son:

rdisp/ROLL_SHM (nuevo valor propuesto: 8000, es decir 64 MB)

rdisp/PG_SHM (nuevo valor propuesto: 3000, es decir 24 MB)

Igualmente se definen los parámetros del path en disco donde se direcciona el área de
paginación y roll . Si no hay suficiente memoria Ram, entonces el Roll File se debe configurar en
disco

DIR_PAGING
DIR_ROLL
rdisp/rpag_file = /usr/sap/PRO/DVEBMGS00/data/PAGFIL00
rdisp/rrol_file =/usr/sap/PRO/DVEBMGS00/data/ROLLFL00

TIP: En sistemas anteriores a la versión 30F, el programa de ABAP SAPMSO50 da acceso al

sistema operativo Unix.

Si se quiere ver los valores actuales que se tienen por default, se puede correr el reporte
RSPFPAR en la transacción SE38, o por medio del siguiente menú: Tools  Admin 
Monitoring  Performance  Setup/Buffers  Parameter Changes  Active Parameters.
 TUNING ORIENTADO A DB INFORMIX

Manejo de Memoria de Informix.

Básicamente, Informix se compone de tres elementos: Procesos (Virtual Processors o

VPS), discos y Memoria Compartida. La memoria compartida consiste a su vez de tres partes:

1. Porción Residente (R).

2. Porción de mensajes (M).
3. Porción Virtual (V).

La porción residente almacena datos del disco en una memoria caché compartida lo cual
asegura un acceso rápido a los datos; aquí se encuentran definidos los Buffer Pools y las colas
LRUS (buffers de datos).

La porción Virtual maneja los recursos para los procesos. Aquí se encuentran los sessions pools,
los sort pools, los data dictionary pools, etc.

La porción de mensajes habilita la comunicación entre los procesos clientes y servidores.

La primera porción de memoria que se aloja es la porción Residente, mientras que la

segunda porción de memoria alojada es la porción virtual. Además de las tres porciones de
memoria, la única que crece dinámicamente es la porción virtual. Existen tres parámetros en el
archivo ONCONFIG (Sistema Informix) que controlan la memoria:

SHMVIRTSIZE (Establece el tamaño inicial de la porción virtual al iniciar el sistema).

SHMADD (Aditional Segment Size, establece el tamaño de las porciones adicionales
de memoria que se añadirán a la porción virtual conforme se vaya acabando el espacio)
SHMTOTAL (Establece el tamaño total de la memoria para Informix, incluyendo las
porciones residente, virtual y de mensajes. En ocasiones es conveniente definir este
valor para evitar que Informix agregue y agregue porciones de memoria a la porción
virtual, especialmente cuando se tiene limitada la cantidad de memoria Ram.

SHMVIRTSIZE

SHMADD = 20

SHMVIRTSIZE SHMVIRTSIZE
=100 MB =200MB

Log message: Allocated additional

shared memory segment

Memory before Memory after

 SAP AG
 Informix puede añadir memoria a la porción virtual conforme la vaya necesitando, sin
embargo es conveniente definir desde un principio la cantidad total de memoria que necesitará a
lo largo de la operación productiva en lugar de que vaya añadiendo la memoria en pedazos.

Esto se debe a que existe un límite a nivel sistema operativo a que se sigan añadiendo porciones
de memoria y al hecho de que se crea overhead en el acceso de la memoria de informix.

Cómo se determina el tamaño óptimo del parámetro SHMVIRTSIZE?

Por medio del comando onstat -g seg, se puede saber el número de porciones adicionales al
valor inicial del SHMVIRTSIZE que se han agregado. En caso de que no se tenga acceso a nivel
sistema operativo, el acceso al comando onstat se obtiene mediante la transacción ST04 
DETAILED ANALYSIS, donde aparece un botón de “Onstat Commands”:

Al hacer click en el botón “Onstat commands” aparece la siguiente pantalla:

Al hacer click en la opción –g aparece la siguiente pantalla:

Se da doble click sobre la acción seg con lo cual aparece lo siguiente:

En la columna CLASS aparecen las porciones de memoria activas en el sistema Informix. La
porción Residente ( R ) aparece con un tamaño de 329 MB, la porción de mensajes ( M )
aparece con un tamaño de 696 MB y aparece una porción de la memoria virtual ( V )de 204 MB
(correspondiente al valor SHMVIRTSIZE), y dos porciones de memoria virtual ( V ) con un
tamaño de 33 MB (correspondiente al valor SHMADD) cada una.

El objetivo es monitorear constantemente el sistema y si después de algún tiempo de monitoreo,

(en que se haya reinicializado el sistema) se observa que el valor promedio de porciones
adicionales de memoria es de 2; entonces hay que añadir ese tamaño al valor inicial de la
porción virtual.

En este caso habría que añadir unos 66 MB al parámetro SHMVIRTSIZE

El valor recomendado para el parámetro SHMADD es de 32MB a 64 MB. Cada vez que se
agregue una de estas porciones de memoria a la porción virtual, se verá reflejado en el log de
informix (ST04  DETAILED ANALYSIS  DATABASE LOG MESSAGE ) con el siguiente
mensaje:

“ Dynamically allocated new shared memory segment “

 En este ejemplo observamos que el tiempo de checkpoint es de 9 segundos. Idealmente
debe ser abajo de 2 segundos, aunque prácticamente es suficiente si podemos mantenerlo abajo
de 10 segundos.

Supongamos el siguiente escenario: Se ejecutan las transacciones y reportes abajo

mencionados que son atendidos por los workprocess a nivel R3 y que ocupan los siguientes
espacios (los workprocess lo pasan a los Informix Process Sessions):
 APPLICATION SERVER SAP PROCESS VA01 ( 5 MB )
VL04 ( 75 MB )
ZREPORTE ( 8 MB )
VA01 ( 7 MB )

DB SERVER INFORMIX PROCESS SESSIONS

Conforme se van ejecutando transacciones y reportes en el sistema, van quedando sesiones con
esa cantidad de memoria alojada. La razón de esto es porque Informix trabaja en el supuesto de
que va a utilizarlas otra vez.

Para liberar estas sesiones que quedaron alojadas, se debe ejecutar el siguiente comando:

Onmode -F

La ejecución de este comando libera sesiones de informix no usadas y en ocasiones porciones

de memoria completas añadidas por el parámetro SHMADD. En sistemas donde falte memoria
Ram es conveniente correrlo cada 30 minutos y en sistema con suficiente memoria, se
recomienda que corra una vez al día.

Se puede programar en el Cron del sistema con los siguientes comandos:

Onstat –g seg
Onmode –F
Onstat –g seg

En ocasiones, la ejecución de este comando puede afectar negativamente la corrida de procesos

batch largos debido a que se tiene que estar cargando a memoria constantemente las tablas
mas usadas.

Con el fin de verificar la cantidad de memoria que se libera cada vez que se corre este comando;
otro lugar donde se pueden monitorear las porciones de memoria de Informix es en la
transacción ST04  DETAILED ANALYSIS  SHARED MEMORY:
NOTA: La memoria del sistema se va fragmentando paulatinamente lo cual lleva a un acceso
mas costoso de la memoria. Por esta razón es conveniente re-inicializar el equipo por ejemplo
cada dos semanas. Sin embargo, esto se debe manejar con mucho cuidado con el cliente pues
en ocasiones éste no lo entiende y puede generarle desconfianza. En la mayoría de las veces,
basta con reinicializar los servidores de aplicación a nivel R3.

Cómo saber cuantos usuarios se encuentran esperando en este momento en la cola del
dispatcher?

Se ejecuta la transacción SM51  Goto  Queue Information . La columna REQUEST

WAITING muestra los usuarios esperando en este momento.
Otros aspectos de la transacción ST04 (INFORMIX)

Anteriormente ya vimos algunos aspectos referentes a la memoria compartida, otros

aspectos en esta transacción son los siguientes:

DATA BUFFERS
Data Buffer Size

Total size of database shared memory buffer

This number gives the total size of database shared memory buffering
spaces. It is obtained indirectly by multiplying the database
configuration parameters, BUFFERS with the SYSTEM-PAGE-SIZE. The SYSTEM-
PAGE-SIZE is a fixed parameter and cannot be altered. The BUFFERS
configuration parameter can be found and altered via the Informix-Online
database configuration file found in the directory $INFORMIXDIR/etc.

Data Buffers Read Quality

The Read Quality percentage number is a measure of how much of the

information requested by the user is already stored in the shared memory
buffer. At system startup, database and shared memory buffer access
statistics are refreshed and begin to again compile. Therefore, care
must be taken such that this number is not interpreted too close to
system representation. Database performance is maximal the closer this
number approaches 100 percent.

If the cached read percentage is below 95 percent, you might be able to

improve performance by lowering the values of LRU_MAX_DIRTY and
LRU_MIN_DIRTY to increase the number of free and/or unmodified buffers
that are available in shared memory LRU queues. LRU_MIN_DIRTY and
LRU_MAX_DIRTY can be changed in the onconfig* parameter file located
in /$INFORMIXDIR/etc.

DATA BUFFERS WRITE QUALITY

Percentage of successful writes for shared memory buffer

The write quality percentage number is a measure of how much the

information needing update is successfully buffered. At system startup,
database and shared memory buffer access statistics are refreshed and
begin to again compile. Therefore, care must be taken such that this
number is not interpreted too close to system start time where the lack
of activity will not show an accurate representation. Database
performance is maximal the closer this number approaches 100 percent.

If the cached write percentage is lower than 82 percent, you might be

able to improve performance by increasing the LRU_MAX_DIRTY and
LRU_MIN_DIRTY parameters. They can be located in the Informix Onconfig
parameter file.

DATA BUFFER PAGE SIZE

System page size (KB)

The system-page-size parameter is taken directly from shared memory and

cannot or should not ever be changed. The parameter is hardware
dependent and defined by the operating systems kernel.
DATA BUFFER READS

The number of reads from the database shared memory buffer. This shared
memory buffer stores information retrieved from disk via a database
query. By doing this, repetitive database requests are accessed much
faster from the shared memory buffer than a repeated disk access

DATA BUFFER WRITES

The number of writes to the database shared memory buffer. This buffer
stores information which is to be updated on disk. By buffering the
information, the update process is more efficient, although there are
drawbacks. System failures may subject data to possibe loss while it is
waiting in buffer for update.

CLEANERS

PAGE CLEANERS

The database buffer cleaner processes are responsible for flushing the
data residing in the shared memory buffer pools. The optimal number of
cleaners depends on your hardware configuration. The maximum value of
altering the current ONCONFIG* parameter file located in
$INFORMIXDIR/etc.

Informix recommends that you configure a page cleaner for each disk that
online uses. However, if more than one disk shares a controler channel,
you might find that more than three page cleaners per controller
overburdens the controller. In most cases, the additional cleaners do
not improve performance unless you separate successive chunks from a
blobspace or dbspace on the disk. Ideally, you should try to assign
successive chunks to separate disk devices.

LRU QUEUES

The number of Least-Reciently-used queues specifies the number of queues

in the shared memory buffer pool. You can tune the value of LRUS, in
combination with the LRU_MIN_DIRTY and LRU_MAX_DIRTY parameters, to
control how frequently the shared memory buffers are flushed to disk.
These parameters are found in the ONCONFIG.

The minimum value of LRUs is 3, the maximum is 32. The optimal value of
LRUS depend on your specific hardware configuration. Your best guide for
selecting a value for LRUS is to experiment with different values and
monitor the performance benefits. You may find that a larger value
increases performance on machines with more than 2 CPUs.

LRU START CLEANING

The LRU_MAX_DIRTY percentage value specifies to the Online database

server when to begin flushing the LRU queues to disk. The default value
of LRU_MAX_DIRTY is 60 percent. (In practice page cleaning begins under
several conditions, only one of which is when the LRU_MAX_DIRTY value is
reached).

LRU END CLEANING

The LRU_MIN_DIRTY percentage value specifies to the online database

server when to end the flushing for the LRU queues to disk.
The default value of LRU_MIN_DIRTY is 50 percent, meaning that page
cleaning is no longer required when 50 percent of the buffers in an LRU
queue are modified. In practice, page cleaning can continue beyond this
point as directed by the page cleaner threads.

NUMBER POOL FLUSHES (Number of)

The number of database buffer pool flushes is a summary of all the

flushing activity resulting from any of the following three conditions.

1. When the number of dirty buffers in a LRU queue reaches its limit
determined by LRU_MAX_DIRTY.
2. When the page cleaner threads cant keep up – in other words, a user
thread need to acquire a buffer and none are available.
3. Online needs to execute a checkpoint.

FOREGROUND WRITES (Number of)

A foreground write is activated when a user thread cannot locate an

empty or unmodified buffer in the shared memory pool, therefore pages
must be flushed in order to make space. Foreground writes should be
avoided. If foreground writes are occuring, tune the value of the page
cleaning parameter by either increasing the number of page cleaners or
decreasing the value of LRU_MAX_DIRTY.

LRU WRITES (Number of)

A LRU write occurs as a result of prompting by the CPU virtual

processor. When the modified LRU queues reache the LRU_MAX_DIRTY
threshold a LRU write is initiated. This type of write is much more
efficient than a foreground write, and, overall, nots as efficient as a
chunk write.

LOG BUFFERS

PHYSICAL LOG BUFFERS.

Online uses the shared memory physical log buffers for tempory storage
of “befor-images” of dbspace pages. The “before images” in the physical
log enable Online to restore consistency to its databases after a system
failure.
The size of the 2 physical log buffers, located in shared memory, are
always equal. By double buffering, user threads are able to write to
the active phyical log buffer while the other buffer is being flushed
to the physical log on disk.
The PHYSBUFF parameter in the ONCONFIG file specifies the size of the
physical log buffers. Small buffers can create problems if you store
records that are larger than the size of the buffers. The minimum value
is 1. The maximum is n>= (page size). Recommended size is 16 pages.

To determine if tuning is needed see the help description for the

PhysLog written/IO parameter.

LOGICAL LOG BUFFER

Online uses the logical log buffer to store a record of changes to

Online data since the last archive. There are 3 logical log buffers
located in the shared memory area. Triple buffering permits the logical
logs virtual processor to write to the active buffer while one of the
others is being flushed to the current logical log file on disk, and
eventually to the logical log backup tapes.

The LOGBUFF parameter in the ONCONFIG file specifies the size of the
logical log buffers.

To determine if tuning is needed, see the help description for the

log.log written/IO parameter.

PHYSLOG WRITTEN / IO (kb)

This field gives the average number of kilbytes that were flushed from
the physical log buffer to the physical log on disk. Its value is an
indicator a to how well the physical log memory buffers are tuned. In
general, if this value is over 75 percent of the size of the physical
log buffer (or 100 percent using buffered logging), you can probably
improve performance by making the physical log buffer size larger.

Any adjustments to this parameter can effect the data buffered write
pecentages. This is due to modified data being held in the cache for
shorter or longer periods of time, restricting or permitting multiple
updates to the same data before it is written to disk.

LOG.LOG WRITTEN / IO

Average number of kbytes to logical log per write.

This field gives the average number of kilbytes that were flushed from
the logical log buffer to the current logical log file on disk. Its
value is an indicator as to how well the logical log memory are tuned.
In general, if this value is over 75 percent of the size of the logical
log buffer (or 100 percent using buffered logging), you can probably
improve performance by making th logical log buffer size larger.

DATABASE ACTIVITY
CPU VIRTUAL PROCESSORS

NUMCPUVPS is a value found in the ONCONFIG file. It specifies to online

the number of virtual processors of the cpu class to run. On a single
processor CPU you should only allocate one CPU virtual processor. On a
multiprocessor, you should not allocate more CPU virtual processors than
there are CPUs on the computer.

COMMITS

The number of ISAM commits since the starting of the database. A commit
is considered a completed transaction. There is not a one to one
correspondence between this value and the number of explicit COMMIT WORK
statements that are executed.

This information is most usefull whte the RESET button is utilized in

combination with the SINCE RESET button. These buttons will reset the
statistics so that values can be displayed over a controlled time
period.

ACTIVE DATABASE SERVER SESSIONS

This value is the number of sessions connected to the Online database

server.

ROLLBACKS

The number f ISAM rollbacks since the starting of the database. A

rollback is considered a completed transaction.

TRANSACTIONS / MIN

This value es the number of ISAM calls per/second since the last
starting of the database. This statistic is gathered across the Online
system and cannot be used to monitor activity on a single database
unless only one database is active or only one database exists.

TOTAL ISAM CALLS

Standard SQL statements are parsed into lower lever commands called ISAM
calls. The number of calls are monitored here to give an indication of
database activity.
Otros parámetros de Informix (ONCONFIG) concernientes a performance.

$ONCONFIG check 5 - MULTIPROCESSOR

CPU
MULTIPROCESSOR 0

MULTIPROCESSOR 1 CPU CPU CPU

... ... ...

OnLine SHM

OnLine SHM

OPERATING SYSTEM
MULTIPROCESSOR 1 MULTIPROCESSOR 0

 SAP AG

Este parámetro afecta la manera en como informix realiza las exclusiones mutuas (MUTEXES)
Cuando se tiene un máquina multiprocesadora, se debe cambiar no solo este parámetro, sino
también los siguientes:

NUMCPUVPS idealmente igual al número de procesadores físicos de la máquina (o CPU – 1).

SINGLE_CPU_VP si no es cero , el límite de CPU VP es 1, por lo que este parámetro debe ser
cero.

$ONCONFIG check 7 - AIOVPS.

NUMAIOVPS <n>

INFORMIX
OnLine SHM

1 2 ... <n>

n = Number of physdevs

 SAP AG

 The number of asynchronous IO virtual processors should be set to the number of physical
devices which contain dbspace chunks ( = the number of physdev<n>s). This number can be
increased dynamically.
 $ONCONFIG check 8 - NETTYPE
NETTYPE ipcshm,1,40,CPU

NETTYPE soctcp,1,40,NET

VP class

OnLine SHM
$INFORMIXDIR/etc/
sqlhosts.<interface> poll threads

 SAP AG

 The format of the value string for the NETTYPE parameter allows for the configuration of the
type of the network connection (referenced from the /informix/<SID>/etc/sqlhosts.<interface>
file), number of poll threads that will be polling for network requests of the given type, the
number of database users that will be expected to connect to the database (maximum value:
USERTHREADS), and the type of virtual processor within which the poll thread will execute
(affects performance).

 SAP R/3 requires two NETTYPE definitions: one for connections to the database from the
database instance itself (shared memory = ipcshm), and one for connections to the database
from dialog instances/application servers (<interface>tcp, for example, tlitcp or soctcp,
depending on hardware platform = TCP/IP).

Este es un parámetro importante para el desempeño del performance, por ejemplo, si en un

sistema se tienen suficientes CPU VPs, conviene que los POLL THREADS no estén corriendo en
VPs de tipo NET sino de tipo CPU ( son mas eficientes) . Si tengo la siguiente definición:

tlitcp, 2, 50, cpu

entonces se crearán 2 hilos POLL en 2 CPU VPs cada uno administrando 50 usuarios ( y como
los usuarios en informix son los workprocess, entonces cada POLL THREAD administrará 50
Workprocess). Si en el sistema R3 no se tienen tantos Workprocess, entonces conviene ajustar
este valor al número de Workprocess que se tiene, por ejemplo:

tlitcp, 2, 25, cpu

 $ONCONFIG check 9 - CPUVPS

physical CPU = 1
NUMCPUVPS 1
SINGLE_CPU_VP 1
MULTIPROCESSOR 0

physical CPU > 1

NUMCPUVPS <= num( )

SINGLE_CPU_VP 0
MULTIPROCESSOR 1

AFF_NPROCS m>1 m <= NUMCPUVPS

AFF_SPROCS k k <=m

 SAP AG

LRU_MAX_DIRTY = 100% => Long Checkpoint Duration

100% LRU_MAX_DIRTY

LRU_MIN_DIRTY

Write Activity
At checkpoints all dirty Between checkpoints there
C h ec k p o in t

C h ec k p o in t

pages are written from the is hardly any write activity.

buffer to disk.
The buffer still contains
lots of dirty pages because
LRU_MAX_DIRTY has not
been reached.

Time
CHKINTV
 SAP AG

 When the difference (LRU_MAX_DIRTY - LRU_MIN_DIRTY) is large or when

LRU_MIN_DIRTY is very high many dirty pages will be held in the Buffer Cache.
 At checkpoint time there will then be a large amount of write activity as the dirty buffer pages
are written to disk. This is evident in the long checkpoint duration.
 The checkpoint duration can be monitored in the
$INFORMIXDIR/online.<hostname>.<sid>.log file.
 If the checkpoint duration is longer than 10 seconds then consider reducing the
(LRU_MAX_DIRTY - LRU_MIN_DIRTY) differential.
 LRU_MAX_DIRTY = 10% => Small Checkpoint Duration

10% LRU_MAX_DIRTY 10%

5% LRU_MIN_DIRTY 5%

C h ec k p o in t
C h e c kp o in t

Time
CHKINTV
 SAP AG

 When LRU_MAX_DIRTY and LRU_MIN_DIRTY are small enough then the normal page
cleaner activity (which starts as soon as LRU_MAX_DIRTY is reached and stops at
LRU_MIN_DIRTY) will reduce the number of dirty pages remaining in the Buffer Cache. This
will then result in a shorter checkpoint duration.

Configuración de Buffers de Informix (Optimización de Performance)

A "SELECT" in Informix

Ready
Queue

CPU
VP

Buffer Cache

AIO
Queue AIO
VP Disk

 SAP AG
 The End User Enters a Select
The user thread goes to the ready queue for the CPU VP

Select Ready
Queue

CPU
VP

Buffer Cache

AIO
Queue AIO
VP Disk

 SAP AG

 A user working in the R/3 System causes an access request to be passed to the database.
 The access request is placed in the Informix OnLine ready queue and waits for a CPUVP to
process it.

The CPU VP Processes the SELECT

Is the required data already in the buffer cache?

Select Ready
Queue

CPU
VP

Buffer Cache

AIO
Queue AIO
VP Disk

 SAP AG
 If the Data is Already in the Buffer Cache...
The CPU VP gets the data and returns it to the user

Ready
Queue

CPU
VP

Buffer Cache

AIO
Queue AIO
VP Disk

 SAP AG

If the Data was not in the Buffer Cache

The CPU passes the request to the AIO VPs

Ready
Queue

CPU
VP

Buffer Cache

Select AIO
Queue AIO
VP Disk

 SAP AG

If the request cannot be satisfied from the Buffer Cache, then the request is submitted to the AIO
Queue and waits for an AIOVP to process it
 If the Data was not in the Buffer Cache (2)
The AIO VP finds the required pages and loads them to the
buffer cache

Ready
Queue

CPU
VP

Buffer Cache

Select AIO
Queue AIO
VP Disk

 SAP AG

 When an AIOVP becomes available to process the request it performs the direct disk access
and loads the data, which has just been read, into the Buffer Cache.

If the Data was not in the Buffer Cache (3)

The CPU VP can now return the data to the end user

Ready
Queue

CPU
VP

Buffer Cache

AIO
Queue AIO
VP Disk

 SAP AG

Por lo tanto, en base a la forma en como Informix realiza una petición SQL, podemos
establecer lo siguiente:
 Performance Monitoring: Health Check
Parameter BUFFERS:

A big buffer
increases the
probability of
finding a page in
the buffer (which
is faster than a
disk access)

CPU
VP

Buffer Cache

AIO
Queue AIO
VP Disk

 SAP AG

Performance Monitoring: Health Check

Parameter NUMCPUVPS:

Update
Select Ready A high number of
Queue CPU VP's decreases
the wait time in the
ready queue

CPU CPU
VP VP

Buffer Cache

AIO
Queue AIO
VP Disk

 SAP AG

 Where the database server is a multiprocessor machine it is possible to configure multiple

CPUVPS. This results in a degree of parallelism in the processing of requests that are
submitted to the database, and consequently will lead to a gain in performance.

Si un servidor que es multiprocesador solo tiene definido un cpuvp, habrá contención a nivel
informix, lo cual se puede observar en la transacción ST04  DETAILED ANALYSIS  WAIT
STATISTICS .
Si al llamar esta pantalla se despliega el mensaje : “ Statistics not Available”, se debe añadir el
siguiente parámetro en el archivo onconfig:

WSTATS = 1

Performance Monitoring: Health Check

KAIO option (where supported):
With KAIO the
CPU VP has
direct access to
disk and does
not give a
request to AIO
VP. -> decreases
AIO time

CPU
VP

Buffer Cache

AIO
Queue AIO
VP Disk

 SAP AG

 Kernel Asynchronous IO bypasses the normal OS system calls and AIOVP-queuing

mechanism. This results in performance gains.
 KAIO will automatically be used when it is available for the specific hardware platform.
 On some platforms KAIO leads to a detriment in performance. In such cases, the environment
variable KAIOOFF = 1 must be set.
Para ver el KAIO VP que está corriendo en el sistema se ejecuta el comando onstat –g act , o
se consulta por medio de ST04  DETAILED ANALYSIS  ONSTAT COMMANDS:

Otros conceptos Utiles de Informix.

Anteriormente se mencionó que Informix se compone de tres elementos principales:

memoria, procesos y discos. Ya se ha hablado algo referente a la memoria utilizada por
informix. En cuanto a los procesos, cada uno de estos en el ambiente de Informix OnLine se
conoce como un virtual processor ( VP ) porque programa y ejecuta sus propios hilos. Cada VP
pertenece a una clase de VP, la cual es responsible de tareas específicas.

Las clases de VP son las siguientes:

CPU All user threads and some system threads run in this class. The purpose of this
class is to put all the CPU intensive activities on this processes.

PIO Runs internal threads for the system which perform writes to the physical log on
disk.

LIO Runs internal threads for the system which perform writes to the logical log on
disk.

AIO Runs internal threads which perform all disk I/O except for writes to the logs
MSC Runs threads for miscellaneous tasks.
SHM Runs internal shared memory communication threads
TLI Runs internal TLI network communication threads
SOC Runs internal sockkets network communication threads
ADM Runs the timer
OPT Handles Blob transfer to an optical subsystem.
Los VPs aparecen a nivel Unix como procesos ONINIT mediante la ejecución del comando ps.
En cuanto a los VPs críticos, los CPU VPs y los AIO VPs son configurables mientras que los LIO
VPs y PIO VPs son autoconfigurables. Además los LIO y PIO VPs se encuentran espejeados
porque el Logdbspace y Physdbspace se encuentra espejeado.

En cuanto a los VPs de comunicación, los SHM, TLI y SOC VPs son igualmente configurables.
Algo que debe quedar claro, es que para el motor de la Base de Datos Informix, los clientes son
los workprocess a nivel R3.

De esta manera, si tenemos configurados 2 CPU VPs Y 2 AIO VPs como en el siguiente
ejemplo,

Cuando un proceso de informix necesita hacer una escritura a disco, pasa la petición a una de
las colas de algún AIO VP. Si al terminar de hacer la escritura regresa al CPU VP original y este
se encuentra ocupado, entonces va a la cola ready de algún otro CPU VP,  es decir que las
colas de los VPs se comparten.

En ocasiones se pueden ligar los CPUs físicos de un host con los CPU VPs, esto se
conoce en Unix como CPU Affinity y en algunos sistemas conviene para mejorar el
performance.

Para poder utilizar el KAIO VP se necesita tener el sistema operativo correcto con todos
sus parches. El KAIO VP es autoconfigurable y se ejecuta como un hilo de un CPU VP siempre y
cuando la variable de ambiente KAIOOFF no se encuentre activada.

Si existen algún problema con la configuración de los KAIO VPs, entonces se activa este
parámetro KAIOOFF = 1 y se configura 1 AIO VP por cada disco físico que se tenga.
En caso de que el KAIO VP se pueda configurar, se deben configurar igualmente al menos 2 AIO
VPs para poder escribir en los logs y los cooked files ya que los KAIO VPs solo pueden escribir
en Raw Devices.

Cada CPU VP tiene un hilo llamado sqlexec que viene siendo el master thread; otro hilo
que también posee es poll el cual corre todo el tiempo (polling for communication) .
Si se tiene una máquina con un solo procesador (y por lo tanto con un solo CPU VP) los demás
POLL THREADS deben correr en los NET VPs tales como TLI, SOC y SHM VPs, lo cual se
especifica mediante el parámetro NETTYPE en el archivo Onconfig.

Los POLL THREADS siempre están buscando nuevas conexiones mientras que los
LISTEN THREADS establecen todas las estructuras para una conexión que inicia.

El THREAD DISCONNEC se encarga de limpiar las áreas de memoria de las sesiones

desconectadas.

RA – TUNING (Read Ahead Tuning). Informix trata de leer por adelantado la información
mediante dos parámetros: RA_PAGES (max 32 pages) y RA_THRESHOLD (mas 30 pages).
Por ejemplo si se tienen los siguientes valores:

RA_PAGES = 32
RA_THRESHOLD = 10

Entonces Informix trae otras 32 páginas a buffer hasta que ya haya leído en buffer 10
páginas. La recomendación es no traer muchas páquinas que no se lean porque se
desperdicia el buffer), esto se logra aumentando el valor de RA_THRESHOLD. Al
ejecutar el comando onstat –p se obtiene una pantalla muy similar a la siguiente:

ixda_RA idx_RA da_RA RA_pgused

xxxx xxxx xxxx xxxx

ixda_RA = index data

idx_RA = index
da_RA = data

Cuando un sql statement como el siguiente: “ select * from <tabla> “ se ejecuta, se

incrementa el valor de da_RA.

Cuando un sql statement como el siguiente se ejecuta: “ select customer_num from

Customer” se incrementa el valor de idx_RA porque se está leyendo de un índice.

La suma de ixda_RA, idx_RA y da_RA no debe ser diferente al 15-20% de RA_pgused,

de lo contrario se deben mover los parámetros RA_PAGES y RA_THRESHOLD (tratar
de acercarlos y aumentarlos).
Con el comando onstat –u se puede obtener el número de usuarios atendidos en el sistema
(es decir el número de workprocess).

Los comandos onstat –g seg , ipcs obtienen información sobre las porciones de memoria
virtual añadidas al sistema.

Con el comando onstat –g glo | pg se obtiene cuales son los VPs que tienen los polls de
comunicación que están corriendo. El número en la columna de vp-class indica el órden que
éstos iniciaron.

Al ejecutar el comando ps –ef | grep oninit debe coincidir los números de procesos oninit con
el número de VPs que obtengo mediante el comando onstat –g glo. Si esto no es así, lo mas
probable es que se encuentre otro Informix Server ejecutándose en la misma máquina.

Para saber cuánto ocupa de memoria un WP, se debe ejecutar el comando onstat –g mem | pg
lo cual me dá el SID de informix y el tamaño en memoria. Mediante la transacción ST04 se busca
el equivalente del SID y el PID de los workprocess y mediante la transacción SM50 se identifica
de qué workprocess se trata.

Para saber si se están ejecutando los hilos KAIO y los VPs en los cuales se ejecuta , se corren
los siguientes comandos: onstat –g ath | pg y/o onstat –g ioq.

El comando onstat –c muestra los parámetros del archivo ONCONFIG.

Mediante el comando onstat –p se monitorean los buffers de Informix. Aquí el Read % cached
debe ser mayor al 95% y el write % cached debe ser mayor al 85%.

El comando onstat –g rea muestra la actividad que tengo en las colas de los CPU VPs. Si
tengo muchas colas en espera, es necesario incrementar el número de CPU VPs.

CLEANERS = La recomendación para los cleaners es 1 por disco si se tiene un solo CPU VP.
En caso de tener mas de 1 CPU VP, se recomienda tener 1 cleaner por chunck

LRU QUEUES = El mínimo son 8, pero lo óptimo es tener 4 * N° CPU VPs. Para ver si tenemos
suficientes colas, se debe correr el comando onstat –g spi y en caso de tener una alta espera,
se deben aumentar.
Al aumentar el número de BUFFERS, conviene aumentar los LRU QUEUES pero no tanto para
que los CLEANERS no tengan mucho trabajo.

En un checkpoint, los CLEANERS graban a disco de los BUFFERS (Chunck Writes, las cuales
son muy eficientes). La actividad de los usuarios se suspende durante un checkpoint, por lo cual
se requiere que éstos sean cortos.

Si en la transacción ST04 se observan escrituras FOREGROUNDS WRITES (muy ineficientes),

se debe aumentar el número de CLEANERS y mover los valores LRU MAX y LRU MIN.

Otros TIPS

Otra transacción de utilidad es la SM66 , donde podemos ver todos los workprocess de un
sistema. A diferencia de la SM50, aquí podemos ver los workprocess del servidor de base de
datos y de los servidores de aplicación (del sistema productivo por ejemplo).
En el botón “SELECT PROCESS” de dicha transacción podemos seleccionar los tipos de
workprocess que deseamos monitorear (Diálogo, Batch, Update, etc).

Si se localiza a un usuario que está loggeado varias veces en el sistema, entonces se procede a
averiguar el porqué de esta situación.

Si mas del 75% de usuarios presentan SEQUENTIAL READ, esto puede deberse probablemente
a un problema de código de Abap o a disco.

 Transacción ST02: Si “In Memory” – “Max. use” < 20% de “In Memory” in la línea “
Extended Memory”  Se debe incrementar el parámetro R3 em/initial_size_MB
TIEMPOS DE RESPUESTA.

Mediante la transacción ST03 se pueden analizar los tiempos de respuesta del sistema R3.

En términos muy generales, se pueden establecer las siguientes reglas:

 CPU time << Process Time  I / O cuello de botella, problemas CPU.

 “Wait time” es alto  Faltan WP.
 “Load time “ es alto  R/3 buffers muy chicos, missing indexes.
 Si “CPU tiime” > 40 % “Response time”  Utilizar los ABAP TRACES.
 Si “Av Roll” > 2X rated disk access time  Incrementar el área de Roll
 Si “Process Time” >> “CPU time”  Analizar disco / red.
 Si “DB time” > 40% “Response time”  R/3 buffers muy chicos, missing indexes.

9 The Average Response Time is only for the application server. It has
the value of 313.7 ms (= 0.3 second). The Average Response Time of
most transactions is approximately less than 2 seconds.

10. The Average CPU Time is 194.2 ms (= 61.9% of the Average Response
Time) which is higher than the normal value. CPU intensive tasks
have occurred during the time interval. The Average CPU Time should
be approximately 40% of the Average Response Time. If it is above
40%, the problem may be one of the following:

 Input/output (I/O) bottleneck

 Network problem
 Slow or old CPU speed
 Too much swapping
 Wrong allocation of I/O intensive files, such as: Swap files,
Oracle online redo log files, Oracle offline redo log files,
Oracle data files.
11. The Average Wait Time is 6.9 ms (= 2.2% of the Average Response
Time) which is a little bit high. The Average Wait Time should be
less than 1% of the Average Response Time. (A high server workload
can produce higher wait times.) If it is above 1%, there may not be
enough work processes, or work processes are too busy.

12. The Average Load Time is 18.7 ms (= 5.96% of the Average Response
Time) which is normal. Load Time normally represents the time for
loading and generating ABAP/4 source code and screen information
from a database. The Average Load Time should be less than 10% of
the Average Response Time. If it is above 10%, there may be missing
indices, or R/3 buffers are too small.

13. The Average Database Request time is 95.8 ms (= 30.5% of the

Average Response Time) which is normal. Average Database request
time should be around 40% of average response time. If it is above
40%,there may be missing indices, too many extents, database CPU
bound, or database memory bound. The Operating System affects
approximately 10% of the above values. Database Calls are the
number of parsed requests sent to a database. There have been
159,892 calls in this example since the R/3 System started up.

14. Database Requests are the number of logical ABAP/4 requests for
data in the database. These requests are passed through the SAP
database interface and parsed into individual database calls. Take
note of the proportion of database calls to database requests. If
access to information in a table is buffered in the SAP buffers,
database calls to the database server are not needed. There are
250,137 requests that are divided into three kinds of requests:

 Direct reads
 Sequential reads
 Changes

15. The time of Direct Reads for each Database Request is 63,774 ms,
which is too high. The normal value should be less than 10 ms.

16. The time of Sequential Reads for each Database Request is 16.2 ms,
which is a little too high. The normal value should be less than 10
ms.

17. The time of Changes and Commits for each Database Request is 10.9
ms, which is normal because this value should be less than 25 ms.
Note that the R/3 System in this example has been used to import a
whole client from another R/3 System, and therefore there are many
read and write activities. These values are not indicative of a
correctly configured and tuned R/3 System.

En la transacción ST03, se pueden hallar cuales fueron los TOP 40 RESPONSES TIMES
mediante el botón TOP TIME:
En esta transacción se monitorea para ver cuales son las transacciones con mayor tiempo de
ejecución (monitorear en un largo lapso de tiempo). Se recomienda buscar notas en el OSS
sobre performance relacionadas con estas transacciones.

Igualmente en la transacción ST03 se puede obtener un listado de las transacciones de R3 con

sus tiempos de ejecución mediante el botón TRANSACTION PROFILE :

O se puede obtener la cantidad de memoria utilizada por cada transacción mediante el botón
MEMORY PROFILE:
REORGANIZACIONES.

Es conveniente monitorear la contención en disco que pueda existir en un sistema. Puede

suceder que un sistema se encuentre lento porque presenta un cuello de botella de I/O debido a
que el acceso mas frecuente a determinadas tablas, se encuentre sobre un solo disco.

R3 cuenta con herramientas para determinar cuál es nuestro disco con mayor acceso mediante
la transacción OS06:
Cuando los parámetros KB PAGED IN /S y KB PAGED OUT / S se incrementan, esto es
indicación de que se está realizando mayor swapeo.

Cuando el parámetro PHYSICAL MEM FREE empieza a disminuir, el swap empieza a aumentar.

En este caso aparece que el disco con mayor tiempo de respuesta es el SSD0, si se hace doble
click sobre éste, aparece la siguiente pantalla:

En este caso se trata de una plataforma solaris, por lo que para obtener información de qué
disco se trata se debe teclear el siguiente comando a nivel sistema operativo.
$ dmesg | more

Se deben identificar no las tablas mas grandes en el sistema sino las mas accesadas en lecturas
y/o escrituras para que , si es conveniente, sacarlas de su dbspace original y colocarlas en otro
dbspace en un disco con menos acceso en disco.

De esta manera es necesario identificar los discos con mayor acceso, los menos accesados, así
como las tablas mas grandes y accesadas. Para obtener las tablas mas grandes, partimos de la
transacción DB02.

DB02
DB02  SPACE STATISTICS

También debemos poner especial atención en el número de extents con que cuenta determinada
tabla. Informix tiene un límite de 120 – 150 extents por lo que al acercarse a este límite, se hace
necesaria una reorganización.

ST04  DETAILED ANALYSIS  TABLE ACTIVITY

En el siguiente ejemplo se identificaron las siguientes tablas mas grandes de la base de

datos(mediante las transacciones DB02 o el SAPDBA) :

FCABP 10.5 GB
 BSAK 4.5 GB
BSAD 4.3 GB
BSIS 6.6 GB
BKPF 4.6 GB

La estrategia adoptada fue crear dbspaces nuevos por cada tabla (de hecho el nombre del
dbspace es el nombre de la tabla) de la siguiente forma:

NOMBRE TAMAÑO COMPARACION AL TAMAÑO

ORIGINAL

Logdbs 946212 valor actual

Physdbs 205000 valor actual
Psapbtab 11003451 valor actual
Psapclu 11281920 valor actual
Psapddic 250000 valor actual
Psapdocu 1000000 valor actual
Psapel30f 1000000 valor actual
Psapes30f 4000000 valor actual
Psapload 250000 valor actual
Psappool 2000000 valor actual
Psapprot 500000 valor actual
Psapsource 250000 valor actual
Psapstab 4088000 valor actual
Psapuser1 250000 valor actual
Rootdbs 200000 valor actual

Creación de dbspaces temporales

Tmpdbs1 1 GB Modificar
Tmpdbs2 1 GB Modificar
Tmpdbs3 1 GB Modificar

Creación de Nuevo Dbspaces.

Psapfcabp 15 GB Modificar
Psapbsak 6 GB Modificar
Psapbsad 6 GB Modificar
Psapbsis 8 GB Modificar
Psapbkpf 6 GB Modificar

Así mismo se propusó la creación de 2 dbspaces mas para tener un mejor desempeño del motor
de la base de datos, según lo especifica la nota 49381 , de manera que se tengan 3 dbspaces
temporales de 1 GB, (en las versiones 4.x, esto se define desde el momento de la instalación )
esto se realiza de la siguiente manera:

Originalmente existía un dbspace temporal de 3GB, por lo que se realizó lo siguiente:

1) Logon con el usuario <sid>adm

2) Ejecutar el comando stopsap r3

3) logoff del sistema.

4) Logon con el usuario informix

5) Ejecutar SAPDBA (crear dbspace)

Seleccionar la opción b) Dbspaces enter
" " " d) Add a Dbspace enter
" " " a) <tmpdbs2> enter
Nota: Nombre del dbspace temporal
tmpdbs2, tmpdbs3 o psaptmp2, psaptmp3 (para evitar conflictos de
nombres)

Seleccionar las opciones d) y c)

Seleccionar la opción s)

Ahora seleccionar la opción t) (para obtener el data140 ó data141, los cuales se

definieron en nuestro caso previamente)
EJECUTAR

Nota: se debe asignar el data140 a tmpdbs2 y data141 a tmpdbs3

A continuación se procede a borrar el dbspace temporal ya existente para

recrearlo nuevamente.

6) Ejecutar SAPDBA (Borrar la dbspace tmpdbs1)

Seleccionar la opción b) Dbspaces enter

" " " c) Drop a Dbspace enter
" " " a) <tmpdbs1> enter
Nota: Nombre de la dbspace temporal tmpdbs1
EJECUTAR

7) Crear el dbspace temporal tmpdbs1 nuevamente (ver paso 5)

8) Agregar los nuevos dbspaces temporales en el archivo ONCONFIG en la variable:

DBSPACETEMP tmpdbs1,tmpdbs2,tmpdbs3

REORGANIZACION DE TABLAS MEDIANTE SAPDBA

Por otro lado el procedimiento para sacar las tablas de sus dbspaces originales a sus
nuevos dbspaces es el siguiente:

 Se baja la aplicación sap mediante un STOPSAP R3

 Se deshabilita el modo unbuffered logging de la base de datos mediante el sapdba:
 Se selecciona la opción f) Logging Mode y se cambia el modo de operación de la base de
datos a modo “NO LOGGING”.

 Se crean los nuevos dbspaces seleccionando la opción b) Dbspaces , después la opción d)

Add a Dbspace

Una vez definido el tamaño del dbspace y creado este, se selecciona la opción c)
Reorganize del menú principal obteniendose la siguiente pantalla:
Se selecciona la opción e) Reorganize Single Table y aparece la siguiente pantalla:

Se puede reorganizar mediante la opción EXPORT / IMPORT, con lo cual se necesita de

espacio adicional en disco duro para almacenar el dump de la tabla. Sin embargo una
manera mas eficiente de realizar la reorganización es mediante la opción de Reorganizar la
Tabla mediante INSERT INTO SELECT FROM .

Una vez que ha terminado la reorganización, aparece el siguiente mensaje si la tabla se

movió a otro dbspace:

DBA098I: Table ‘FCABP’ was moved to a different dbspace! The SAP data
Dictionary was updated accordingly by SAPDBA. To kkeep these changes during
the next upgrade of your R3 system you must update de DDIC manually within R3
 using transaction SE13 and release the correspondign transport request
afterwards.
Within transaction SE13 please enter ‘APPL1’ as new ‘data class’ for table FCABP.
You find details about transaction SE13 in the DDIC documentation.

IMPORTANTE:
Lo que sucede es lo siguiente: Cuando se realiza un upgrade o reorganización
mediante copia de base de datos de un sistema al que se le han sacado tablas a vivir fuera de
sus dbspaces nativos, al final de estos procesos, los dbspaces regresan a sus dbspaces
originales.

Para solucionar esto existen dos posibilidades: Se vuelven a sacar las tablas después
de un upgrade o copia de base de datos; o se actualiza el diccionario de R3 para indicarle el
nuevo dbspace hogar de las tablas. Esto se realiza especificándo el nuevo data class
indicado en el mensaje de la reorganización por sapdba en la transacción SE13. En la
transacción SE14 también aparece la especificación del dbspace hogar de una tabla.

Transaccion SE13:

Transacción SE14:
En la opción “ Storage parameters”:
TIP: Se observó que la reorganización mediante copia de base de datos se realiza en forma
mas rápida si el sistema cuenta con el último nivel de Kernel Patches.
 MONITOREO DE PROCESOS CON ALTO TIEMPO DE RESPUESTA

Para el monitoreo de Programas y Reportes con altos tiempos de ejecución se ejecutan

las siguientes transacciones:

 Se ejecuta la transacción SM66

En esta transacción se muestran los programas ejecutados en todos los servidores (tanto el
de base de datos como los servidores de aplicaciones. Esta transacción se monitorea
constantemente mediante el botón de REFRESH para encontrar los programas que se
llevan mas tiempo. Si se hace doble click en uno de los programas deseados, aparece la
siguiente pantalla:
Aquí se muestran datos sobre tiempo de que lleva ejecutándose, usuario que lo mandó y
número de reporte.

 Una vez que se encuentra un programa o reporte largo, se ejecuta la

transacción SM50 sobre el servidor que se desea monitorear: (la transacción
SM51) muestra lo mismo pero de todos los servidores existentes.

En esta pantalla obtengo el identificador del proceso el cual se utiliza para encontrar la
instrucción SQL utilizada en este reporte mediante la transacción ST04 botón
DETAILED ANALYSIS botón ORACLE SESSION / INFORMIX SESSION Y botón
SQL STATEMENTS. De la transacción ST04  Detailed Analysis  Oracle – Informix
Session obtengo el session ID, el cual se compara con el session ID de ST04  Detailed
 Analysis  Sql Statements (Para que aparezca el Session ID en esta última transacción, se
debe hacer click en el botón PER SESSIONS).

La instrucción SQL nos muestra las tablas sobre las cuales está leyendo/escribiendo.

Las tablas se consultan en la transacción SE12 (solo lectura) o SE11 (modificable). En

esta transacción se puede consultar los índices definidos que tiene una tabla y compararlos con
los campos que lee una instrucción SQL sobre dicha tabla. De esta manera se puede determinar
si se está o no aprovechando el índice.

Por ejemplo, si un índice se compone de los campos: campo1,

campo2,campo3,campo4,campo5 y la instrucción SQL solo lee los campos campo4,campo5
entonces no se está aprovechando el índice y en realidad se está efectuando un barrido
secuencial en la lectura/escritura de esta tabla.

EJEMPLO:

En la transacción SM66 tenemos:

Aquí vemos que el reporte con mas tiempo de ejecución es RFFMS012 de FSEHERNANDEZ
con pid 22457.

En la transacción SM51:
Aquí vemos igualmente el reporte con el pid 22457.

En la transacción ST04  Detailed Analysis  informix session:

Aquí se ve el reporte con pid 22457 tiene el sid 6802.

En la transacción ST04  Detailed Analysis  Sql Statement tenemos:

Aquí se busca el sql statement con sid 6802 y se hace doble click para ver dicho sql statement:

Se comparan los campos que se están leyendo sobre esta tabla y los índices definidos para ver
si falta algún nuevo índice o si éstos no se están aprovechando correctamente. En este caso se
necesitaría un índice que incluyera a los campos MANDT y OBJNR (que aparecen en el
WHERE).
SOLUCION: Modificar la instrucción SQL para que utilice todos los campos ( en el caso de que
el reporte provenga de una pantalla, hacer que sea mandatorio para el usuario el llenado de los
campos necesarios en la pantalla para la utilización completa del índice). Otra solución es
definir un nuevo índice para la instrucción SQL. La creación de índices se puede dar
incluso para programas de SAP y no solo para programas realizados por el cliente.

En la transacción SM04 se puede encontrar la transacción utilizada por un usuario o

reporte.

TABLE BUFFERS EN R3

Los Buffers de R3 son locales a los servidores de aplicación.

Los Buffers de R3 ayudan a reducir el acceso sobre la red a la base de datos y ayuda a quitar
trabajo de la base de datos.

La diferencia de tiempos de acceso a los buffers y la base de datos es significativa.

There are three basic buffering types:

 Resident buffering (100%): the contents of the whole table is loaded into the buffer on the
first access to any data from the table.
 Generic buffering: a generic key (first n key fields) is specified when maintaining the
technical settings. This generic key divides the contents of the table into so-called generic
areas. When accessing any data with a specified generic key, the whole generic area is
loaded into the buffer. The figure shows the case of generic buffering with one and two fields
as generic key. A very typical case of generic buffering is the client-dependent buffering
(client is the first key field). When specifying resident buffering for a client-dependent table,
the ABAP/4 Dictionary automaticly uses generic buffering with one key field.

 Partial buffering (single record): only single records are read from database and stored into
the buffer.

SQL Statements Bypassing Buffer I

 All buffer types:
 SELECT ... BYPASSING BUFFER
 SELECT FOR UPDATE
 Any aggregate function (COUNT, MIN, MAX, SUM, AVG)
 SELECT MIN(F1) FROM T1 WHERE ...
 SELECT DISTINCT
 WHERE clause contains ... IS NULL
 ORDER BY (other than PRIMARY KEY)

There are several statements which can not be satisfied from the buffer. Those statements
bypass the buffer and are sent directly to the database. The above shows the statements which
bypass any buffer type.
Those statements should be avoided when programming with buffered tables in order to
guarantee good performance. An exception are maintanance transactions on buffered tables.
Those should use an explicit SELECT BYPASSING BUFFER to ensure to get the most-up-to-
date data directly from the database.
SQL Statements Bypassing Buffer II
Partial Buffer:
A non-single select
SELECT * FROM T1 WHERE ...

Generic Buffer:
Select without specifying the generic key
SELECT * FROM T1 WHERE ...

The above statements bypass the partial/generic buffer.

What happens when a buffered table is updated (inserted, deleted)?

 The update is performed on the database table and in some way also on the buffer. The
exact buffer handling depends on the type of the buffer. Either the buffer is updated, or the
contents are simply marked as invalid (they will be read on the next access).

 For systems with single application server this is consistent.

In case of more than one application server, the buffer of application server B is not updated
immediately.

The updating statement is executed by the R/3 DBIF (Database Interface) which inserts a record
into the table DDLOG indicating the change on the table T001.

 Each application server (in our example B) reads periodicly the contents of DDLOG in order
to invalidate the contents of its buffer if necessary.
 The period for the synchronization is usually 1 or 2 minutes (profile parameter)
 Within this period, users on applicartion server B read the ’old’ data. First after the buffer
synchronization, the data is marked as invalid and reread again on the next access.
Granularity of Invalidation

Resident (100%) bufferable tables:

Any change invalidates the buffered table
Generic bufferable tables:
Most changes invalidate the corresponding generic area(s)
Partial bufferable tables:
Work area mode invalidates one buffered record
Other changes invalidate the whole table

The granularity of invalidation depends on the buffering type.

In work area mode, the head line of a table (work area) is used to transfer data, e.g. ’UPDATE
dbtab.’ where dbtab has been defined as ’TABLES dbtab.’.

Technical Settings (SE13) -> !screen shot!

Is a table bufferable ? (logical decision)
If yes: buffering type (technical decision)
resident (100%)
generic (generic key) + length of generic key
partial (single record)
Special: Buffering allowed but off
in customer system buffering can be swiched on
specification of buffering type is optional
Views? INDX tables?

The most important question is: is a table bufferable? This can be answered with yes if the table
is read-mostly and if it is acceptable that changes on this table are not immediately visible on all
application servers.

The buffering type can only be decided based on the access profile on this table. In most cases
this should be known to the programmer of the table and thus, on of the settings partial, generic
or resident should be set. For some special cases a new type ’installation-dependent’ is
introduced. If this is set, the table is initially not buffered but can be set to one of the above types
in the running system.

R/3 Buffers - What can be buffered?

In a productive system rarely changing data:
Table buffers for tables with:
rather small size
(’small’ depends on access frequency)
read-mostly access
e.g. control tables, customizing tables,
’small’ master data
As of 4.0: views have technical settings
Special buffer for runtime objects:
programs, dynpros, table structures
 NOTAS IMPORTANTES SOBRE TUNING

Nota 97497 Memory management parameters

Nota 33576 Memory management 30C
Nota 15374 Performance Analysis
Nota 38981 Performance Problems
Nota 103747 R3 4.x parameters recommendations
Nota 21636 Increasing Ram Extension
Nota 16223 Problems with roll memory
Nota 121808 Swaps in program buffer
Nota 43427 HPUX Shared memory limits
Nota 37537 Performance increase by share memory pools
Nota 38052 System panic, terminations due to low swapspace

Oracle

Nota 40137 ArchiveLink Increase SPA, GPA parameters

Nota 3155 Sapdba tablespace overflow

Informix

Nota 24189 Informix Disk Layout

Nota 29413 Extending Logical Logs
Nota 95094 Increase size of physical Logs
Nota 29873 Informix performance analysis of Selects
Nota 24509 Informix DBSL parameters
Nota 41360 Informix Onconfig parameters
Nota 38307 Reducing Informix shared memory consumption

Jorge Raúl Nuevo Fonseca

Consultor basis