1. Introducción al análisis y optimización con SAP HANA
Para optimizar una aplicación para utilizarla con SAP HANA tenemos las siguientes herramientas que nos ayudaran a que nuestro código aproveche la potencialidad del paradigma code pushdown.
- Transacción ST05 (SQL traces): Para poder conocer a que tablas accede un programa y poder determinar por ejemplo, si un SELECT está demorando más tiempo debido a que se está accediendo de forma no optima a la tabla.
- Transacción SAT (Análisis de tiempo de ejecución): La sección "Tips and tricks" de esta transacción nos permite comparar el performance de diferentes sentencias ABAP.
- Transacción SLIN (Verificación ampliada de código): Podemos realizar una verificación estática del código, por ejemplo detectar código que no se utiliza.
- Transacción SCI (Code Inspector): Podemos realizar comprobaciones de performance, seguridad, sintaxis, uso de convenciones de nombre, programación robusta, etc.
- Transacción ATC (ABAP Test Cockpit): Presenta los mismos chequeos que el Code Inspector, sumando una serie de mejoras que hacen que los chequeos de calidad sean más eficientes y completos.
- Transacción STAD: Registros estadísticos que proporcionan una visión general de los tiempos de la base de datos.
- Transacción ST12: Combina las transacciones STAD, SAT y ST05 en una sola interfaz.
- Transacción ST22: Análisis de errores en tiempo de ejecución.
A partir de ABAP 7.4 tenemos algunas herramientas nuevas:
- Transacción SQLM (Monitor SQL): Supervisa el sistema de producción y proporciona datos valiosos de optimización del rendimiento. El monitor SQL recopila, agrega y persiste la información en tiempo de ejecución sobre las sentencias SQL. 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 disponibles en el monitor SQL.
- Transacción SWLT (SQL Performance Tunning WorkList Tool): Lo podemos utilizar para combinar los datos del Monitor SQL con los resultados del análisis del código y por lo tanto, hacer planes para lograr una optimización valiosa.
2. El análisis del código ABAP
El Code inspector (transacción SCI) es una herramienta que se utiliza para comprobar los objetos del repositorio. Podemos chequear objetos individuales o conjuntos de objetos para verificar el rendimiento, la seguridad, la sintaxis y el cumplimiento de las convenciones de nombres.
Podemos definir inspecciones que con la ayuda de variantes de verificación, examinen ciertos conjuntos de objetos. Como resultado de una inspección, recibimos mensajes de información, mensajes de advertencia o mensajes de error en diferentes propiedades de los objetos examinados.
- Variante de verificación: Define las reglas que se aplicaran, las comprobaciones que se realizaran y la configuración de esas comprobaciones.
Globales: Están disponibles para todos los usuarios.
Locales: Están asociados directamente con un usuario especifico.
SAP proporciona una variante de verificación global con el nombre DEFAULT.
- Conjunto de objetos: Define los objetos de desarrollo que se incluirán.
- Inspección: Define una combinación de variantes de verificación y conjuntos de objetos, en otras palabras, que comprobaciones deben aplicarse a que objetos de desarrollo.
2.1. Las verificaciones relevantes al migrar a SAP HANA
- Native SQL y hints de 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. Estas sentencias son propias del SQL Nativo de Oracle y no funcionaran más con SAP HANA. Para encontrar estas sentencias podemos utilizar las siguientes comprobaciones del Code Inspector: Uso de la interfase ADBC y Sentencias Criticas.
- Comportamiento del SORT: En las tablas columnares si no especificamos el ORDER BY, la base de datos devolverá los registros de datos desordenados, por lo que usar esta cláusula es necesaria, o también podemos usar SORT. En la categoría Programación Robusta del Code Inspector tenemos un check para encontrar los SELECT sin ORDER BY.
- Adiós a las tablas cluster y pool: Cuando se migra a SAP HANA, las tablas cluster y pool son convertidas a tablas transparentes.
2.2. Las verificaciones relevantes al optimizar para SAP HANA
- Uso inseguro de FOR ALL ENTRIES: La tabla interna que se utiliza en esta sentencia nunca debe estar vacía, ya que de lo contrario todos los registros de la tabla de base de datos serán leídos.
- Transformar las sentencias FOR ALL ENTRIES en JOINS: En muchos casos, un JOIN ofrece ventajas de rendimiento adicionales sobre el FOR ALL ENTRIES.
- Declaraciones SELECT que omiten el Buffer de tabla: El buffer de tabla base de datos que se tilda al crear la tabla todavía juega un papel importante cuando se usa SAP HANA. Para evitar una mayor carga de la base de datos, no debemos omitir este buffer si se ha activado 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 que no se necesiten.
- SELECTs en Loops: Existe una verificación que encuentra sentencias SELECT que se ejecutan en Loops.
- Exit/Check en Select... Endselect: Si utilizamos EXIT para salir de un Select...Endselect, es posible que una gran cantidad de registros 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 de la instrucción SELECT de modo de indicar que no se usa un filtro hasta que se han leído los datos.