Analisis y Optimizaion con SAP HANA
- Realizar traces de SQL a través de la trx ST05: para poder conocer a que tablas BD accede un programa de modo de poder determinar por ejemplo, si un SELECT está demorando mas tiempo de lo que deberia debido a que se está accediendo de forma no óptima a una taba BD.
- El análisis de tiempo de ejecución de ABAP mediante la trx SAT: esta trx es la evolucion de la famosa trx SE30 a través de la cual se realizaba el análisis en tiempo de ejecución. La seccion "Tips and Tricks" de esta transaccion permite comparar la performance de diferentes sentencias ABAP.
- La verificacion ampliada de codigo a través de la transaccion SLIN: mediante la cual se realiza una verificacion estática del codigo y permite detectar entre otras cuestiones muy valiosas, el codigo existente que no se utiliza.
- Chequear el código generado a través del Inspector de código de SAP con la transaccion SCI: con el cual se puede realizar comprobaciones de performance, seguridad, sintaxis, uso de convenciones de nombre, programacion dobusta. etc.
- El ABAP test Cockpit correspondiente a la transaccion ATC: es la evolucion del inspector de código. Presenta los mismos chequeos que la transaccion SCI. sumado a una serie de mejoras que hacen que los chequeos de calidad de nuestras aplicaciones sean más eficientes y completos.
- La utilizacion de los registros estadísticos mediante la transaccion STAD: que proporcionan una vision general simple de los tiempos de la BD y son un punto de partida útil.
- El Análisis de transacciones individuales a través de la trx ST12: la cual es una herramienta especial que combina trx STAD, SAT y ST05 en una sola interfaz.
- El análsis de errores en tiempo de ejecucion mediante la trx ST22: que proporciona informacion valiosa para solucionar el problema que origino el dump.
A partir de ABAP 7.4 se tiene algunas herramientas nuevas y muy útiles:
- El Monitor SQL a través de la transaccion SQLM: supervisa el sistema de produccion y proporciona datos valiosos de optimizacion del rendimiento. El monitor SQL basicamente recopila, agrega y persiste la informacion en tiempo de ejecucion sobre las sentencias de SQL en la interfaz de la BD.
La memoria caché de SQL en la BD proporciona informacion especifica de la BD sobre la declaracion SQL (por ejemplo, la cantidad de paginas leídas o los tiempos de E/S y CPU requeridos). Estos datos junto con informacion sobre el programa ABAP y el contexto de llamada en el que se ejcutó la declaracion, se encuentran disponible en el monitor SQL.
En Consecuenciam estas dos fuentes de datos se complementan entre si y proporcionan informacion adicional especifica sobre las sentencias de SQL.
- El SQL Performance Tunning WorkList Tool mediante la trx SWLT: el cual podemos utilizar para combinar los datos del monitor de SQL con los resultados de análisis del código y por lo tanto, hacer planes para lograr una optimizacion valiosa.
Previo al momento de realizar la migracion a SAP HANA es indispensable analizar que de todo el codigo Z existente en el sistema SAP es realmente utilizado, esto se debe a que realizar la adaptacion de los programas ABAP para SAP HANA requerie un gran esfuerzo el cual se puede ver bastante reducido si solo se optimiza los programas que actualmente solo se utilizan en el ambiente productivo. Para analizar el uso de las transacciones y programas existentes en el ambiente productivo se cuenta con transacciones estandar del sistema que son propias de los administradores del sistema SAP o SAP BASIS. Es probable que mucho de los programas Z o trx existentes en produccion no se usen por mucho tiempo por lo que se deberá determinar que parametro se toma para decidir si optimizar o no una trx o programa.
Analisis del código ABAP
El inspector de código (trx SCI) puede ayudar a identificar aquellas partes del programa que tienen potencial de mejora para SAP HANA.
Presenta una serie de comprobacones que podemos realizar en los objetos de desarrollo.
Luego de ejecutar, se recibirá 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 codigo ABAP para evitar que se emita un mensaje.
SAP no permite escanear el código estándar del sistema con el inspector de codigo.
Usando el inspector de codigo, podemos chequear objetos individuales o conjuntos de objetos para verificar el rendimiento, la seguridad, la sintaxis y el cumplimiento de las conveciones de nombres.
En el inspector de código, se puede definir inspecciones que, con la ayuda de check variant (variante de verificaciones), examinen ciertos conjuntos de objetos.
Como resultado de una inspeccion, recibimos mensajes de información, mensajes de advertenciam o mensajes de error en diferentes propiedades de los objetos examinados.
Se debe conocer los siguientes conceptos:
Variantes de verificacion: define las reglas que se aplicarán, las comprobaciones que se realizarán y la configuracion de esas comprobaciones.
Conjunto de Objetos o Object Set: define los objetos de desarrollo que se incluiran.
Inspeccion en el contexto del inspector de codigo: define una combinacion de variantes de comprobacion y conjuntos de objetos, en otras palabras que comprobaciones deben aplicarse a qué objetos de desarrollo.
Los elementos globales estan disponibles para todos los usuarios.
Los elementos locales están asociados directamente con un ID de usuario específico.
SAP proporciona una variante de verificacion global con el nombre DEFAULT.
Esto se utiliza para los objetos que se verifican en el menú contextual de programas, clases, modulos de funcion, etc.
Para el nombre de usuario, si se crea una variante de verificacion local con el nombre DEFAULT, el sistema usará esto en lugar de la variante de verificacion global
Verificaciones relevantes al migrar a SAP HANA
Durante la migracion a SAP HANA, la principal prioridad es asegurarse que no se experimente ningun contratiempo funcional, incluidas las cancelaciones de programas dumps y los cambios no deseados en el comportamiento de una aplicacion.
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 BD: una excepcion a la afirmacion que se acaba de realizar es cualquier parte de un programa ABAP en el que se haya utilizado implementaciones de BD, es decir programas en los que se utiliza SQL nativo de la BD.
En las implementaciones de SAP donde se utiliza como BD a Oracle es común encontrarse con las sentencias HINTS en los SELCT para forzar la utilizacion de los índices de las tablas.
Se debe tener en cuenta que estas sentencias son propias del SQL Native de Oracle y no funcionarán más luego de la migracion a SAP HANA.
Para ayudar a localizar estos códios dentro de los programas ABAP se puede utilizar las siguientes comprobaciones del inspector de codigo: uso de la interfase ADBC y Sentencias Criticas.
Comportamiento del SORT: el comportamiento del ordenamiento de los registros recuperados de las tablas BD luego de un SELECT puede requerir adaptaciones, particularmente si no especificamos un ordenamiento explícito en el codigo del programa ABAP, por ejemplo usando ORDER BY o SORT.
Tener presente que en las tablas BD columnares si no se especifica la cláusula ORDER BY, la BD devolverá los registros de datos desordenados
En las bases de datos clásicas, que hara ahora se utilizan, la secuencia del ordenamiento podía tener que ver con un índice de la BD que se usó para la consulta.
Sin embargo, esto era mas bien una coincidencia, y no había ninguna garantía para esta clasificación. Para una programacion estable, se tenia que especificar la adicion ORDER BY si se deseaba que los registros regresen ordenados.
En SAP HANA, hay muchos menos índices de BD, y la mayoria de ellos difieren de los de las BD clásicas.
Para recibir los datos de lectura en la secuencia deseada se debe usar si o si la adición ORDER BY o posteriormente ordenar en el programa ABAP usando SORT.
Se puede usar la opcion de verificacion del inspector de codigo ABAP "buscar enunciados problematicos para resultado de SELECT OPEN CURSOR sin ORDER BY para encontrar aquellas partes del programa para las cuales se procesa un conjunto de resultado que requere una clasificacion, por ejemplo en una busqueda ordinaria usando un comando ABAP y por la cual no se puede determinar una clasificacion en el programa a traves de un ORDER BY o SORT.
- Adios a las tablas cluster y pool: Cuando se migra la BD a SAP HANA, las tablas cluster y poll son convertidas a tablas transparentes. Esta conversión es automática y no involucra que se realice cambios a las aplicaciones que la utilizan.
Sin embargo se debe tener en cuenta que cuando los registros son seleccionados con OPEN SQL sin especificar un ordenamiento determinado, segun SAP el usuario no puede confiar en el ordenamiento (de acuerdo a la clave primaria de la tabla).
En este caso SAP recomienda siempre especificar el ordenamiento con ORDER BY en el SELECT o con SORT luego de almacenados los registros en una tabla interna.
En la categoria Programacion Robusta del inspector de código se tiene disponible un check para ayudar a encontrar las partes de los programas ABAP que presentan SELECTs sin ORDER BY.
Verificaciones relevantes al optimizar para SAP HANA
- Uso inseguro de FOR ALL ENTRIES: por un mejor performance, se utiliza FOR ALL ENTRIES o un JOIN en lugar de realizar un SELECT anidado, es decir un SELECT dentro de otro SELECT, lo que resulta catastrofico desde el punto de vista de la performance.
Ahora bien, si se utiliza FOR ALL ENTRIES se debe tener presentte que la tabla interna que se utiliza en la sentencia nunca debe estar vacia, ya que de lo contrario todos los registros de la tabla serán leídos
Es por ello que siempre antes de ejecutar la sentencia FOR ALL ENTRIES se debe chequear que la tabla interna no se encuentre vacia.
- Buscar las sentencias FOR ALL ENTRIES para transformarlas en uniones: un JOIN ofrece ventajas de rendimiento adicionales sobre la cláusula FOR ALL ENTRIES. Por este motivo, se puede realizar una comprobacion 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 la tabla BD que se tilda al crear la tabla todavia juega un papel importante cuando se usa SAP HANA como BD.
Para evitar una mayor carga de la BD, no se debe omitir este buffer si se ha activado el buffer para una tabla.
Para este fin, se debe realizar una comprobacion en las instrucciones SELECT que ingoran el buffer.
- Instrucciones problematicas SELECT *: Se debe evitar leer las columnas de las tablas bd que no se necesitan.
Para este fin, hay una verificacion 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 cofigo de retorno SY-SUBRC de la instruccion 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 BD, 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 verificacion que encuentran sentencias SELECT que se ejecutan en Loops.
A partir de AS ABAP 7.4, las busquedas tambien pueden extenderse mas alla de las subrutinas, cuestion que anteriormente no era posible.
- EXIT/CHECK en SELECT...ENDSELECT: si se usa 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 se debe usar la sentencia CHECK inmediatamente luego a la instruccion 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 adecuada.
En SAP ECC desde el punto de vista de la performance, la utilizacion de la sentencia SELECT...ENDSELECT estaba totalmente desaconsejada y se sugería reemplazarla or 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.
Se puede configurar variantes de verificacion en la transaccion SCI correspondiente al inspector de codigo. SAP nos proporciona un rango de variantes por defecto. Una variante muy util es la Variante Performance DB la cual se encuentra disponible a partir de ABAP 7.4. Tambien se puede definir variante de comprobacion personalizadas seleccionando y configurando las comprobaciones adecuadas desde el arbol de directorio, ademas se puede definir variante de verificacion especificamente para un usuario del sistema o globalmente para todos los usuarios del sistema, esto es muy util si se trabaja dentro de un pool de programador de modo que todos los programadores usen la misma variante del inspector de codigo para la comprobacion de los programas.