Premisas a tener en cuenta para obtener un buen performance en SAP, PARTE III SISTEMA DE BASE DE DATOS.

Premisas a tener en cuenta para obtener un buen performance en SAP, PARTE III SISTEMA DE BASE DE DATOS.

En este ámbito lo que se debe tener en cuenta, son varios elementos importantes que interactúan con la gestión de la base de datos y que, si no se encuentran bien definidos y afinados, pueden llegar a impactar su rendimiento, a saber:

·         El primero de ellos es el cache ratio que dependiendo del motor de base de datos, el valor varia, pero por lo general en promedio debe estar por encima del 98%.

·         El segundo, es tener un tamaño ideal para el log de la base de datos. ¿Qué significa?, responderé la pregunta, pero no sin antes aclarar el proceso y que va orientado para aquellas personas que desconocen cómo opera. La base de datos dentro de su gestión lo primero que hace es escribir en el log, para luego con otro evento escribir físicamente a los archivos que conforman la base de datos. Esto con el fin de asegurar y garantizar la integridad, que, en otras palabras, antes cualquier fallo, el motor es capaz de recuperarse a partir del fallo, manteniendo su operatividad y funcionalidad. Dicho eso, responderé lo que mencioné al inicio de este punto. Cuando hago referencia al tamaño ideal de log, me refiero, al tiempo que transcurre, entre el momento que se genera un archive log y otro.

Este efecto se produce debido a la tarea que ejecuta el proceso que maneja el redo log, pues una vez alcanza el limite definido, lo mueve al disco, por ende, genera un archivo físico que denominados archive log. Este redolog trabaja en memoria. Si el tiempo es de menos de un minuto, significa que es muy pequeño lo cual genera un alto IO en el disco, de ahí la necesidad de evaluarlo y si es el caso ampliarlo. Este fenómeno está catalogado con uno de los elementos que afecta el rendimiento. No hay un dato exacto, pero dependiendo del motor, puede cambiar el tamaño. Un elemento de apoyo para definirlo se encuentra en el EWA, que no es más que un reporte en donde te examina la salud del sistema en todos los ámbitos y que hablaré en un artículo independiente más adelante.

En este punto resalto la importancia de tener una estrategia de backup a nivel de logs muy bien configurada, la recomendación siempre es tener una copia del log en el disco y otro en la cinta y esta última asegurada y custodiada por un ente externo que cumplan con las normas que se exigen para este tipo de almacenamiento, con sus debidos controles.

·         El tercer punto es revisar como se encuentran programadas las estadísticas de la base de datos, en la transacción DB13, deben estar acorde a lo recomendado por SAP y varía dependiendo del motor.

En esto punto es importante resaltar que un factor importante para mejorar el rendimiento es la periodicidad para ejecutar las estadísticas a nivel de sistema operativo, para ello existen cinco premisas a tener en cuenta:

1.       Cuando se aplica una actualización del parche en la base de datos o después de un upgrade del motor de base de datos, por ejemplo, de la 9i a la 10g.

2.       Después de un upgrade de SAP.

3.       Cada tres o cuatro meses por seguridad.

4.       Cuando se haya hecho una carga representativa de datos.

5.       Cuando se haya instalado o desinstalado una instancia de SAP, en el modo MCOD, es decir varias instancias de SAP en el mismo motor de base de datos.

La premisa que más se utiliza es la tercera, que corresponde a ejecutar cada cuatro meses los comandos que abajo se detallan y que actualizan las estadísticas a nivel del diccionario de datos como las estadísticas del sistema de Oracle.

brconnect -u / -c -f stats -t oradict_stats

brconnect -u / -c -f stats -t system_stats

La mayoría de los casos esta recomendación nunca es tenida en cuenta, solo se tiene presente en el momento cuando el rendimiento se ve degradado y se aplican como correctivos, una mala práctica, pues siempre esperamos a que estos sucesos ocurran para poder aplicarlos, cuando es una de las tareas en el ejercicio del proceso de administración basis y que se clasifican como acciones preventivas.

·         El cuarto, es afinar los parámetros de base de datos de acuerdo con las notas que existen para ello, en donde se hacen unas recomendaciones que han sido probadas previamente por SAP pero que no son la última palabra, aunque si son un punto de partida para afinar su sistema y tenerlo alineado a su operación, pues no todos los sistemas corren con el mismo número de usuarios, ni con la misma carga, ni con las mismas aplicaciones, ni tampoco con los mismos recursos, por ende, varían.

Nota: Hoy por hoy ya existen scripts para algunos motores de base de datos, que nos pueden ayudar y que permite analizar cada parámetro de la base de datos con el fin que sea cotejado con los parámetros básicos que recomienda SAP, que nos dan un abrebocas de cómo se encuentra nuestro sistema y que puede ser complementado con el EWA convencional que se encuentra programado en la instancia y es generado a través del solution manager. En caso de que este no sea de mucha utilidad, se puede recurrir a un servicio más especializado de SAP y que basado en el histórico nos puede arrojar ajustes significativos a realizar, todo en pro de mejorar el rendimiento.

·         El quinto, es la actualización en cuanto al parche, es importante también hacerlo y mantenerlo actualizado, por cuanto vienen muchas mejoras y ajustes que se hacen debido a bugs encontrados o en su defecto porque han mejorado algunos algoritmos, todo en pro del bienestar del motor. Obviamente esto requiere una evaluación previa antes de aplicarlo en el sistema productivo.

·         El sexto, es chequear aquellas transacciones que están castigando al sistema, bien sea del cliente como estándar, que están ocasionando tiempos de respuesta muy altos.

·         El séptimo, es revisar que no exista algún log activo, como es el caso, de la ST05 que evalúa sentencias sql, el caso de la transacción “SWELS - Switch Event Trace On/Off” que activa el log del módulo de workflow, transacciones que ocasionan alto stress al sistema y que sí, permanecen mucho tiempo activadas o en el peor de los casos en horas de alta actividad, con toda seguridad afectarán el rendimiento.

Estos primeros 7 puntos son los más relevantes en el análisis de rendimiento para una base de datos, pero si a pesar de haberlos ajustados no se ven cambios significativos, es bueno ir un poco más al fondo y para ello es chequear el tamaño del datafile, que es como se le conoce a uno de los archivos físicos que componen y construyen un tablespace. En condiciones ideales el tamaño debe ser homogéneo. Pero cuando se observan muy disparejos, solo queda un camino y es la reorganización. En este punto de la reorganización, debemos realizar algunos pasos previos, entre los que se encuentran, calcular el tamaño de cada datafile, separar las tablas y los índices de aquellas tablas que tienen un alto IO, en tablespace independientes, reconstruir índices, depurar aquellas tablas estándar para disminuir el espacio de la base de datos, entre otros.

Para poder hallar el tamaño de cada datafile, el cálculo está sujeto a variables como son el tamaño de la base de datos, el tiempo que resta del contrato de renovación tecnológica, tamaño de crecimiento promedio por mes, entre otros. 

Para un mejor entendimiento lo ilustraré mediante un ejemplo, a través del análisis en el motor de base de datos Oracle.

Para desarrollar el ejemplo, utilizaré la transacción dbacockpit, ya que desde allí obtengo más información en la que me indica en que debo concentrar mi atención para identificar la causa raíz.

·         Lo primero que ejecuto es un script que me ayuda a entender el estado de la base de datos a nivel de rendimiento y que no es más que la relación entre el “Busy wait time" y el "CPU time"

SELECT

  ROUND((STM1.VALUE - STM2.VALUE) / 1000000) "BUSY WAIT TIME (S)",

  ROUND(STM2.VALUE / 1000000) "CPU TIME (S)",

  ROUND((STM1.VALUE - STM2.VALUE) / STM1.VALUE * 100) || ' : ' ||

  ROUND(STM2.VALUE / STM1.VALUE * 100) RATIO

  FROM V$SYS_TIME_MODEL STM1, V$SYS_TIME_MODEL STM2

  WHERE STM1.STAT_NAME = 'DB time' AND STM2.STAT_NAME = 'DB CPU';

El resultado debe ser la relación entre un 60 y 40%, lo cual indica que es un sistema que se encuentra bien afinado, valores diferentes o cercanos al 80:20, requieren de la atención respectiva, ya que deben entrar en un proceso de análisis, chequeo, ajuste y monitoreo.

·         Lo segundo es evaluar las estadísticas, que, hablado en términos coloquiales, nos ayudan a definir el mejor camino para realizar las consultas. Estas se revisan en la DB13 y la idea es que chequear que por un lado se encuentren programadas de acuerdo con las buenas prácticas y del otro lado que su ejecución haya sido exitoso.

·         Lo tercero, es revisar la frecuencia de escritura/lectura o “disk Access time” que evalúo a través de la ST06, pues en condiciones normales la carga de un disco o porcentaje de utilización no puede exceder el 80%, si hay valores altos se debe revisar con el fabricante del HW. He visto sistemas con valores sobre el 100%, lo cual indica que algo sucede a nivel físico o de almacenamiento, por ende, el performance se degrada.

En esta imagen los discos están al 100 de utilización, por ende, la tasa de transferencia va aumentando, afectando los tiempos de respuesta, que se reflejan en la parte de aplicación con los usuarios finales, transacciones que toman más del tiempo en procesarse, reportes que demoran en terminar, entre otros.

·         Lo cuarto, es las sentencias sql que es uno de los puntos importante para el rendimiento y aclararé en un artículo independiente.

·         Lo quinto, es revisar si existe un cuello de botella a nivel de HW, para ello de forma conjunta se evalúa el comportamiento de la CPU, memoria y paginación sobre el servidor de base de datos. Para ello a partir de la versión 10g existe la vista V$OSSTAT o en su defecto desde DBA_CPU_USAGE_STATISTICS, en donde se puede obtener esa información.

·         Lo sexto, es revisar el tamaño del buffer pool, que se encuentran en la st04, área data buffer ->”Quality %”, este debería ser al menos del 94% en operación normal. Si es muy bajo el hit ratio (quality) puede obedecer a que el tamaño del buffer data parámetro es muy pequeño, lo cual debe ser chequeado y en su defecto ampliado. Es importante tampoco exagerar en el valor pues puede quedar sobredimensionado, al punto de llegar a no tener un efecto positivo y más bien si se puede estar pecando en tener un recurso de memoria subutilizado innecesariamente, cuando podría estar siendo utilizado por otros procesos.

·         Lo séptimo, es evaluar su versión del parche, revisando que no haya salido del plan de mantenimiento de SAP, en caso tal, se debe proceder a realizar la preparación en un ambiente de pruebas para realizar la actualización y evaluar su comportamiento, pues de esta forma se garantiza que, en caso de presentar alguna anomalía, SAP puede prestar el servicio de soporte correspondiente.

·         El octavo es chequear el indicador de las sentencias sql que se mide con el parámetro "Reads/User Calls", un valor superior a 15 indica que las sentencias sql deben ser revisadas, pues debido a su mala construcción pueden estar ocasionado un comportamiento no deseado. Esto puede aplicar tanto en los programas del cliente como en los programas estándar.

·         El noveno, es chequear la fragmentación de las tablas e índices que requieren de un trabajo adecuado representado en tiempo, pues se llegan a encontrar tablas que están muy fragmentadas y el paso para mejorarlas es mediante una reorganización, que es otro tema que requiere se mencionado con detalle.

Existen otros parámetros que pueden ser chequeados y que se encuentren detallados en la nota “618868 - FAQ: Oracle performance”.

Cerraré este aparte indicando que en caso extremo y dependiendo de la transaccional es probable que a pesar de aplicar los correctivos el performance o el rendimiento no mejore, como última alternativa, queda ejecutar un quicksizer, que es una herramienta de SAP que permite calcular los SAPS que se requieren y se necesitan, representado en la estimación de los recursos físicos, para que SAP opere en su día a día, pues en algunos casos se puede presentar que el reporte arroje que por el volumen de información y debido a la alta transaccionalidad, el mejor camino sea separar la instancia de SAP, de la base de datos, es decir en un servidor dejar la instancia de SAP y en otro servidor la base de datos (concepto que se conoce como instalación distribuida) con el fin de lograr un mejor rendimiento, pero como lo mencioné son estrategias que existen y están allí para aportar un camino de solución a una tema de rendimiento.