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

Lección 3: Análisis y optimización con SAP HANA

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

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

Para ello contamos con herramientas de análisis en tiempo de ejecución y error disponibles:

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

La memoria caché de SQL en la BD proporciona información específica de la BD sobre la declaración SQL, por ejemplo, la cantidad de paginas 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 la llamada en el que se ejecuto la declaración, se encuentran disponibles 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 SQL.

NOTA: Previo al momento de realizar la migración a SAP HANA, resulta indispensable analizar que 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 mas de 5 años por lo que allí abra que determinar que parámetro se toma para decir si optimizar o no una transacción o programa.

CAP 2. Análisis del código ABAP

El inspector de código (Tx 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.

Después 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.

NOTA: SAP no permite escanear el código estándar de sistema con el inspector de código.

NOTA: El inspector de código es una herramienta que se utiliza para comprobar los objetos del repositorio. Usando el inspector de código, podemos chequear objetos individuales o conjuntos de objetos para verificar el rendimiento, la seguridad, la sintaxis y el cumplimiento de las convenciones de nombres.

En el inspector de código podemos definir inspecciones que, con la ayuda de check variant ( variantes de verificaciones), 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.

Debemos conocer los siguientes conceptos básicos:

¿Qué es una Variante de verificación?

Una variante de verificación define las reglas que se aplicarán, las comprobaciones que se realizarán y la configuración de esas comprobaciones.

¿Qué es un conjunto de objetos o Object set?

Un conjunto de objetos o Object set define los objetos de desarrollo que se incluirán.

¿Qué es una Inspección en el contexto del inspector de código?

Una Inspección define una combinación de Variantes de comprobación y Conjuntos de objetos, en otras palabras, qué comprobaciones deben aplicarse a qué objetos de desarrollo.

¿Cuál es la diferencia entre las variantes de verificaciones locales y globales?

Los elementos globales están disponibles para todos los usuarios. Los elementos locales están asociados directamente con un ID de usuario específico. SAP proporciona una Variante de verificación global con el nombre "DEFAULT". Esto se utiliza para los objetos que se verifican en el menú contextual de programas, Clases, Módulos de función, etc.

Para nuestro nombre de usuario, si creamos una variante de verificación local con el nombre DEFAULT, el sistema usará esto en lugar de la variante de verificación global.

2.1 – 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.

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 BD.

NOTA: en las implementaciones de SAP donde se utiliza como BD 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 de SQL Nativo de Oracle y no funcionaran después 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 interface ADBC y Sentencias Críticas.

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

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

En las BD clásicas, 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 más bien una coincidencia, y no había garantías para esta clasificación. Para una programación estable, teníamos que especificar la adición ORDER BY si queríamos que los datos nos viniesen ordenados.

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

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

SELECT * FROM mara

INTO TABLE ti_mara

ORDER BY matnr DESCENDING.

NOTA: Podemos usar la opción de verificación del inspector de código ABAP buscar enunciados problemáticos para resultados 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.

Cuando se migra la BD 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).

NOTA: en la categoría Programación Robusta del inspector de código tenemos disponible un CHECK para ayudar a encontrar las partes de los programas ABAP que presentan SELECT sin ORDER BY.

2.2 – Verificaciones relevantes el Optimizar para SAP HANA

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

Vemos algunas de estas verificaciones:

Por una cuestión de mejor perfomance 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 perfomance.

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 BD serán leídos. Por eso, antes de ejecutar la sentencia FOR ALL ENTRIES debemos chequear que la tabla interna no se encuentre vacía.

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

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

El buffer de tabla de BD que se tilda al crear la tabla, todavía juega un papel importante cuando se usa en SAP HANA como BD.

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

Debemos realizar una comprobación en las instrucciones SELECT que ignoran el Buffer.

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

Para esto 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.

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 verificación que encuentra sentencias SELECT que se ejecutan en LOOPS.

A partir de la 7.4 las búsquedas también pueden extenderse más allá de las subrutinas.

Si utilizamos la sentencia EXIT para salir de un SELECT ENDSELECT, es posible que una gran cantidad de registro de datos se lean innecesariamente y esto se debe a que los datos se transfieren en bloque.

En este caso debemos utilizar la sentencia CHECK inmediatamente después de 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.

NOTA: en SAP ECC, desde el punto de vista de la perfomance, la utilización de la sentencia SELECT ENDSELECT estaba desaconsejada y se recomendaba 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 BD.

NOTA: Podemos configurar variantes de verificación en la Tx SCI correspondiente al inspector de código.

SAP nos proporciona un rango de variantes por defecto. Una variante muy útil es 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 que todos los programadores ejecuten la misma variante del inspector de código para la comprobación de los programas.