✒️ABAP HANA / El análisis y la optimización con SAP HANA Por Pedro Duarte

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

Si queremos desarrollar una nueva aplicación ABAP o optimizar una aplicación existente para utilizarla con SAP HANA, es posible que nos preguntemos qué enfoque adoptar y qué herramientas utilizar para realizar la optimización de los códigos ABAP existentes o generar de cero códigos ABAP performantes, que aprovechen al máximo la potencialidad que presenta el paradigma code pushdown.

Para cumplir con este proposito contamos con una serie de herramientas de análisis de tiempo de ejecución y error disponibles.

En nuestra labor diaria como desarrolladores ABAP, estamos familiarizados con algunas de las herramientas que se pueden usar para este propósito.

Repasemos a continuación con que opciones contamos:

Realizar traces de SQL a través de la transacción ST05: para poder conocer a que tablas bases de datos accede un programa de modo de poder determinar por ejemplo, si un SELECT está demorando más tiempo de lo que debería debido a que se está accediendo de forma no óptima a una tabla base de datos.

El análisis de tiempo de ejecución de ABAP mediante la transacción SAT: esta transacción es la evolución de la famosa transacción SE30 a través de la cual realizabamos análisis en tiempo de ejecución. La sección "Tips and tricks" de esta transacción nos permite comparar la performance de diferentes sentencias ABAP.

La verificación ampliada de código a través de la transacción SLIN: mediante la cual realizamos una verificación estática del código y nos permite detectar entre otras cuestiones muy valiosas, el código existente que no se utiliza.

Chequear el código generado a través del Inspector de código de SAP con la transacción SCI: a través de la cual podemos realizar comprobaciones de performance, seguridad, sintaxis, uso de convenciones de nombre, programación robusta, etc.

El ABAP Test Cockpit correspondiente a la transacción ATC: la cual es la evolución del Inspector de código. Presenta los mismos chequeos que la transacción SCI, sumado a una serie de mejoras que hacen que los chequeos de calidad de nuestras aplicaciones sean más eficientes y completos.

La utilización de los registros estadísticos mediante la transacción STAD: que nos proporcionan una visión general simple de los tiempos de la base de datos y son un punto de partida útil.

El análisis de transacciones individuales a través de la transacción ST12: la cual es una herramienta especial que combina transacciones STAD, SAT y ST05 en una sola interfaz.

El análisis de errores en tiempo de ejecución mediante la transacción ST22: que nos proporciona información valiosa para solucionar el problema que originó el dump.

A partir de ABAP 7.4 tenemos algunas herramientas nuevas y muy útiles, ellas son:

El Monitor SQL a través de la transacción SQLM: el cual supervisa el sistema de producción y proporciona datos valiosos de optimización del rendimiento. El monitor SQL básicamente recopila, agrega y persiste la información en tiempo de ejecución sobre las sentencias de SQL en la interfaz de la base de datos.

La memoria caché de SQL en la base de datos proporciona información específica de la base de datos sobre la declaración SQL (por ejemplo, la cantidad de páginas leídas o los tiempos de E/S y CPU requeridos). Estos datos junto con información sobre el programa ABAP y el contexto de llamada en el que se ejecutó la declaración, se encuentran disponible en el monitor SQL.

En consecuencia, estas dos fuentes de datos se complementan entre sí y proporcionan información adicional específica sobre las sentencias de SQL.

El SQL Performance Tunning WorkList Tool mediante la transacción SWLT: el cual podemos utilizar para combinar los datos del Monitor de SQL con los resultados del análisis del código y por lo tanto, hacer planes para lograr una optimización valiosa.

En lo que resta de esta lección analizaremos en detalle algunas de las herramientas que acabamos de mencionar y que resultan de suma utilidad para identificar las partes de un programa ABAP que tienen potencial para ser optimizadas.

AUDIO ACLARATIVO: Previo al momento de realizar la migración a SAP HANA resulta indispensable analizar ¿Qué de todo el código Z existente en el sistema SAP es realmente utilizado?. Esto se debe a que realizar la adaptación de los programas ABAP para SAP HANA requiere un esfuerzo en horas hombre, el cual se puede ver reducido ampliamente si solo se optimizan los programas que actualmente se utilizan en el sistema productivo. Para analizar el uso de las transacciones y programas existentes en el ambiente productivo contamos con varias transacciones estándar del sistema que son propias de los administradores del sistema SAP o SAP BASIS. Es ampliamente probable que nos encontremos que muchas de las transacciones o programas Z existentes en producción no se utilizan hace más de 5 años, por lo que allí habrá que determinar ¿Qué parámetros se toma para decir si optimizar o no una transacción o programa?.

2 | El análisis del código ABAP

El Inspector de código (transacción SCI) puede ayudarnos a identificar aquellas partes del programa que tienen potencial de mejora para SAP HANA.

Presenta una serie de comprobaciones que podemos realizar en los objetos de desarrollo.

Luego de ejecutado recibiremos una lista de mensajes con prioridad, cada uno asignado a la verificación correspondiente.

Debido a que pueden ocurrir falsas alarmas con estas comprobaciones, podemos insertar comentarios especiales en el código ABAP para evitar que se emita un mensaje.

SAP no permite escanear el código estándar del sistema con el Inspector de código.

2.1 | Las verificaciones relevantes al migrar a SAP HANA

Durante la migración a SAP HANA, la principal prioridad es asegurarnos que no se experimente ningún contratiempo funcional, incluidas las cancelaciones de programas dumps y los cambios no deseados en el comportamiento de una aplicación.

En general, gracias a la compatibilidad y portabilidad del código ABAP, no es necesario realizar ajustes a los programas.

Native SQL y hints de base de datos

Una excepción a la afirmación que acabamos de realizar es cualquier parte de un programa ABAP en el que hayamos utilizado implementaciones de bases de datos, es decir programas en los que utilizamos SQL nativo o Native SQL de la base de datos.

En las implementaciones de SAP donde se utiliza como base de datos a Oracle es común encontrarnos con las sentencias HINTS en los SELECT para forzar la utilización de los índices de las tablas.

Debemos tener en cuenta que estas sentencias son propias del SQL Nativo de Oracle y no funcionarán más luego de la migración a SAP HANA.

Para ayudarnos a localizar estos códigos dentro de los programas ABAP podemos utilizar las siguientes comprobaciones del Inspector de Código: Uso de la Interfase ADBC y Sentencias Criticas.

Comportamiento del SORT

El comportamiento del ordenamiento de los registros recuperados de las tablas bases de datos luego de un SELECT puede requerir adaptaciones, particularmente si no especificamos una ordenamiento explícito en el código del programa ABAP, por ejemplo, utilizando ORDER BY o SORT.

Debemos tener presente que en las tablas base de datos columnares si no especificamos la cláusula ORDER BY, la base de datos devolverá los registros de datos desordenados.

En las bases de datos clásicas, que utilizabamos hasta ahora, la secuencia del ordenamiento podía tener que ver con un índice de la base de datos que se usó para la consulta.

Sin embargo, esto era más bien una coincidencia, y no había ninguna garantía para esta clasificación. Para una programación estable, teníamos que especificar la adición ORDER BY si deseabamos que los datos regresen ordenados.

En SAP HANA, hay muchos menos índices de bases de datos, y la mayoría de ellos difieren de los de las bases de datos clásicas.

Para recibir los datos de lectura en la secuencia deseada, debemos si o si usar la adición ORDER BY o, posteriormente, ordenar en el programa ABAP usando SORT.

AUDIO ACLARATIVO: Podemos usar la opción de verificación del inspector de Código ABAP, buscar enunciados problemáticos para el resultado de "Select Open Cursor" sin Order By, para encontrar aquellas partes del programa para las cuales se procesa un conjunto de resultados que requiere una clasificación, por ejemplo en una búsqueda binaria usando un comando ABAP y para lo cual no se puede determinar una clasificación en el programa a través de order by o sort.

Adios a las tablas cluster y pool

Cuando se migra la base de datos a SAP HANA, las tablas cluster y pool son convertidas a tablas transparentes. Esta conversión es automática y no involucra que realicemos cambios a las aplicaciones que las utilizan.

Sin embargo, debemos tener en cuenta que cuando los registros son seleccionados con Open SQL sin especificar un ordenamiento determinado, según SAP el usuario no puede confiar en el ordenamiento (de acuerdo a la clave primaria de la tabla).

En este caso SAP recomienda tal como mencionamos anteriormente siempre especificar el ordenamiento con ORDER BY en el SELECT o con SORT luego de almacenados los registros en una tabla interna.

En la categoría Programación Robusta del Inspector de código tenemos disponible un check para ayudarnos a encontrar las partes de los programas ABAP que presentan SELECTs sin ORDER BY.

---

2.2 | Las verificaciones relevantes al optimizar para SAP HANA

Para identificar el potencial de optimización en el contexto de los accesos a las tablas de la base de datos contamos con un amplio rango de verificaciones que podemos llevar a cabo. Estas verificaciones se basan principalmente en las recomendaciones de performance de Open SQL.

A continuación analicemos en detalle algunas de estas verificaciones:

Uso inseguro de FOR ALL ENTRIES

Por una cuestión de mejor performance utilizamos FOR ALL ENTRIES o un join en lugar de realizar un SELECT anidado, es decir un SELECT dentro de otro SELECT, lo que resulta catastrófico desde el punto de vista de la performance.

Ahora bien, si utilizamos FOR ALL ENTRIES debemos tener presente que la tabla interna que se utiliza en la sentencia nunca debe estar vacía, ya que de lo contrario todos los registros de la tabla base de datos serán leídos.

Es por ello que siempre antes de ejecutar la sentencia FOR ALL ENTRIES debemos chequear que la tabla interna no se encuentre vacía.

Buscar las sentencias FOR ALL ENTRIES para transformarlas en uniones

En muchas casos, un join ofrece ventajas de rendimiento adicionales sobre la cláusula FOR ALL ENTRIES.

Por este motivo, podemos realizar una comprobación de las cláusulas FOR ALL ENTRIES existentes en los programas ABAP de modo de convertirlas en uniones.

Declaraciones SELECT que omiten el Buffer de tabla

El buffer de tabla base de datos que se tilda el crear la tabla todavía juega un papel importante cuando se usa SAP HANA como base de datos.

Para evitar una mayor carga de la base de datos, no debemos omitir este buffer si se ha activado el buffer para una tabla.

Para este fin, debemos realizar una comprobación en las instrucciones SELECT que ignoran el buffer.

Instrucciones problemáticas SELECT *

Debemos evitar leer las columnas de las tablas base de datos que no se necesitan.

Para este fin, hay una verificación disponible para encontrar sentencias SELECT para las que se seleccionan demasiados campos.

Con frecuencia, esto hace referencia a verificaciones de existencia, donde se seleccionan todos los campos SELECT *, mientras que solo con el código de retorno SY-SUBRC de la instrucción SELECT es suficiente.

Buscando SELECTs en Loops en subrutinas

Por lo general, los problemas de rendimiento no se deben a un solo acceso a la base de datos, sino a un gran número de accesos sucesivos.

Por ejemplo, pueden ocurrir problemas con los accesos que se ejecutan en Loops.

Hay una serie de controles que pueden encontrar esos Loops.

En particular, incluyen una verificación que encuentra sentencias SELECT que se ejecutan en Loops.

A partir de AS ABAP 7.4, las búsquedas también pueden extenderse más allá de las subrutinas, cuestión que anteriormente no era posible.

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 de modo de 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.

En SAP ECC desde el punto de vista de la performance, la utilización de la sentencia SELECT...ENDSELECT estaba totalmente desaconsejada y se sugería reemplazarla por SELECT SINGLE o SELECT INTO TABLE según el caso.

Esta misma recomendación aplica en el sistema SAP S/4 con HANA como base de datos.

AUDIO ACLARATIVO: Podemos configurar variantes de verificación en la transacción SCI correspondiente al espectador de Código. SAP nos proporciona un rango de variantes por defecto. Una variante muy útil en la variante Performance DB la cual se encuentra disponible a partir de ABAP 7.4. También podemos definir variantes de comprobación personalizadas, seleccionando y configurando las comprobaciones adecuadas desde el árbol de directorios. Además, podemos definir variantes de verificación específicamente para un usuario del sistema o globalmente para todos los usuarios del sistema. Esto es muy útil cuando trabajamos dentro de un pool de programadores de modo de que todos los programadores se ejecuten la misma variante del inspector de Código para la comprobación de los programas.