Premisas a tener en cuenta para obtener un buen performance en SAP, PARTE V (ANALISIS DESARROLLOS ABAP)

Desarrollos ABAP (programas zeta del cliente) que van orientados a sentencias SQL y que por lo general por estar mal construidos la mayoría de las veces castigan al sistema.

En este frente son muchas las razones por las que un sistema se ve afectado a nivel de rendimiento, a continuación, las posibles causas más frecuentes:

1.       La mayoría de los casos ocurre porque el programa zeta construido para satisfacer una necesidad no está leyendo los índices creados.

2.       En algunos casos los programas zeta no están construidos cumpliendo las buenas prácticas, por nombrar alguno de ellos, el select *, crear más de tres join en una sentencia, entre otros.

3.       Inconvenientes con el tamaño de los índices, estos tienen igual o mayor tamaño que la tabla. Solo se deben reconstruir a través de la se14, por lo general un índice no debe ocupar más del 10% del tamaño de la tabla, máximo un 20% exagerando.

4.       Problemas con los programas estándar. Para ello solo basta con revisar si existen mejoras que puedan ser aplicadas a través de notas OSS.

5.       La tabla que el programa zeta está leyendo no tiene índices creados.

6.       Otra causa es que el programa estándar a pesar de estar leyendo los índices aun toma mucho tiempo de ejecución, para ellos se debe consultar notas oss que la mayoría de las veces recomienda crear un índice adicional o en su defecto actualizar el programa estándar.

7.       También sucede que algunas sentencias ya son obsoletas y deben ser actualizadas.

8.       La tabla que el programa zeta o estándar no tiene las estadísticas actualizadas.

9.       Dentro del proceso de análisis, uno de los mensajes que se identifican y te ponen en alerta, es cuando en el programa zeta del cual se está realizando el análisis, no está utilizando los índices, se refleja con el texto conocido como “FULL TABLE SCAN”.

Ahora, con relación a los índices para una tabla, existen algunas reglas que debemos tener claras a saber:

a.       No crear 2 índices con los mismos campos.

b.       El índice se debe crear con campos selectivos que van ser utilizados por la consulta y/o programa zeta y que son parte de la tabla.

c.       Como regla de oro un índice no debe contener más de cuatro campos

d.       Otra regla de oro a la hora de crear índices es no crear más de 5 índices por tabla.

e.       No cambie un índice creado por SAP, a menos que este soportado en una nota OSS.

f.        Nunca cambie un índice de más de 10 MB de tamaño durante horas de operación, ya que cuando se modifica el índice, este se bloquea y por ende toda operación que sobre el índice se esté realizando y que genera como consecuencia un congelamiento en algunas transacciones relacionadas o tienen relación con la tabla.

No me queda más que mencionar que para esta gestión, existen algunas herramientas que te ayudaran a evaluar la ejecución de un programa zeta en el sentido de hacer un trace a las sentencias sql (sql statements), cuando se sospecha que esta ocasionado alguna demora y en el peor de los casos u ocasionándole estrés al sistema o degradando el rendimiento del mismo, con el fin de tomar las medidas y/o acciones correctivas.

No obstante, pueden en algún momento, aunque es un poco complejo y bastante dispendioso, realizar seguimiento a un programa estándar, a saber:

·         Transacción ST05 (SQL trace)

·         Transacción STAD (Statistics)

·         Transacción SAT (Abap runtme Analysis)

·         Transacción ST03 (Work load analysis)

·         SQLM /SDF/ZQLM abap SQL monitor

Aunque la ST05 y la SAT entregan información detallada del performance acerca de sql statements y son capaces de seguir solicitudes o requerimientos que pueden ser enlazados a procesos de negocio, no están diseñadas para monitorear un sistema por un periodo de tiempo largo.

De otro lado, la STAD y la ST03 aunque son capaces de monitorear sistemas completo, no son capaces de entregar información detallada del performance acerca de sql statements.

Es de anotar que en algunos momentos se requieren realizar un monitoreo temporal por un periodo de tiempo largo, con el fin de identificar lo que no se pudo detectar con la transacción previas. Para ello existe en la actualidad una transacción denominada ABAP SQL monitor que cubre esa necesidad, es decir que es capaz de monitorear un sistema por un periodo largo de tiempo, mientras también están entregando información detalla acerca del sql statement que los puede enlazar a los procesos de negocio. De esta manera se tiene una colección de datos más gruesa para detectar cualquier falla que pueda estar ocasionando inconvenientes de rendimiento.