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

Análisis y optimización con SAP HANA

1- Introducción al Análisis y optimización con SAP HANA.

Para lograr optimizar nuestros programas ABAP contamos con una serie de herramientas de análisis de tiempo de ejecución y error disponibles.

Contamos con las siguientes opciones:

-> Realizar traces de SQL a través de la TX ST05: De esta manera identificamos a que tablas está accediendo el programa y si en alguna de ellas está tardando más de lo normal, debido a un acceso no optimo.

-> Análisis de tiempo de ejecución mediante la TX SAT:

Está TX es la evolución de la TX SE30 mediante la cual se puede realizar un análisis en tiempo de ejecución.

La sección "Tips and tricks" nos permite comparar el performance de diferentes sentencias ABAP.

-> La verificación ampliada de código a través de la TX SLIN:

Nos permite detectar mediante una verificación estática el código que no se utiliza, entre algunas otras cosas muy valiosas.

-> Chequear el código generado a través del inspector de código de SAP con la transacción SCI:

Mediante 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:

Es la evolución del inspector de código.

Presenta los mismos chequeos que la TX SCI, sumado a una serie de mejoras que hacen que las revisiones de calidad de nuestras aplicaciones sean más eficientes y completas.

-> La utilización de los registros estadísticos mediante la transacción STAD:

Nos proporciona una visión general simple de los tiempos de la BD y es un buen punto de partida.

-> El análisis de transacciones individuales a través de la transacción ST12:

Es una herramienta especial que combina las transacciones :

- STAD

- SAT

- ST05

En una sola interfaz.

-> El análisis de errores en tiempo de ejecución mediante la transacción ST22:

Nos brinda información valiosa para solucionar el problema que provocó el "DUMP".

A partir de ABAP 7.4 tenemos algunas herramientas nuevas y muy útiles las cuales son:

-> El monitor SQL a través de la transacción SQLM:

Supervisa el sistema de producción y proporciona datos valiosos de optimización del rendimiento. Básicamente recopila, agrega y persiste la información en tiempo de ejecución sobre las sentencias SQL en la interfaz de la BD.

La memoria cache de la BD nos proporciona datos específicos de la BD sobre las declaraciones SQL (cantidad de páginas leídas, tiempos de E/S y CPU requerido, entre otras).

Estos datos junto con información del programa ABAP y el contexto de la llamada en la que se ejecutó la declaración, están disponibles en el monitor SQL.

-> El SQL Performance Tunning WorkList Tool mediante la transacción SWLT:

La podemos usar para combinar la información del monitor de SQL con los resultados del análisis del código para lograr una buena optimización.

NOTA: Antes de comenzar la migración de los programas "Z" se puede solicitar el apoyo de los BASIS para que nos indiquen si hay alguna TX "Z" que ya no se usa, y de esta manera determinar que si requiere y que no, una optimización.

2- Análisis del código ABAP.

La TX SCI puede ayudarnos a encontrar que partes de un programa tienen potencial de mejora para SAP HANA.

Nos presenta una serie de comprobaciones que podemos realizar, y posteriormente nos muestra una lista de mensajes con diferentes prioridades, según la verificación correspondiente.

Se pueden insertar comentarios especiales en el código ABAP para evitar que se emitan mensajes que son falsas alarmas.

NOTA: SAP no permite la inspección de código estándar del sistema mediante el inspector de código.

-> Conceptos básicos:

- Variante de verificación

Define las reglas que se aplicarán, las comprobaciones que se realizarán y la configuración de esas comprobaciones.

- Conjunto de objetos u Objetos set:

Define los objetos de desarrollo que se incluirán.

- Inspección dentro del contexto del inspector del código:

Son las comprobaciones que se deben aplicar al grupo de objetos de desarrollo.

- Diferencia entre variantes de verificación local y global:

Los elementos globales están disponibles para todos los usuarios.

Los elementos locales están ligados a un ID de usuario especifico.

SAP nos proporciona una variante de verificación global con el nombre "DEFAULT".

Esto se usa para los objetos que se verifican en el menú contextual de programas, clases, Módulos de función, etc.

Si creamos una variante con el nombre "DEFAULT" para nuestro usuario, el sistema usara dicha variante en lugar de usar la variante de verificación global.

-> Pasos para usar el inspector de código:

-> TX SCI

-> Asegurarse que la en las variantes de verificación se muestre el icono global.

-> Visualizamos la variante de verificación "DEFAULT"

- Nos muestra cuales son las verificaciones que ejecuta la variante "DEFAULT".

-> Cambiamos de global a local.

-> Creamos una copia de la variante global "DEFAULT".

-> Modificamos la variante que acabamos de crear.

-> Damos clic en Programing Conventions:

- Seleccionamos

-> Naming Conventions.

-> Extended Naming Conventions for Programs.

-> ABAP Unit Test Conventions

-> Guardamos nuestra variante.

-> Al ejecutar un programa vamos al menú:

-> Program.

-> Check.

->Code Inspector.

Nos mostrara una lista de mensajes.

Debemos abrir la categoría que nos indica donde se generaron los mensajes.

2.1 Verificaciones relevantes al migrar a SAP HANA.

Lo principal es asegurarnos que no se presente 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 de ABAP no se requiere hacer algún ajuste en los programas.

-> Native SQL y hints de BD

Una excepción a la afirmación anterior es cualquier parte del código ABAP donde hayamos usado Native SQL.

Toda sentencia de SQL Nativo no va a funcionar despues de la migración a HANA. Para ayudarnos a detectar estas sentencias dentro de nuestros códigos podemos usar las siguientes comprobaciones del inspector de código:

- Interfase ABDC

- Sentencias criticas

-> Comportamiento del SORT.

Debemos utilizar la cláusula "ORDER BY" para devolver la información de manera ordenada, ya que las tablas de la BD HANA son columnares y a diferencia de las BD clásicas donde el ordenamiento se podía dar en base al índice que se usó para la consulta, si no usamos dicha cláusula HANA nos devolverá la información desordenada.

Para recibir la información de manera ordenada debemos especificar la cláusula "ORDER BY" o hacer uso del "SORT" en ABAP.

-> Adiós a las tablas cluster y pool.

Las tablas cluster y pool son convertidas en tablas transparentes al migrar a SAP HANA, dicha conversión es automática y no requiere que hagamos cambios en las aplicaciones o programas que las usan.

Pero debemos tomar en cuenta que si los registros son seleccionados mediante "OPEN SQL" y no se especifica ordenamiento, el usuario no puede confiar en el ordenamiento en base a la clave primaria de la tabla.

Para estos casos se recomienda usar "ORDER BY" en los SELECT o usar SORT una vez almacenado el resultado en tablas internas.

NOTA: Usando la sección "Programación Robusta" del inspector de código podemos detectar sentencias SELECT las cuales no tienen un "ORDER BY".

2.2 Verificaciones relevantes al optimizar para SAP HANA.

Contamos con un amplio rango de verificaciones que podemos correr. Las cuales se basan principalmente en las recomendaciones de performance de "OPEN SQL".

Algunas de estas verificaciones son:

-> Uso inseguro de FOR ALL ENTRIES.

Antes de usar un "FOR ALL ENTRIES" debemos asegurarnos que la tabla interna que usaremos no esté vacía.

-> Buscar las sentencias FOR ALL ENTRIES para transformarlas en uniones.

En muchos casos un join nos da mejor rendimiento sobre el uso de "FOR ALL ENTRIES", por lo que podemos realizar una comprobación las cláusulas "FOR ALL ENTRIES" existentes en los programas ABAP para convertirlas en "Uniones".

-> Declaraciones SELECT que omiten el Buffer de la tabla.

El buffer de la tabla de la BD es seleccionado automáticamente al crear una tabla.

El buffer nos ayuda a evitar una mayor carga de la BD, es por eso que no debemos omitir el buffer.

Con ese fin se realizan las comprobaciones de las instrucciones "SELECT" que ignoran el buffer.

-> Instrucciones problemáticas SELECT *

Debemos evitar consultar columnas innecesarias. Para ello hay una verificación que nos indica en que consultas se estan seleccionando demasiados campos.

Esto hace referencia a verificaciones de existencia, SELECT *, mientras que con el código de retorno SY-SUBRC de la instrucción SELECT es suficiente.

-> Buscando SELECT en LOOPS en subrutinas

Por lo general los problemas de rendimiento de BD son generados por un número de accesos a la BD sucesivos.

-> EXIT/CHECK en SELECT ENDSELECT

Al usar la sentencia SELECT ENDSELECT es posible que una gran cantidad de registros sean leídos innecesariamente, esto es causado por que los datos son transferidos por bloques.

En estos casos debemos usar la sentencia "CHECK" inmediatamente despues del SELECT para indicar que no se usa un filtro hasta que se han leido los datos, estas dos expresiones se pueden convertir frecuentemente en una sentencia "WHERE" adecuada.

NOTA: El uso de la sentencia SELECT ENDSELECT esta totalmente desaconsejada tanto en SAP ECC como EN SAP HANA.

2 Agradecimientos:

Han agradecido este aporte: Martín Gómez Rodríguez, Abraham Noriega Cabrera