✒️ABAP HANA / Las recomendaciones para desarrollar aplicaciones ABAP en SAP HANA Por Lucero Tapia Cruz

Recomendaciones generales:

Detalles a considerar en la migración y optimización de programas ABAP

- Almacenamiento por columnas VS almacenamiento por filas: cuando creamos una tabla de BD por default se crea con almacenamiento por columnas, pero se puede elegir cualquiera de los 2 tipos de almacenamiento. Se pueden analizar grandes conjuntos de datos con el almacenamiento por columnas, SAP recomienda que se configuren todas las BD con el almacenamiento columnar

Las tablas que contienen datos de aplicación se almacenan por columnas, también se debe aplicar a las tablas que se utilizan para búsquedas de texto.

Motivos para utilizar almacenamiento por fila(tablas pequeñas o volátiles) si se accede a una tabla predominantemente mediante declaración DML, update insert o delete. Las tablas técnicas de SAP son elegibles a almacenamiento por filas: ejemplo tablas para procesamiento de actualización correspondientes al paquete STSK. A estas tablas se accede con SELECT SINGLE.

* Para configurar en la se11 el tipo de almacenamiento de una tabla seleccionar el botón "Opciones Técnicas", pestaña "Propiedades especificas de la BD"

- Implementación específica de SAP HANA

1.- Implementaciones independientes de la BD: utilizando Open SQL y ABAP CDS

2.- Implementaciones que utilizan funciones específicas de SAP HANA: SQL nativo y HANA CDS.

Pautas para implementación específica

- Primero Open y luego Native: Preferiblemente debemos utilizar vistas de OPEN SQL y CDS antes de implementar SQL Nativo, vistas de SAP HANA o procedimientos de BD. El servidor de aplicación ABAP no necesita usuario adicional para la BD se SAP HANA.

- Primero ABAP CDS y luego HANA CDS: Debemos utilizar los procedimientos de la BD ABAP en lugar de los de la BD SAP HANA. Se pueden sincronizar fácilmente los procedimientos de BD ABAP con otros objetos ABAP y transportarlos.

RECOMENDACIONES PARA LA MIGRACIÓN

- Código ABAP dependiente de la BD: Debemos ajustarlo para la BD SAP HANA si es necesario. Es el caso de la utilización SQL nativo a través de la declaración EXEC SQL o los HINTS ORACLE de BD

- Conversión tablas de pool y cluster: Al convertir estas tablas en transparentes se pierde el ordenamiento, por lo que debe analizarse su acceso con respecto al ordenamiento en la migración.

* El code inspector proporciona la verificación Find select for pool/cluster Tab without ORDER BY para encontrar rápidamente estos puntos críticos.

- Comportamiento del ordenamiento: Sino especificamos ORDER BY la secuencia en la que se leen los registros de la tabla BD es impredecible. Con SAP HANA el ordenamiento implicito no está garantizado ya que no es una característica documentada de Open SQL. Por lo que se debe utilizar la adición ORDER BY. La opción BINARY SEARCH requiere de la tabla interna ordenada

Recomendaciones de performance: Velocidad de ejecución de los programas. Una compresión sólida de las pautas y técnicas para lograr un rendimiento óptimo Reglas de oro para la programación de BD:

1.- Mantener el conjunto de resultados lo más pequeño posible: El número de filas seleccionadas debe ser reducido al leer datos de la BD, para lo cual se deben utilizar varias medida:

- Cláusula WHERE: Debemos leer los registros realmente necesarios

- Cláusula HAVING: Otra opción para reducir filas seleccionadas. Se usa junto con la cláusula GROUP BY para seleccionar solo ciertos grupos haciendo restricciones a las filas agrupadas.

- Transferir sólo filas requeridas. Transferir sólo los registros necesarios, ya que no se deben eliminar del servidor de aplicaciones los datos que no se ocupan( no se debería ocupar un DELETE WHERE después del SELECT ). La sentencia CHECK o el filtrado IF-ENDIF también pueden indicar la transferencia de demasiadas filas.

*REGLA 1 para SAP HANA Menor esfuerzo de E/S, un consumo de memoria optimizado en el caché, un menor consumo de CPU y una transferencia de red optimizada para que se transfieran menos datos.

2.- Mantener el conjunto de datos transferido lo más pequeño posible. Transferir la menor cantidad de datos posible entre la base y el servidor de aplicaciones. La carga de red se puede reducir transfiriendo menos bloques.

- Usar adición UP TO n ROWS: Usar si sólo se necesitan un cierto número de filas.

- DISTINCT: Se usa para eliminar las entradas duplicadas que ya se encuentran en la BD.

- Reducir número de columnas: Seleccionar solo as columnas de una tabla de BD que sean necesarias. La selección mediante SELECT * solo se deben realizar si todas las columnas son realmente necesarias.

- Funciones de agregación: Es mejor realizar cálculos en la base de datos y transferir os resultados, en lugar de transferir los datos y realizar el cálculo en el programa. (COUNT, MIN valor mínimo, MAX valor máximo, SUM suma de los valores, AVG valor promedio). SELECT SUM( seatsocc ) FROM sflight...

- Realizar chequeos de existencia eficientemente: Para determinar si hay un registro de datos para una clave específia, no debemos usar SELECT COUNT(*) porque el número es irrelevante en este caso. El conjunto de resultados se debe restringir a una fila con UP TO n ROWS.

- Modificar sólo las columnas necesarias: Para realizar cambios con la instrucción UPDATE, solo las columnas deseadas deben cambiarse con la instrucción SET.

* Regla 2 para SAP HANA

Si los registros de datos se almacenan en el almacenamiento orientado a columnas, cada columna es una estructura de almacenamiento separada.

3.- Reducir el número de ejecuciones de consulta:

Cada declaración SQL en un programa ABAP que se envía a la BD implica un cierto grado de esfuerzo en la BD. Para reducir la carga en la BD se debe mantener e número de accesos lo más bajo posible mediante las siguientes medidas:

- Usando operaciones de conjunto en lugar de operaciones individuales: al leer con SELECT se debe usar la adición INTO TABLE en lugar de SELECT... ENDSELECT, si todos los datos caben en la memoria principal.

SELECT...ENDSELECT es útil si la memoria es insuficiente para todos los datos o si solo se accede a los datos leídos una vez.

Para insertar datos en una tabla no se debe hacer registro por registro, sino insertar el conjunto de registros en una sola operación: INSERT sbook from table lt_sbook.

- No realizar más acceso múltiples: Evitar usar un SELECT ante de un DELETE para el mismo registro de datos. Realizar una operación DELETE sin una instrucción SELECT precedente.

- No usar bucles con SELECT anidados.Para usar conjuntos de datos se recomienda usar:

Joins o uniones, Vistas, FOR ALL ENTRIES.

No usar: SELECT... SELECT.... ENDSELECT. ENDSELECT.

Usar: SELECT.. INNER JOIN.

- No ejecutar instrucciones SELECT en el LOOP a través de tablas internas: La adición FOR ALL ENTRIES es útil para reducir el número de ejecuciones. Pero debemos asegurarnos que la tabla interna nunca este vacía y no contenga duplicados.

- Utilizando buffers. Contribuyen a minimizar el número de declaraciones SQL que se envían a la BD

* Regla 3 para SAP HANA

Consumo reducido de CPU para la BD, los recursos de red también se utilizan de una mejor manera porque se puede optimizar la cantidad de bloques enviados.

4.- Minimizar el esfuerzo de búsqueda. Se puede minimizar el esfuerzo de la BD con un índice

- Índices de BD en BD clásicas: Consta de campos seleccionados de la BD que se copian en una secuencia ordenada en una estructura separada. Existen primarios y secundarios.

Primario: Contiene los campos de clave principal, el índice es único y sólo puede haber un registro para cualquier combinación. Estos se crean automáticamente en los sistemas cuando se crea una tabla

Secundarios: Pueden ser únicos o no. Se crean en el DDIC. Se usan para optimizar el rendimiento, por ejemplo, solo los valores únicos pueden estar en una columna que no forma parte de la clave principal.

* La formulación correcta de las cláusulas WHERE o HAVING y una definición de índice secundario adecuada puede minimizar el esfuerzo de búsqueda.

RECOMENDACIONES PARA CREAR ÍNDICES:

- Crear para tablas de BD donde los accesos de lectura son más críticos. en el tiempo de accesos de escritura.

- El número de índices y campos creados en el índice debe mantenerse lo más pequeño posible. De o contrario se requiere más esfuerzo para cambiar el accesos a la BD.

- Los campos en los que se crean los índices solo deben estar en un índice si es posible.

- Los campos en un índice secundario deben ser campos a través de los cuales selecciona a menudo. Los campos deben ser selectivos; el porcentaje de registros de datos seleccionados por el índice debe ser pequeño

- Los campos que tienen mayor probabilidades de ser consultados con el operador = deben estar al principio del índice.

* En el WHERE se debe usar EQ, IN, siempre que sea posible. Evitar en el WHERE las condiciones NE; incluir la sección inicial del índice en la condición WHERE.

Indices de la base de datos SAP HANA: Con SAP HANA, distinguimos entre índices invertidos y compuestos.

Los índices compuestos tienen un requisito de memoria más alto, por lo que se recomienda trabajar lo más posible con los índices invertidos. Se debe crear un índice en cada caso para la columna que tenga la condición más selectiva. Los indices compuestos deben crearse en casos excepcionales.

El mantenimiento de los índices también aumenta los costos de acceso de escritura en SAP HANA, pero son menores en los índices invertidos

Al migrar un sistema existente a SAP HANA ya no se crean todos los índices secundarios existentes para las tablas configuradas con almacenamiento por columnas.

* Regla 4 para SAP HANA:

Optimiza el consumo de memoria en el caché, reduce el consumo de cpu y optimiza la transferencia de red porque se transfieren menos datos para la BD clásica

En SAP HANA su cumplimiento tiene una prioridad más baja porque en muchos casos no se requiere ningún índice. El consumo de CPU se reduce por el índice y generalmente se crean para la columnas individuales. Los índices que abarcan varias columnas son la excepción.

5.- Reducir la carga en la BD.

Mantener la carga de operaciones repetidas en la BD lo más pequeña posible.

Medidas que contribuyen a reducir la carga en la BD

- Buffers :

están disponibles los siguientes buffers cross usuario en el servidor de aplicaciones.

• Objetos compartidos
• Buffer compartido
• Memoria compartida
• Buffer de tabla

Los buffer específicos de usuario también están disponibles dentro de una sesión de usuario:

• Memoria SAP
• Memoria ABAP
• Programación específica del buffering en tablas internas

El acceso al buffer en el servidor de aplicaciones es aún más rápido (10 veces ) que acceder a la BD.

- Ordenando: Si el ordenamiento es parte del cálculo o se puede realizar de manera no muy costosa en la BD, también debe realizarse en la BD

- Evitar accesos idénticos: Reduce el número de accesos a la BD y evita cargas innecesarias en la BD.

* Regla 5

Los buffers en el servidor de aplicaciones siguen estando justificados porque ofrecen tiempos de acceso más rápidos y pueden aliviar la BD de accesos innecesarios. Si un resultado debe consultarse varias veces, debe almacenarse en un buffer