🚀PROMO #PLANCARRERA2024 - 🔥Bonificaciones, Precios Congelados y Cuotas

 X 

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

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

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 desarrollar una nueva aplicación ABAP y optimizar una aplicación existente para utilizar con SAP HANA, es necesario adoptar un nuevo enfoque y utilizar nuevas herramientas de análisis de tiempos de ejecución y error disponibles. Para realizar la optimización de los códigos ABAP existentes o generar desde cero códigos ABAP performances, que aprovechen al máximo la potencialidad que presenta el paradigma pushdown.

Herramientas que se pueden utilizar:

- 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 de 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 famoseos transacción SE30 a través de la cual realizábamos análisis en tiempo de ejecución. La sección Tips&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 e código generado a través del inspector de código 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 estadisticos mediante la transacción STAD: que nos porporciona una visión genera 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 general que combina transacciones STAT, SAT y ST05 en una sola interfaz.

- El análisis de errores en tiempos 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 muy útiles:

- 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 se 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 son 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 los tanto, hacer planes para lograr una optimización valiosa.

2. Análisis del código ABAP.

El inspector de código (transacción SCI) puede ayudarnos a identificar aquelas 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¨.

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 a 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 al ayuda del 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.

Debemos conocer los siguientes conceptos:

- 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?

Define los objetos de desarrollo que se incluirán.

- Qué es una inspección en el contexto de inspector de código?

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 de código ABAP, no es necesario 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 SLECT 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 ABP podemos utilizar las siguientes comprobaciones del inspector de código: Uso de la Interfase ADBC y sentencias Críticas.

- Comportamiento del SORT.

El comportamiento del ordenamiento de los registros recuperados de las tablas base de datos luego de un SELECT puede requerir adaptaciones, particularmente si no especificamos un ordenamiento explícito en el código del programa, 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 utilizábamos 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 desabamos 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 necesariamente usar la adición ORDER BY o, posteriormente, ordenar en el programa ABAP usando SORT.

- Adios a las tablas cluster y pool

Cuando se migra la base de datos SAP HANA, los 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 se recomienda tal como mencionamos anteriormente siempre especificar el ordenamiento con ORDER BY en el SELECT o con SORT luego de almacenados los registros en unta 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 representan SELCT-s sin ORDER BY.¨.

2.2 Verificaciones relevantes al Optimizar para SAP HANA.

Para identificar el potencial de optimización en el contexto de los accesos a la 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 Open SQL.

Análisis de algunas 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 muchos 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 convertirse en uniones.

- Declaraciones SELECT que omiten el buffer de tabla.

El bufar de tabla base de datos que se tilda al crear la tabla todavía juega un papel importante cuando se usa SAP HANA combase de datos.

Para evitar una mayor carga de la base de datos, no debemos omitir este buffer si se ha activado en 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 necesiten.

Para este fin, hay una verificación disponible para encontrar sentencias SELEC 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 el código de retorno SY-SUBRC de la instrucción SELECT es suficiente.

- Buscando SELECTs en LOOPS de 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 loop.

Hay una serie de controles que pueden encontrar esos loops.

En particular, incluyen una verificación que encuentra sentencias SELECT que se ejecutara 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 ... ENDSLECT, 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 este 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 reemplazar por SELECT SINGLE o SELECT INTO TABLE según el caso.

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

Podemos configurar variantes de verificación en la transacción SCI correspondiente al inspector de código, SAP nos proporciona un rango de variantes por defecto. Una variante muy útil es la performance DB disponible a partir de ABAP 7.4.

Además se cede definir variantes de verificación para un usuario del sistema o para todos globalmente para todos los usuarios para cuando se trabajo con un equipo de trabajo de modo que todos los programadores ejecutar la misma variante de verificación para todos los programas.


 

 

 


Sobre el autor

Publicación académica de Miguel Angel Acosta Acosta, en su ámbito de estudios para el Máster ABAP for HANA.

SAP Expert


Miguel Angel Acosta Acosta

Profesión: Ingeniero de Sistemas - Ecuador - Legajo: TF64C

✒️Autor de: 238 Publicaciones Académicas

🎓Egresado de los módulos:

Disponibilidad Laboral: FullTime

Presentación:

Profesional de ingeniería de sistemas en computación e informática, con experiencia en la implantación y soporte de proyectos informáticos para empresas del sector industrial y financiero.

Certificación Académica de Miguel Acosta