Recomendaciones para desarrollar en SAP HANA.
1.- Tips prácticos importantes al desarrollar aplicaciones ABAP HANA.
- Recomendaciones generales: proporcionaremos algunas recomendaciones generales para el desarrollo de ABAP ene SAP HANA. Principalmente presentaremos los detalles que debemos considerar para la migración y optimización de los programas ABAP
- Pautas de performance: La velocidad de ejecución de los programas, naturalmente, desempeña un papel crucial en el contexto ABAP.
Muchos escenarios de uso implican el acceso a grandes conjuntos de datos en tiempo real.
2.- Recomendaciones generales.
Hemos recopilado algunas recomendaciones generales que debemos seguir para realizar la migración y el desarrollo en SAP.
2.1- Almacenamiento por columnas Vs Almacenamiento por filas.
En SAP HANA por defecto las tablas se crean con almacenamiento por columnas, esto es recomendable, siempre que no haya una razón específica para almacenarlas por filas.
Las tablas que contienen datos de la aplicación siempre se almacenan por columnas porque es muy probable que estos datos también se utilicen en escenarios de análisis.
Esto se aplica particularmente a las tablas que contienen una gran cantidad de registros de datos porque el almacenamiento por columnas proporciona mejores propiedades de compresión.
Esto también se aplica a las tablas que se utilizan para búsquedas de texto.
"Las tabas técnicas de SAP son elegibles para un almacenamiento por filas, tablas para el procesamiento STSK, o para llamadas a RFC correspondiente al paquete SRFC".
Conclusiones con respecto al almacenamiento por filas y por columnas.
- Ambos enfoques tienen ventajas y desventajas
- Los datos comerciales casi siempre se colocan en el almacenamiento basado en columnas.
- Algunas tablas requieren almacenamiento de datos basado en filas, por ejemplo las tablas técnicas de SAP.
- Son principalmente tablas muy pequeñas o muy volátiles, donde el tiempo requerido para los accesos de escritura es más importante que el tiempo requerido para los accesos de lectura.
- O en tablas donde los accesos de un solo registro ( a través del comando SELECT SINGLE) son el patrón de acceso principal.
Compresión de los datos.
Técnicas de compresión de SAP HANA.
La alta compresión reduce la cantidad de datos que deben transferirse desde la memoria principal a la CPU.
Esto se aplica particularmente si necesitamos analizar grandes cantidades de datos.
Algunas tablas requieren almacenamiento de datos basado en filas.
- Para almacenar el contenido de una columna en el almacenamiento por columnas, de la base de datos de SAP HANA crea un mínimo de dos estructuras de datos:
- Vector de diccionario
- Vector de atributo.
El vector de diccionario almacena cada valor de una columna solo un vez.
Los contenidos del vector de diccionario se almacenan como datos ordenados, asigna cada valor a un entero, debido a que se almacena en orden, no se requiere almacenamiento adicional.
El vector de atributos solo almacena solo los enteros.
2.2 Implementaciones específicas de SAP HANA.
En el desarrollo de ABAP en SAP HANA, debemos distinguir dos escenarios:
- Implementaciones independientes de la base de datos: por ejemplo Open SQL y ABAP CDS.
- Implementaciones que utilizan funciones específicas de SAP HANA: por ejemplo, SQL nativo y HANA CDS.
En el primer caso, no tenemos que considerar nada especial desde la perspectiva de la logística del software.
Utilizamos SAP HANA como cualquier otra base de datos, pero nos beneficiamos directamente de la alta velocidad de procesamiento de SAP HANA en muchos escenarios.
Nuestros desarrollos son ejecutables entonos los sistemas de bases de datos soportados por SAP.
Al usar funciones nativas de SAP HANA, inicialmente se aplican las mismas implicaciones que las habituales si definimos partes de una aplicación específicamente para un sistema de base de datos (por ejemplo, a través de SQL nativo, Hints Otras técnicas).
Para la optimización de rendimiento de un aplicación BAP existente, es recomendable que procedamos inicialmente utilizando herramientas estándar.
Las siguientes pautas nos proporcionan ayuda en este punto:
- Primero Open y luego Native.
Preferiblemente debemos utilizar las vistas Open SQL y CDS antes de implementar SQL nativo, vistas de SAP HANA o procedimiento de base de datos.
Las funciones abiertas se integran de manera óptima con el entorno de desarrollo y el tiempo de ejecución de BAP.
El servidor de aplicaciones ABAP comprueba exhaustivamente sus objetos de desarrollo, y no necesita ningún usuario adicional para la base de datos SAP HANA.
- Primero ABAP CDS y luego HANA CDS.
Debemos utilizar los procedimientos de la base de datos ABAP en lugar de los procedimientos de la base de datos SAP HANA.
Los objetos de desarrollo destinados por ABAP AS se vinculan de forma óptima con la gestión del ciclo de vida ABAP.
Podemos sincronizar fácilmente los procedimientos de la base de datos ABAP con otros objetos ABAP y transportarlos.
2.3 Recomendaciones para la migración.
Una regla básica es que las aplicaciones ABAP son totalmente compatibles.
Pero igualmente debemos tener en cuenta algunos puntos importantes:
- Código ABAP dependientes de la base de datos.
Si usamos código ABAP dependiente de la base de datos en los desarrollo existentes, debemos probarlo como en cualquier migración de datos y ajustarlo para la base de datos SAP HANA si es necesario.
Un ejemplo de esto es la utilización de SQL nativo a través de la declaración EXEC SQL o los hints de base de datos; estas posiciones en el código deben verificarse.
Si bien los hints de labs de datos ya no se ejecutan en la nueva plataforma cuando se migra a SAP HANA, siempre será necesaria una comprobación exacta para el SQL dependiente de la base da datos, ya es muy probable que ocurran errores a menos que intervengamos.
"Los hints e la base de datos, cuyo objetivo generalmente es forzar la ejecución de un índice y dividir la carga de trabajo, no solo que no funciona en SAP HANA sino que no son necesarios debido a la nueva arquitectura de la base de datos HANA".
- Conversión de tablas pool y custer.
Al convertir las tablas cluster y pool en tablas transparentes, pueden surgir problemas si confiamos en un ordenamiento implícito en nuestros desarrollos.
Esto se debe a que en las tablas cluster y pool, la interfase de la base de datos (DBI) siempre realiza un ordenamiento implícito.
Este ordenamiento se pierde después de a conversión a una tabla transparente porque aquí no se agrega ORDER BY automático en la declaración. Por lo tanto, el acceso a las tablas pool y cluster debe analizarse con respecto a su ordenamiento durante una migración a SAP HANA.
""Ei inspector de código nos proporciona la verificación Find Select Pool/Cluster Tan without ORDER BY de modo que podamos encontrar rápida y fácilmente estos puntos críticos en nuestros desarrollos ABAP."".
- Comportamiento del Ordenamiento
Si no especificamos ORDER BY en la declaración SQL SELECT, la secuencia en la que se leen los registros de la tabla de datos es impredecible.
Pueden ocurrir cambios en el comportamiento de ordenación implícita para las tablas transparentes existente.
En las bases de datos orientadas a filas se accede a las tablas a través de un índice primario o secundario. Aquí, los datos a menudo se leen en la secuencia deseada porque se leen desde la base de datos en la secuencia almacenada allí cuando se usa un índice.
"Con SAP HANA el ordenamiento implícito no esta garantizado ya que no es una característica documentada de Open SQL.
Tal como mencionamos anteriormente debemos utilizar la adición ORDER BY si deseamos que los datos se seleccionen en un orden determinado".
Esta regla se aplica en particular a SAP HANA porque los datos están orientados a columnas, no hay un índice secundario y los datos se pueden leer en paralelo.
Por lo tanto, los lugares del código ABAP en donde encontremos con esta situación implican un error de programación que debemos corregir independientemente de la migración de SAP HANA.
3.- Pautas de performance.
A continuación proporcionaremos recomendaciones de rendimiento para desarrollar aplicaciones ABAP en SAP HANA, contestaremos las preguntas más importantes y frecuentes relacionadas con SAP HANA y describiremos las reglas más importantes y cualquier cambio en el contexto de SAP HANA.
Reglas e oro para la programación de bases de datos.
Existen 5 reglas cuyo objetivo es optimizar la programación de las bases de datos. Estas son:
1. Mantener el conjunto de resultados lo más pequeño posible.
2. Mantener el conjunto de datos transferido los más pequeño posible
3. Reducir e número de ejecuciones de consulta SQL.
4. Minimizar el esfuerzo de búsqueda.
5. Reducir la carga en la base de datos.
3.1 Mantener el conjunto de resultados lo más pequeño posible
Es decir el número de filas seleccionadas lo más pequeño posible al leer datos de la base de datos.
Podemos minimizar el conjunto de resultados utilizando varias medidas:
- Usando la cláusula WHERE.
En ABAP el número de registros transferidos se controla mediante la condición WHERE.
Debemos leer solo los registros de datos que realmente necesitamos. Podemos no utilizar la condición WHERE solo si se requieren todos los registros para cada acceso.
"No utilizar la cláusula WHERE es particularmente problemático para las tablas de base de datos que aumentan con el tiempo porque los volúmenes crecientes de datos se transfieren con el tiempo".
Ejemplo en donde se seleccionan todos los clientes de la tabla:
SELECT id_name discount custtype
FROM scustom
INTO (lv_cust-id, lv_cust-name,
lv_cust-discount, lv_cust-custtype).
IF lv_cust-custtype = 'B'.
WRITE: / lv_cust-id,
lv_cust-name,
lv_cust-dicount.
ENDIF.
ENDSELECT.
En el siguiente ejemplo solo se seleccionan los clientes que se necesitan.
SELECT id_name discount custtype
FROM custom
INTO (lv_cust-id, lv_cust-name,
lv_cust-discount, lv_cust-custtype)
WHERE custtype = 'B'.
WRITE: / lv_cust-id,
lv_cust-name,
lv_cust-dicount.
ENDSELECT.
- Trabajando con la cláusula HAVING.
Proporciona otra opción para reducir las filas seleccionadas.
Se utiliza junto con la cláusula GROUP BY para seleccionar solo ciertos grupos haciendo restricciones a las filas agrupadas por ejemplo, en los valores agregados.
En el siguiente ejemplo se determina y selecciona el uso mínimo de todas las conexiones de vuelo.
SELECT carril connie MIN(seatsocc)
FROM sflight
INTO (lv_sflight-carrid, lv_sflight-connid, lv_min)
GROUP BY carrid connie.
IF lv_min > 0.
WRITE: / lv_sflight-carrid,
lv_sflight-connid, lv_min.
ENDIF.
ENDSELECT.
Utilizando HAVING.
SELECT carril connie MIN(seatsocc)
FROM sflight
INTO (lv_sflight-carrid, lv_sflight-connid, lv_min)
GROUP BY carrid connie.
HAVING lv_min > 0.
WRITE: / lv_sflight-carrid,
lv_sflight-connid, lv_min.
ENDSELECT.
- Transfiriendo solo las filas requeridas.
Siempre debemos transferir solo los registros de datos que realmente necesitamos.
"Nunca debemos eliminar los datos que no necesitamos en el servidor de aplicaciones en el programa ABAP y, por lo tanto, transferirlos innecesariamente desde la base de datos".
Un ejemplo que cae bajo esta regla se refiere a la selección de datos en tablas internas, de las cuales los registros de datos que son innecesariamente se eliminan usando la sentencia DELETE.
SELECT id_name discount custtype
FROMO scustom
INTO CORRESPONDING FIELDS OF TABLE lt_scustom
WHERE country = 'DE'.
DELETE lt_custom WHERE custtype = 'P'.
LOOP AT lt_scustom INTO ls_cust.
WRITE: / ls_cust-id, ls_cust-name, ls_cust-discount, ls_cust-custtype.
ENDLOOP.
La sentencia CHECK o el filtrado mediante IF-ENDIF también pueden indicar la transferencia de demasiadas filas. En el siguiente ejemplo, la selección está restringida a los datos requeridos.
SELECT id_name discount custtype
FROMO scustom
INTO CORRESPONDING FIELDS OF TABLE lt_scustom
WHERE country = 'DE'.
AND custtype <> 'P'.
LOOP AT lt_scustom INTO ls_cust.
WRITE: / ls_cust-id, ls_cust-name, ls_cust-discount, ls_cust-custtype.
ENDLOOP.
Significado de la Regla # 1 para SAP HANA.
Una aplicación coherente de esta regla para las bases de datos clásicas conduce a un menor esfuerzo de E/S, un consumo de memoria optimizado en el caché, un menor consumo de CPU y una transferencia de red optimizada porque se transfieren menos datos.
Esta regla se aplica sin cambios y con la misma prioridad para SAP HANA.
La CPU y los recursos de la memoria principal también se conservan en SAP HANA si hay que leer menos registros de datos.
No hay cambios en la transferencia de datos a través de la red.
3.2 Mantener el conjunto de datos transferido lo más pequeño posible.
Esto se debe a que los datos se transfieren de la base de datos al servidor de aplicaciones en bloques y la carga de red se puede reducir transfiriendo menos bloques.
Como programador, podemos hacer esto al influir en el número de filas y columnas seleccionadas mediante restricciones que van más allá de la condición WHERE. Estas restricciones se logran:
- Utilizando la adición UP TO n ROWS.
Si solo necesitamos un cierto número de filas, podemos utilizar la adición UP TO n ROWS para restringir aún más el número de filas.
Ejemplo de un proceso incorrecto:
Como SELECT...ENDSELECT. lee los datos en bloques de la base de datos, en el primer bloque ya se transfirieron más registros de los necesarios.
SELECT id_name discount
FROM scustom
INTO (ls_cust-id, ls_cust-name, ls_cust-discount)
WHERE custtype = 'B'
ORDER BY discount DESCENDING.
IF sy-dbcnt GT 10. EXIT.
ENDIF.
WRITE: / ls_cust-id, ls_cust-name, ls_cust-discount.
ENDSELECT.
Ahora bien si utilizamos la adición UP TO n ROWS exactamente 10 registros se transfieren (ejemplo de un buen proceso).
SELECT id_name discount
FROM scustom UP TO 10 ROWS
INTO (ls_cust-id, ls_cust-name, ls_cust-discount)
WHERE custtype = 'B'
ORDER BY discount DESCENDING.
WRITE: / ls_cust-id, ls_cust-name, ls_cust-discount.
ENDSELECT.
- Trabajando con DISTINCT
Si el sistema calcula con una determinada condición WHERE que tiene entradas duplicadas innecesarias con respecto a as columnas seleccionadas, la instrucción DISTINCT debe usarse para eliminar las entradas duplicadas que ya se encuentran en la base de datos.
En el ejemplo siguiente, se crea una lista de descuentos que se otorgaron y las entradas duplicadas se eliminan después de la selección.
En el siguiente ejemplo, se crea una lista de descuentos que se otorgaron y las entradas duplicadas se eliminan después de la selección.
SELECT custtype discount
FROM scustom
INTO CORRESPONDING FIELDS OF TABLE lt_scustom
WHERE discount > 0
ORDER BY custtype discount DESCENDING.
DELETE ADJACENT DUPLICATES FROM lt_custom.
LOOP AT lt_scustom INTO ls_cust.
WRITE: / ls_cust-custtype, ls_cust-discount.
ENDLOOP.
Ahora utilizando DISTINCT solo los datos requeridos se leen de la base de datos.
SELECT DISTINCT custtype discount
FROM scustom
INTO CORRESPONDING FIELDS OF TABLE lt_scustom
WHERE discount > 0
ORDER BY custtype discount DESCENDING.
LOOP AT lt_scustom INTO ls_cust.
WRITE: / ls_cust-custtype, ls_cust-discount.
ENDLOOP.
- Reduciendo el número de columnas.
Debemos seleccionar solo las columnas de una tabla de base de datos que son necesarios en el programa.
La selección de todas las columnas mediante SELECT * solo se debe realizar si todas las columnas son realmente necesarias.
En la instrucción INTO CORRESPONDING FIELDS OF TABLE lt_scustom, cuando se especifica SELECT *, el sistema realiza un esfuerzo en la comparación de todos los nombres de las columnas, por lo tanto hay que ser muy cuidadoso.
- Utilizando funciones de agregación.
Si solo se requiere datos para los cálculos, es mejor realizar estos cálculos en la base de datos y transferir los resultados en lugar de transferir todos los datos y realizar el cálculo en el programa ABAP.
"Las funciones agregadas son: COUNT, MIN, MAX, SUM y AVG".
Ejemplo: mediante el siguiente código todas las reservas de vuelos se seleccionan y se agregar en el programa ABAP
lv_sum = 0.
SELECT seatsocc
FROM sflight
INTO lv_seatsocc
WHERE carried = 'LH'
AND flat LIKE '2013 %'.
lv_sum = lv_sum + lv_seatsocc.
ENDSELECT.
WRITE: / lv_sum.
Mientras que con la siguiente lógica la suma de las reservas se calcula en la base de datos, y solo esta suma se transfiere al programa ABAP.
lv_sum = 0.
SELECT SUM(seatsocc)
FROM sflight
INTO lv_seatsocc
WHERE carried = 'LH'
AND flat LIKE '2013 %'.
WRITE: / lv_sum.
- Realizando chequeos de existencia eficientemente
Debemos realizar estas funciones agregadas solo si necesitamos realizar un cálculo.
Para determinar si hay un registro de datos para una clave específica, no debemos usar SELECT COUNT(*) porque el número es irrelevante en este caso.
Para tal verificación de existencia, solo necesitamos un solo campo del registro de datos que buscamos, y este debe ser un campo del índice que está en uso.
Si deseamos verificar si hubo vuelos para una conexión de vuelo específica en un año, tal como mencionamos podemos verificarlo utilizando un COUNT(*).
Aquí, se cuentan todos los registros de datos en la base de datos que cumplen con la condición.
La adición UP TO 1 ROWS no cambia nada porque solo se ejecuta después de contar.
SELECT count(*) UP TO 1 ROWS
FROM flight INTO lv_cnt
WHERE carried = 'LH'
AND connie = '0400'
AND flat LIKE '2013 %'.
IF lv_cnt > 0.
ENDIF.
Ahora bien, mediante el siguiente código los registros de datos no se cuentan porque el número de registros es irrelevante. Solo se selecciona un campo, tampoco debería haber SELECT * aquí, el conjunto de resultados está restringido a una fila con UP TO n ROWS.
Esto asegura que solo lea un registro de datos. Una vez que la base de datos ha determinado un registro que cumple con las condiciones, el procesamiento finaliza.
SELECT carril INTO lv_sflight-carrid
UP TO 1 ROWS
FROM sfight
WHERE carried = 'LH'
AND connid = '0400'
AND fldate LIKE '2013 %'.
ENDSELECT.
IF sy-subrc EQ 0.
...
- Modificando solo las columnas necesarias.
Para realizar cambios con la instrucción UPDATE, solo las columnas deben cambiarse con la instrucción SET.
Aquí, se transfiere una cantidad innecesariamente grande de columnas y todas las columnas se sobreescriben en la base de datos, incluso si sus valores no han cambiado.
SELECT * FROM sbook
INTO ls_book
WHERE carried = 'LH'
AND connie = '0400'
AND fldate >= '20140101'.
ls_book-conid = '0500'.
UPDATE book FROM ls_book.
ENDSELECT.
En este caso solo se debe cambiar la(s) columna(s) que tiene que cambiar.
UPDATE sbook
SET connie = '0500'
WHERE carried = 'LH'
AND connie = '0400'
AND fldate >= '20140101'.
Significado de la Regla #2 para SAP HANA.
Los efectos de la regla #2 son muy similares a los de la regla #1
La aplicación consistente de estas reglas lleva a un consumo reducido de recursos en a base de datos clásica.
Esta regla se aplica sin cambios a SAP HANA porque los recursos se conservan de manera similar.
La prioridad de la regla es ligeramente superior a la de otras bases de datos.
Esto se puede atribuir al diferente almacenamiento de datos. Si los registros de datos se almacenan de forma basada en filas, todas las columnas de un bloque están muy juntas.
En el almacenamiento orientado a columnas, cada columna es una estructura de almacenamiento separada. Aunque estas estructuras de almacenamiento pueden procesarse en paralelo, el tiempo requerido para varias columnas es ligeramente mayor.
Incluso si las diferencias no son muy grandes, debemos prestar especial atención a estas reglas y verificar las aplicaciones de tiempo crítico para la optimización con respecto a esta regla.
3.3 Reducir l número de ejecuciones de consulta.
La tercera regla recomienda reducir el número de consultas a la base de datos.
Cada declaración SQL en un programa ABAP que se envía a la base de datos implica un cierto grado de esfuerza en la base de datos.
Por lo tanto, la declaración y sus parámetros asociados se transfieren a lavase de datos donde la declaración se analiza en términos de la sintaxis y la función de búsqueda por hash en el caché de SQL, o donde la declaración se almacena cuando se ejecuta por primera vez.
Además, las autorizaciones y la existencia de objetos de base de datos (tablas, vistas, etc.) deben verificarse para asegurarse de que estén presentes.
Los resultados de la consulta también deben ser transferidos.
Para reducir la carga en lavase de datos, debemos mantener el numero de accesos lo más bajo posible.
En los programas ABAP, podemos influir en em número de declaraciones mediante las siguientes medidas:
- Usando operaciones de conjunto en lugar de operaciones individuales.
Al leer con SELECT, debemos elegir la adición INTO TABLE en lugar del bucle SELECT --- ENDSELECT si todos los datos a leer caben en la memoria principal.
SELECT ---- ENDSELECT lee los datos de la base de datos en bloques a la interfase de la base de datos.
Desde allí los datos se transfieren en registros únicos al programa ABAP.
"El bucle SELECT -- ENDSELECT es til si la memoria disponible es suficiente para todos los datos o si solo se accede a los datos leídos una vez".
Para accesos de escritura, debemos confiar siempre que sea posible en las operaciones de configuración con tablas internas. El número de consultas de la base de datos se reduce considerablemente, la base de datos puede realizar más optimizaciones con los datos que se transfieren todos a la vez.
En el siguiente ejemplo: los registros de datos se insertan registro por registro en un bucle.
LOOP AT lt_sbook INTO ls_sbook.
INSERT INTO sbook VALUES ls_book.
ENDLOOP.
Mientras que con la siguiente sentencia todos los registros de datos se insertan en una sola operación.
INSERT sbook FROM TABLE lt_sbook.
- No realizando más accesos múltiples.
Debemos asegurarnos de no acceder repetidamente a los mismos datos.
Por ejemplo, evitemos realizar un SELECT antes de un DELETE para el mismo registro de datos.
SELECT SINGLE * FROM flight INTO lv_sflight
WHERE carried = 'SQ' AND connie = '0002'.
IF sy-subrc =0.
DELETE FROM sflight
WHERE carried = 'SQ' AND connid = '0002'.
IF sy-subrc =0.
COMMIT WORK.
ENDIF.
ENDIF.
En el siguiente código realizamos una operación DELETE sin una instrucción SELECT precedente.
DELETE FROM sflight
WHERE carried = 'SQ' AND connid = '0002'.
IF sy-subrc =0.
COMMIT WORK.
ENDIF.
- No utilizando bucles con SELECT anidados.
Para los bucles de SELECT anidados, la instrucción SELECT interna se ejecuta una vez para cada registro de datos que devuelve el bucle SELECT externo.
Por tanto, tal construcción solo debe usarse si el conjunto de resultados del bucle externo contiene muy pocas filas.
Para fusionar conjuntos de datos, es recomendable utilizar?
Joins o uniones.
vistas.
FOR ALL ENTRIES.
Ejemplos:
Aquí, la instrucción SELECT se ejecuta una vez en la tabla SBOOK para cada registro de datos que se leyó en la tabla SFLIGHT.
SELECT carril connid fldate FROM sflight
INTO (lv_carrid, lv_connid, lv_fldate)
WHERE plane type = '727-200'.
SELECT booked FROM sbook INTO lv_bookid
WHERE carried = lv_carrid
AND connid = lv_connid
AND fldate = lv_fldate.
WRITE: / lv_carrid, lv_connid, lv_bookid.
ENDSELECT.
ENDSELECT.
Mientras que en la siguiente lógica los datos se leen mediante una unión y solo se envía una declaración a la base de datos.
SELECT f~carrid f~connid b~bookid
INTO (lv_carrid, lv_connid, lv_bookid)
FROM sflight AS f INNER JOIN sbook AS b
ON f~carrid = b~carrid
AND f~connid = b~connid
AND f~fldate = b~fldate
WHERE plane type = 727-200
WRITE: / lv_carrid, lv_connid, lv_bookid.
ENDSELECT.
- Sin ejecutar instrucciones SELECT en el LOOP a través de tablas internas.
Al igual que los bucles anidados, no debemos ejecutar ls instrucciones SELECT en e LOOP a través de tablas internas.
Aquí, la instrucción FOR ALL ENTRIES es útil para reducir el número de ejecuciones.
"Cuando utilizamos la sentencia FOR ALL ENTRIES debemos asegurarnos que la tal interna nunca esté vacía y no contenga duplicados".
Ejemplo, se ejecuta un SELECT para cada registro de datos en el bucle LOOP mediante la tabla interna LT_SFLIGHT
LOOP AT lt_sflight INTO lv_sflight,
SELECT SINGLE bookid customid FROM sbook
INTO lv_sbook.
WHERE carrid = lv_carrid
AND connid = lv_connid
AND fldate = lv_flvdate.
WRITE: / lv_sflight -carrid,
lv_sflight-connid.
lv_sflight-fldate,
lv_sbook-bookid,
lv_sbook-customid.
ENDLOOP.
Mientras que el siguiente código el número de sentencias SELECT ejecutadas se reduce utilizando FOR ALL ENTRIES.
IF lines ( lt_sflight ) > 0.
SELECT carrid connid fldate bookid customid
FROM sbook
INTO CORRESPONDING FIELDS OF TABLE lt_sbook
FOR ALL ENTRIES IN lt_sflight
WHERE carrid = lt_sflight-carrid
AND connid = lt_sflight-connid
AND fldate = lt_sflight-fldate.
ENDIF.
- Utilizando BUFFERS.
El uso del buffer de tabla SAP y otros buffers también contribuyen a minimizar el numero de declaraciones SQL que se envían a la base de datos.
Significado de la regla #3 para SAP HANA.
La aplicación coherente de esta regla lleva a un consumo reducido de CPU para las bases de datos clásicas.
Los recursos de red también se utilizan de una mejor manera porque se puede optimizar la cantidad de bloques enviados.
Esta regla tiene una prioridad más alta para SAP HANA que para otras bases de datos.
El esfuerzo involucrado en la ejecución de una declaración es actualmente un poco más alto en SAP HANA que en las bases de datos clásicas.
Sin embargo, esto será optimizado en el futuro.
Las aplicaciones que envían un gran número de consultas rápidas a la base de datos deben examinarse en términos de potencial de optimización, en función de los enfoques presentados en los ejemplos de esta lección.
3.4 Minimizar el esfuerza de búsqueda.
Podemos minimizar el esfuerzo de la búsqueda de datos con un índice.
índices de bases de datos en bases de datos clásicas.
Existen índices primarios e índices secundarios.
Siempre se crea automáticamente en los sistemas SAP cuando crea una tabla.
Luego están los índices secundarios, que pueden ser únicos o no únicos. Los índices secundarios se crean en el DDIC.
Normalmente se usan para optimizar el rendimiento, pero también pueden tener motivos semánticos para índices únicos si, 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 pueden minimizar significativamente el esfuerzo de búsqueda porque solo se debe leer una parte de los datos.
Recomendaciones.
Los índices secundarios se crearán solo para las tablas base de datos donde los accesos de lectura son más críticos en el tiempo que los accesos de escritura, ya que cada índice creado debe mantenerse para los accesos de escritura.
El número de índices y campos creados en el índice debe mantenerse lo más pequeño posible, De lo contrario, se requiere más esfuerzo para cambiar los accesos a la base de datos, y el optimizado es más probable que tome decisiones erróneas.
Los campos en los que se crean los índices solo deben estar en un índice si es posible. Deben evitarse los solapamientos.
Los campos en un índice secundario deben ser campos a través de los cuales selecciona a menudo. Estos campos también deben ser selectivos; es decir, el porcentaje de registros de datos seleccionados por el índice debe ser pequeño.
Los campos que tienen más probabilidades de ser consultados con el operador = deben estar al principio del indice.
El operador = y los AND siempre son compatibles e manera eficiente en el índice, una lista de IN también cae en esta categoría.
Debemos evitar los no igual not in , se debe evitar, distinto, porque no se puede admitir de manera eficiente en el indice, si es posible debemos reescribir como positivas.
- indices de la base de datos en SAP HANA.
Con SAP HANA, distinguimos entre índices vertidos y compuestos.
Los índices compuestos tienen requisitos de memoria más alto debido a las estructuras de memoria para una columna interna adicional.
Se recomienda trabajar lo más posible con los índices invertidos.
Es decir, se debe crear un índice en cada caso para la columna que tenga la condición más selectiva. Los índices compuestos deben crearse solo en casos excepcionales, por ejemplo, cuando los datos de diferentes columnas se correlacionan de tal manera que solo ciertas combinaciones son selectivas.
El mantenimiento de los índices también aumenta los costos de acceso de escritura en SAP HANA.
Sin embargo, estos costos son significativamente menores para los índices invertidos que para los índices compuestos, para los cuales se deben mantener múltiples estructuras de memoria.
"Si estamos migrando un sistema existente SAP HANA, ya no se crean todos los índices secundarios existentes para las tablas configuradas con almacenamiento por columnas".
En principio, solo se deben crear índices adicionales si los tiempos de acceso son insuficientes sin un índice. En este caso, se debe crear un índice para las condiciones selectivas, siempre que no estén cubiertas por el índice primario.
Significado de la rega #4 para SAP HANA.
Una aplicación coherente de esta cuarta regla para las bases de datos clásicas lleva a un menor esfuerzo de E/S, optimiza el consumo de memoria en la caché, reduce el consumo de CPU y optimiza la transferencia de red porque se transfiere menos datos.
La cuarta regla cambia en SAP HANA, y su cumplimiento tiene una prioridad más baja porque en muchos casos no se requiere ningún índice en SAP HANA. Si se requiere un índice para las tablas muy grandes, las reglas para la definición del indice cambian.
En estos casos, el consumo de CPU se reduce por el índice.
En SAP HANA, los indices generalmente se crean para columnas individuales.
Los índices que abarcan varias columnas son la excepción.
3.5 Reducir la carga en a base de datos.
La quinta regla se resume las reglas mencionadas anteriormente y recomienda reducir la carga en la base de datos siempre que se posible.
La base de datos es un recurso central en el sistema SAP.
Por este motivo, debemos mantener la carga para operaciones repetidas en la base de datos lo más pequeña posible.
- Utilizando Buffers.
Debido a que los datos de SAP HANA se almacenan en la memoria principal, es posible que nos hayamos preguntado si los buffers en el servidor de aplicaciones o en los programas aún son necesarios.
Los siguientes buffers cross usuario están disponibles en el servidor de aplicaciones:
. Objetos compartidos
. Buffer compartido
. Memoria compartida
. Buffer de tabla
Los siguientes buffers específicos del 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.
No hay cambios en las recomendaciones para el almacenamiento en buffer de datos cuando se usa SAP HANA.
El acceso al buffer en el servidor de aplicaciones es aún más rápido que acceder a la base de datos también para SAP HANA.
Esto se debe a que, entre otras cosas, la memoria principal del servidor de aplicaciones ser encuentra en el mismo servidor en el que se ejecuta el programa ABAP.
El acceso al buffer de la taba es aproximadamente 10 veces mas rápido que el acceso a los datos en la base de datos.
Las reglas siguen siendo las mismas para los demás buffers (por ejemplo, objetos compartidos, memoria compartida, buffer compartido, tablas internas, memoria ABAP y memoria SAP).
Esto significa que debemos continuar almacenando en dichos buffers todos los datos que requieren mucho tiempo para obtener o calcular, y cualquier dato utilizado más de una vez. Esto aliviará la base de datos de consultas costosas repetidas.
- Ordenado.
Si el ordenamiento en la base de datos no se puede asignar a través de un índice que se utiliza para la selección entonces debemos ordenar en el ASP SAP, especialmente si a aplicación requiere ordenar el conjunto total de datos.
Sin embargo, si se requiere el ordenamiento de un conjunto de datos grande para calcular un resultado menor (por ejemplo determinar los cinco mejores clientes en relación con el valor del pedido), el ordenamiento debe realizarse en la base de datos.
Si el ordenamiento es parte del cálculo o se puede realizar de manera no muy costosa en la base de datos, también debe realizarse en las base de datos.
- Evitando accesos idénticos.
Otra medida es evitar accesos idénticos, es decir, debemos evitar la lectura múltiple de datos idénticos.
Esto no solo reduce el numero de accesos a la base de datos ( tal como mencionamos en la regla #3) sino que también evita cargas innecesarias en la base de datos.
Generalmente, las tablas internas o incluso los buffers se utilizan para evitar accesos idénticos.
Significado de la regla #5 para SAP HANA.
Una aplicación coherente de esta quinta regla para las bases de datos clásicas conduce a un menor consume de CPU y a una carga reducida en la red.
El esfuerzo de E/S también puede reducirse evitando accesos múltiples.
También con SAP HANA, los buffers en el servidor de aplicaciones siguen estando justificados porque ofrecen tiempos de acceso más rápidos y pueden aliviar la base de datos de accesos innecesarios.
Esto significa, por ejemplo, que podemos ejecutar cálculos complejos a través de la inserción de código en la base de datos en SAP HANA, pero solo podemos llamar a estos cálculos con la frecuencia que sea necesaria.
Si un resultado debe consultarse varias veces, debe almacenarse en un buffer.
La fortaleza central de SAP HANA reside en la ejecución de cálculos complejos en grandes conjuntos de datos.
Debemos ejecutar dichos cálculos en la bas de datos
Sin embargo, no tiene sentido enviar siempre los mismos cálculos o accesos a los mismos datos de lavase de datos.
Por este motivo podemos formular una quinta regla para SAP HANA de la siguiente manera:
Aliviar la base de datos de accesos innecesarios.
Así formulada, esta regla se aplica sin cambios y con la misma prioridad a SAP HANA porque los recursos de la CPU y de la red también se pueden liberar de la misma forma.
Disponibilidad Laboral: FullTime
