✒️El análisis y la optimización con SAP HANA

1 Introducción al análisis y optimización con SAP HANA

Ya sea que deseemos optimizar código ABAP existente o generar desde cero código ABAP para aprovechar al máximo la potencialidad del paradigma code pushdown, tenemos una serie de herramientas de análisis de tiempo de ejecución y error disponibles para cumplir con dicho propósito.

Tal vez algunas las conocemos como desarrolladores ABAP, veamos cada una de ellas:

• Realizar traces de SQL mediante transacción ST05: Para poder conocer a que tablas de BD accede un programa y determinar si un SELECT se demora demasiado por acceder de forma no óptima a la(s) tablas(s).
• Análisis de tiempo de ejecución de ABAP mediante transacción SAT: Es la evolución de la SE30 y permite realizar análisis en tiempo de ejecución. La sección "Tips and tricks" de esta nueva transacción nos permite comparar el performance de diferentes sentencias ABAP.
• Verificación ampliada de código mediante transacción SLIN: Para realizar verificación estática del código y detectar entre otras cuestiones, código que no se utiliza.
• Revisar código generado a través del inspector de código de SAP mediante transacción SCI: Para realizar comprobaciones de performance, seguridad, sintaxis, convenciones de nombres, programación robusta, etc.
• El ABAP Test Cockpit de la transacción ATC: Es la evolución del inspector de código. Presenta las mismas revisiones que SCI sumado a una serie de mejoras que hacen que las revisiones de calidad sean mas eficientes y completas.
• Utilizar registros estadísticos mediante transacción STAD: Nos proporciona una visión general simple de los tiempos de la base de datos y son un punto de partida útil.
• Análisis de transacciones individuales mediante transacción ST12: Es una herramienta especial que combina STAD, SAT y ST05 en una sola interfaz.
• Analizar errores en tiempo de ejecución mediante transacción ST22: Nos proporciona información valiosa y detallada sobre el problema que originó en DUMP.
• (ABAP 7.4 en adelante) Monitor SQL mediante transacción SQLM: Supervisa el sistema de producción y proporciona datos para optimización del rendimiento. Basicamente recopila, agrega y persiste la información en tiempo de ejecución sobre las sentencias SQL en la interfaz de la base de datos. La memoria caché de SQL proporciona información sobre la declaración SQL (cantidad de páginas leídas o tiempos de E/S y CPU) y esos datos junto con la información del programa y contexto de llamada en que se ejecutó estan disponibles en SQLM. En consecuencia, toda esta información se complementa y proporciona información adicional específica sobre las sentencias SQL ejecutadas.
• (ABAP 7.4 en adelante) SQL Performance Tunning Worklist Tool mediante transacción SWLT: Para combinar los datos del monitos SQL con los resultados del análisis del código y por lo tanto, hacer planes para lograr una optimización valiosa.

A continuación vamos a analizar a detalle algunas de las herramientas mencionadas y que resultan útiles para identificar partes de un programa ABAP que tienen potencial de ser optimizadas.

2 Análisis del código ABAP

El inspector de código SCI puede ayudarnos a identificar las partes del programa que tienen potencial de mejora para SAP HANA. Presenta una serie de comprobaciones que podemos realizar en los objetos de desarrollo y una vez ejecutado nos mostrará una lista de mensajes con prioridad, cada uno asignado a la verificación correspondiente. Cabe señalar que pueden ocurrir falsas alarmas, es algo que debemos tener en consideración y saber que es posible insertar comentarios especiales en el código ABAP para evitar que se emitan dichos mensajes. Recordemos que el inspector verifica rendimiento, seguridad, sintaxis y cumplimiento de convenciones de nombres sobre objetos individuales o grupos de objetos.

Antes de continuar, necesitamos conocer algunas definiciones:

• Variante de verificacion: Define las reglas que se aplicaran, comprobaciones a realizar y configuracion de dichas compobraciones.
• Conjunto de objetos y Object Set: Define los objetos de desarrollo que se incluirán en la inspección.
• Inspección: Define una combinación de variante de verificación y conjunto de objetos, es decir, que comprobaciones se realizarán sobre que objetos.
• Diferencia entre variantes locales y globales: Lo global esta disponible para todos los usuarios, los locales están asociados con un ID de usuario.
• Variante Default: SAP la proporciona y es la que se utiliza para objetos que se verifican en el menu contextual de programas, clases, módulos, etc. Cabe señalar que si creamos una variante de verificación llamada Default, esa es la que SAP utilizará en lugar de la global.

El Code Inspector te permite definir variantes, conjunto de objetos y tus corridas (inspecciones). Ojo, después de la primera vez que realizas una inspección, la siguiente vez ya no es "nueva inspección" sino "crear nueva versión" de la inspección para que simplemente repita la ejecución y ver los nuevos resultados después de haber realizado nuestras modificaciones pertinentes.

A continuación un video donde se habla de lo anterior: ***VIDEO AQUI***

2.1 Verificaciones relevantes al migrar a SAP HANA

Nuestro principal objeto al migrar debe ser que no se experimente ningún contratiempo funcional, incluyendo cancelaciones por DUMPs y cambios no deseados en el comportamiento de nuestras aplicaciones. En general, gracias a la compatiblidad y portabilidad del código ABAP, no es necesario realizar ajustes a los programas.

2.1.1 Native SQL y Hints de base de datos

Una excepción a la compatibilidad son las implementaciones de bases de datos, es decir, utilización de SQL Nativo o Hints para bases de datos. Los Hinst son particularmente comunes en implementaciones de SAP donde se utiliza Oracle como base de datos para forzar el uso de índices de las tablas. Estas sentencias ya no funcionarán después de migrar a SAP HANA.

Para ayudarnos a localizar estos códigos dentro de ABAP podemos utilizar las siguientes comprobaciones del inspector de código: Uso de la interfase ADBC y Sentencias críticas.

2.1.2 Comportamiento del SORT

El comportamiento del ordenamiento de los registros recuperados de las tablas luego de un SELECT puede requerir adaptaciones, particularmente si no estabamos ordenando nada ya sea con ORDER BY o con SORT.

En las bases de datos clásicas, la secuencia de ordenamiento podía tener que ver con un índice utilizado para la consulta pero era una coincidencia, no es que hubiese garantía de que así sería. Para una programación estable teníamos que especificar un ordenamiento.

En bases de datos columnares si no se especifica la cláusula ORDER BY, la base de datos devolverá los registros desordenados. Si deseamos recibir los datos en una secuencia determinada, debemos utilizar ORDER BY o posteriormente ordenar en el código ABAP usando SORT.

2.1.3 Adios a tablas cluster y pool

Las tablas cluster y pool en SAP HANA son convertidas en tablas transparentes. Esto es automático y no involucra cambios a las aplicaciones que las utilizan. Lo único a considerar es, como se mencionó en el punto anterior, que se debe realizar un ordenamiento explícito a los resultados obtenidos si es que esperamos un cierto orden en los registros.

2.2 Verificaciones relevantes al optimizar para SAP HANA

Para identificar el potencial de optimizaci[on en el contexto de los accesos a base de datos contamos con un amplio rango de verificaciones que se pueden realizar, la mayoría de ellas orientadas a performance.

2.2.1 Uso inseguro de FOR ALL ENTRIES

Si utilizamos un FOR ALL ENTRIES debemos tener presente que la tabla interna que se utiliza nunca debe estar vacía o de lo contrario todos los registros de la tabla serán leídos. Es por ello que siempre debemos revisar que la tabla interna no se encuentre vacía antes de ejecutar el FOR ALL ENTRIES.

2.2.2 Buscar sentencias FOR ALL ENTRIES para transformarlas en JOINs

En muchos casos, un join ofrece ventajas de rendimiento sobre la cláusula FOR ALL ENTRIES. Debido a ello, podemos realizar una comprobación para realizar esta conversión o sustitución.

2.2.3 Declaraciones SELECT que omiten el buffer de tabla

El buffer sigue siendo útil en SAP HANA. Para evitar una mayor carga de la base de datos, no debemos omitir ese buffer si se ha activado para determinada tabla. Para ello, hay que realizar una comprobación en los SELECT que omitan su utilización.

2.2.4 Buscando SELECTs en LOOPS en subrutinas

Por lo general, los problemas de rendimiento tienen que ver con múltiples accesos sucesivos a la base de datos. Por ejemplo por realizarse dentro de LOOPS o en subrutinas que incluyen una llamada pero son ejecutadas desde un LOOP.

2.2.5 EXIT/CHECK en SELECT...ENDSELECT

Si utilizamos la sentencia EXIT para salir de un SELECT...ENDSELECT, es posible que una gran cantidad de registros de datos se lean innecesariamente y esto se debe a que los datos se transfieren en bloques. En ese caso debemos usar la sentencia CHECK inmediatamente luego a la instrucción SELECT para indicar que no se usa un filtro hasta que se han leído los datos. Con frecuencia, estas dos expresiones se pueden convertir en una condición WHERE adecuada.

Tips

• Previo a la migración resulta valioso analizar que, de todos los desarrollos Z existentes, sigue siendo utilizado. Esto para optimizar solo los programas que realmente se usan. Seguramente encontrarás varios que ya no son necesarios.
• SAP no permite escanear el código estándar del sistema con el inspector de código.
• Podemos configurar variantes de verificación en la SCI de forma personalidad pero cabe señalar que SAP nos da algunas variantes que pueden sernos de mucha utilidad, por mencionar alguna tenemos la llamada PERFORMANCEDB.
• En ECC se recomendaba por performance no utilizar SELECT...ENDSELECT sino reemplazarla por SELECT SINGLE o SELECT INTO TABLE según fuera necesario. Esta misma recomendación sigue siendo válida en SAP S/4HANA.
• Podemos usar la opción "Buscar enunciados problemáticos para resultados de SELECT OPEN CURSOR SIN ORDER BY" de la verificación del inspector de código ABAP para encontrar partes de programas que necesitan conjuntos de resultados que requiere una ordenación y que tal vez no la tengan. Un ejemplo de ello serían las búsquedas binarias. Puedes buscarlo en la categoría de Programación robusta.

Agradecimiento:

Ha agradecido este aporte: Martín Gómez Rodríguez