Tips Practicos importantes al desarrollar aplicaciones ABAP en SAP HANA
Pautas de performance: la velocidad de ejecucion de los programas, naturalmente, desempeña un papael crucial en el contexto de SAP HANA
Muchos escenarios de uso implican el acceso a grandes conjuntos de datos en tiempo real.
Una comprension solida de las pauutas y tecnicas para lograr un rendimiento optimo es escencial.
El Almacenamiento por columnas vs Almacenamiento por filas
Cuando se crea una tabla BD poder elegir crearla con almacenamiento por columnas (columnar) o por filas.
Por defecto la tabla se creará con almacenamiento por columnas (Storage Type: poder elegir entre almacenamiento por columnas, filas o indefinido, por defecto se almacena por columnas).
Se puede analizar grandes conjuntos de datos de manera mas eficiente en el almacenamiento por columnas.
Sap recomienda que se configure todas las tablas BD utilizando almacenamiento por columnas, siempre que no haya una razón especifica para almacenarlas por filas.
Las tablas que contienen datos de la aplicacón siempre se almacenan por columnas porque es muy probable que estos datos tambien se utilicen en escenarios de análisis.
Esto se aplica particularmente a las tablas que contienen una gran cantidad de registros de dedatos porque el almacenamiento por columnas proporciona mejores propiedades de compresión.
Esto tambien se aplica a las tablas que se utilizarán para búsquedas de texto.
Existen motivos para utilizar almacenamiento por filas en una tabla, por ejemplo si se accede a una tabla mediante declaraciones en lenguaje de manipulacion de datos (DML) en el tiempo (insert, update, delete) esta no puede ser una tabla de aplicaciones en la que posteriormente se necesite realizar analisis, por lo tanto, principalmente las tablas tecnicas de SAP son elegibles para el almacenamiento por filas. Los ejemplos incluyen tablas para el procesamiento de actualizaciones correspondientes al paquete STSK o para el procesamiento de llamadas a funcion remota remotas RFC correspondientes al paquete SORFC. Normalmente se accede a estas tablas con un select simple.
En cada base de datos relacional las entradas de una entrada BD deben almacenarse en un determinado diseño de datos independiente de que si esta representacion se realiza en la memoria principal por ejemplo en SAP HANA o siguiendo el enfoque tradicional con un medio fisico. Hay 2 opciones diferentes para esto. Almacenamiento de datos basado en Filas y en Columnas. SAP HANA soporta ambos enfoques.
En SAP HANA se puede especificar el enfoque de almacenamiento que se utilizara para cada tabla base de datos ya sea que este creada desde el diccionario de datos o en SAP HANA STUDIO.
Basado en Fila: todos los datos pertenecientes a una fila se colocan uno al lado del otro, lo que facilita el acceso a toda la fila. sin embargo accede a todos los valores de una columna es un poco mas complejo ya que estos valores no se puede transferir desde la memoria principal a la CPU de manera tan eficiente como el almacenamiento basado en columnas la compresion de los datos tambien es menos eficiente con este enfoque de almacenamiento
Basado en Columnas: Los contenidos de una columna se colocan uno junto al otro en la memoria principal esto significa que todas las operaciones que accedan a una columna encontraran la informacion requerida cerca, lo que tiene efectos favorables en el transporte de datos entre la memoria principal y la CPU. sin embargo si se necesita una gran cantidad de datos o todos los datos de una fila se convierte en una desventaja ya que no tiene los datos cerca, el almacenamiento basado en columnas tambien facilita la compresion eficiente y la agregacion basados en una columna.
Conclusiones: ambos enfoques tienen ventajas y desventajas.
Los datos comerciales casi siempre se colocan en el almacenamiento basado en columnas porque las ventajas de este enfoque superan a sus desventajas (grandes cantidades de datos) sin embargo Algunas tablas requieren almacenamiento de datos basados en filas. principalmente son tablas 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 (SELECT SINGLE) son el patron de acceso principal.
Compresion de los datos: la base de datos de SAP HANA posee tecnicas de compresion que pueden usarse para los datos en el almacenamiento por columna tanto en memoria principal como en almacenamiento persistente. La alta compresion reduce la cantidad de datos que deben transferirse desde la memoria principal a la CPU. Esto se aplica particularmente si se necesita analizar garndes cantidades de datos. Algunas tablas requeieren almacenamiento de datos basado en filas.
Codificacion: traducir el contenido de un campo en un entero.
Para almacenar el contenido de una columna en el almacenamiento por columnas, la base de datos de SAP HANA crea un minumo de dos estructuras de datos
Vector de diccionario: almacena cada valor de una columna solo una vez,
Vector de atributo.
Implementacines especificas de SAP HANA: Se debe distinguir dos escenarios
Implementaciones independientes de la BD: por ejemplo utilizando OPEN SQL y ABAP CDS
Implementaciones que utilizan funciones especificas de SAP HANA: por ejemplo, SQL nativo y HANA CDS.
Para la optimizacion de rendimiento de una aplicacion ABAP existente, es recomendable que se proceda inicialmente utilizando herramientas estándar.
Primero Open y luego native: preferiblemente se deba utilizar las vistas de Open SQL y CDS antes de implementar SQL nativo, vistas de SAP HANA o procedimientos de BD.
Las funciones abiertas se integran de manera óptima con el entorno de desarrollo ABAP y en el tiempo de ejecucion de ABAP.
El servidor de aplicaciones ABAP comprueba exhaustivamente sus objetos de desarollo, y no necesita ningun usuario adicional para la base de datos SAP HANA
Primero ABAP CDS y luego HANA CDS: se debe utilizar los procedimientos de la BD ABAP en lugar de los procedimientos de la BD SAP HANA.
Los objetos de desarrollo gestionados por ABAP AS se vinculan de forma optima con la gestion del ciclo de vida ABAP.
Se puede sincronizar facilmente lo sprocedimientos de la BD ABAP con otros objetos ABAP y transportarlos.
Recomendaciones para la migracion: Una regla basica es que las aplicaciones ABAP son totalmente compatibles, pero igualmente se debe tener en cuenta:
Codigo ABAP dependiente de la BD: si se usa codigo ABAP dependiente de la BD en los desarrollos existentes, se debe validar como en cualquier migracion de datos y ajustarlo para la BD SAP HANA si es necesario.
Un ejemplo es la utilizacion de SQL nativo a través de la declaracion EXEC SQL o los hints de BD; estas posiciones en el codigo deben verificarse.
Si bien los hints de la BD ya no se ejecutan en la nueva pataforma cuando se migra a SAP HANA, siempre sera necesaria una comprobacion exacta para el SQL dependiente de la BD, ya es muy probable que ocurran errores.
Los Hints de la BD, cuyo objetivo generalmente es forzar la ejecucion de un indice y dividir la carga de trabajo, no solo que no funcionan en SAP HANA sino que no son necesarios debido a la nueva arquitectura de la BD HANA.
Conversion tablas de pool y cluster: al convertir las tablas cluster y pool en tablas transparentes, pueden surgir problemas si se confia en un ordenamiento implicito en los desarrollos.
Esto se debe a que en las tablas cluster y pool, la interfase de la BD (DBI) siempre realiza un ordenamiento implicito.
Este ordenamiento se pierde despues de la conversion a una tabla transparente porque aqui no se agrega ORDER BY automatico en la declaracion. por lo tanto, el acceso a las tablas pool y cluster debe analizarse con respecto a su ordenamiento durante una migracion a SAP HANA.
El inspector de codigo proporciona la verificacion Find Select for pool/cluster Tab without ORDER BY de modo que se pueda encontrar rápida y fácilmente estos puntos críticos en los desarrollos ABAP.
Comportamiento del ordenamiento: si no se especifica ORDER BY en la declaracion SQL SELECT, la secuencia en la que se leen los registros de la tabla BD es impredecible.
Puede ocurrir cambios en el comportamiento de ordenación implícita para las tablas transparentes existentes.
En las BD orientadas a filas se accede a las tablas a través de un índice primario o secundario. Aqui, los datos a menudo se leen en la secuencia deseada porque se leen desde la BD 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.
Se debe utilizar la adición ORDER BY si se desea que lo sdatos se selecciones en un orden determinado.
Esta regla se aplica en particular a SAP HANA poruqe los datos estan orientados a columna, no hay un índice secundaro y los datos se pueden leer en paralelo.
Por lo tanto, los lugares del codigo ABAP en donde se puede encontrar con esa situacion implican un error de programacion que se debe corregir independientemente de la migracion a SAP HANA.
Puede ocurrir problema cuando se asume que un ordenamiento determinado es llevado a cabo en la secuencia de un programa ABAP. por ejemplo cuando se trabaja con una tabla interna y se ejecuta la adicion BINARY SEARCH la cual tiene como requisito que la tabla interna se encuentre previamente ordenada por el campo CAMPOS por el cual se ejecutara la busqueda binaria. No se debe confiar en los ordenamiento implícitos, si se necesita una clasificacion especifica de los datos cuando se accede a una base de datos se debe usar ORDER BY explicitamente.
Las pautas de performance:
Reglas de oro para la programacion de BD: existe un conjunto de 5 reglas cuyo objetivo es optimizar la programacion de la BD.
- Mantener el conjunto de resultados lo mas pequeño posible: es decir el numero de filas seleccionadas lo mas pequeño posible al leer datos de la BD. esto es posible de realizar usando varias medidas:
Usando una clausula WHERE: en ABAP, el numero de registros de datos transferidos se controla mediante la condicion WHERE. se debe leer solo los registros de datos que realmente se necesita. Se puede no utilizar la condicion WHERE solo si se requieren todos los registros para cada acceso
No utilizar la clausula WHERE es particularmente problematico para las tablas BD que aumentan con el tiempo poruqe los volumenes crecientes de datos se transfieren con el tiempo.
Trabajando con la clausula HAVING: proporciona otra opcion para reducir las filas seleccionadas
Se utiliza junto con la clausula GROUP BY para seleccionar solo ciertos grupos haciendo restricciones a las filas agrupadas, por ejemplo en valores agregados.
Transfiriendo solo las filas requeridas: siempre se debe transferir solo los registros de datos que realmente se necesite.
Nunca se debe eliminar los daos que no se necesite en el servidor de aplicaciones en el programa ABAP y, por lo tanto, transferirlos innecesariamente desde la BD.
Significado de la Regla 1 para SAP HANA: una aplicacion coherente de esta regla para las BD 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 tambien se conservan en SAP HANA si hay que leer menos registros de datos.
No hay cambios en la transferencias de datos a través de la red.
- Mantener el conjunto de datos transferido lo mas pequeño posible: se debe transferir la menor cantidad de datos posible entre la BD y el servidor de aplicaciones. Esto se debe a que los datos se transfieren de la BD a servidor de aplicaciones en bloques y la carga de red puede reducir transfiriendo menos bloques. Se puede realizar esto al influir en el número de filas y columnas seleccionadas mediante restricciones que van más allá de la condición WHERE.
Utilizando la adición UP TO n ROWS: solo se necesita un cierto número de filas, asi se podrá restringir aún más el número de filas.
Trabajando con DISTINCT: si el sistema calcula con una determinada condición WHERE que tiene entradas duplicadas innecesarias con respecto a las columnas seleccionadas, la intrucción DISTINCT debe usarse para eliminar las entradas duplicadas que ya se encuentran en la BD.
Reduciendo el numero de columnas: se debe seleccionar solo las columnas de una tabla de BD que son necesarios en el programa.
La seleccion de todas las columnas mediante SELECT * solo se debe realizar si todas las columnas son realmente necesarias.
Utilizando funciones de agregacion: si solo se requerien datos para los cálculos, es mejor realizar estos cálculos en la BD y transferir los resultados en lugar de transferir todos los datos y realizar el cálculo en el programa ABAP.
Las funciones agregadas disponibles son COUNT,MIN,MAX,SUM y AVG para el número, el valor minimo, el valor maximo, la suma de los valores y el valor promedio, respectivamente.
Realizando chequeos de existencia eficientemente: se debe utilizar estas funciones agregadas solo si se necesita realizar un cálculo.
para determinar si hay un registro de datos para una clave específica, no se debe usar SELECT COUNT (*) porque el numero es irrelevante en este caso.
Para tal verificacion de existencia, solo se necesita un solo campo del registro de datos que se busca, y este debe ser un campo del índice que está en uso.
Si se desea verificar si hubo vuelos para una conexión de vuelo específica en un año específico, puede ser verificado con un COUNT (*).
Aquí, se cuentan todos los registros de datos en la BD que cumplen con la condicion.
La adicion de UP TO 1 ROWS no cambia nada porque solo se ejecuta después de contar.
Modificando solo las columnas necesarias: para realizar cambios con la instruccion UPDATE, solo las columnas deseadas deben cambiarse con la instrucción SET.
Al cambiar filas de áreas de trabajo o estructuras, eneralmente se transfieren demasiados datos y las columnas que no han cambiado también se sobreescriben.
Significado de la Regla 2 para SAP HANA: los efectos de la regla 2 son simiares a la regla 1.
La aplicación consistente de estas reglas lleva a un consumo reducido de recursos en la BD 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 BD.
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 juntos.
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, se debe prestar especial atencion a estas reglas y verificar las aplicaciones de tiempo crítico para la optimizacón con respecto a esta regla.
- Reducir el numero de ejecuciones de consulta: cada declaracion SQL en un programa ABAP que se envia a la BD implica un cierto grado de esfuerzo en la BD.
Por lo tanto, la declaracion y sus parametros asociados se transfieren a la BD donde la declaracion se analiza en terminos de sintaxis y la funcion de busqueda por hash en el cache de SQL, o donde la declaracion se almacena cuando se ejecuta por primera vez.
Ademas, las autorizaciones y la existencia de objetos de BD (tablas, vistas, etc) deben verificarse para asegurarse de que estén presentes.
los resultados de la consulta tambien deben ser transferidos.
Para reducir la carga en la BD, se debe mantener el numero de acceso lo mas bajo posible.
En los programas ABAP, se puede influir en el numero de declaraciones mediante las siguientes medidas:
Usando operaciones de conjunto en lugar de operaciones individuales: al leer con SLECT, se debe elegir la adicion INTO TABLE en lugar del bucle SELECT ... END SELECT si todos los datos a leer caben en la memoria principal.
SELECT ... ENDSELECT lee los datos de la BD en bloques a la interfase de la BD.
Desde alli, los datos se transfieren en registros Unicos al programa ABAP.
El bucle SELECT ... ENDSELECT es útil si la memoria disponible es suficientemente para todos lo sdatos o si solo se accede a los datos leidos una vez.
Para los accesos de escritura, se debe confiar siempre que sea posible en las operaciones de configuracion con tablas internas. El numero de consultas de la BD se reduce considerablemente, y la BD puede realiar las optimizaciones con los datos que se transfirieron todos a la vez.
No realizando accesos multiples: se debe asegurar de no acceder repetidamente a los mismos datos.
No utilizando bucles con SELECT anidados: para los bucles de SELECT anidados, la instruccion SELECT interna se ejecuta una vez para cada registro de datos que devuelve el bucle SELECT externo.
Por lo tanto, la contruccion solo debe usarse si el conjunto de resultados del bucle externo contiene muy pocas filas.
Para fusionar conjuntos de datos, es recomendable usar: Joins o uniones - Vistas - FOR ALL ENTIES.
Sin ejecutar instrucciones SELECT en el LOOP a través de tablas internas: al igual que bucles anidados no se debe ejecutar esta instruccion. Aqui, la adicion FOR ALL ENTRIES es útil para reducir el numero de ejecuciones.
Cuando se usa la sentencia FOR ALL ENTRIES se debe asegurar que la tabla nterna nunca esté vacía o no contenga duplicados.
Utilizando buffers: El uso de buffer de tabla SAP y otros Buffers tambien constribuyen a minimizar el numero de declaraciones SQL que se envian a la BD.
Significado de la Regla 3 para SAP HANA: la aplicacion coherente de esta regla lleva a un consumo reducido de CPU para las BD clásicas.
Los recursos de red tambien 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 BD.
El Esfuerzo involucrado en la ejecucion de una declaracion es actualmente un poco mas alto en SAP HANA que en las otras BD clasicas.
Sin embargo, esto será optimizado en el futuro.
Las aplicaciones que envían un gran numero de consultas rapidas a la BD deben examinarse en terminos de potencial de optimizacion, en funcion de los enfoques presentados.
- Minimizar el esfuerzo de busqueda: es posible de aplicar mediante índice.
Indices de BD en BD clásicas: un índice consta de campos seleccionados de la tabla BD, que se copian en una secuencia ordenada en una estructura separada.
Existen índices primarios y secundarios.
El primario contiene lo campos de clave principal. Por lo tanto, este índice es único y solo puede haber un registro de datos para cualquier combinacion de los campos de este índice.
siempre se crea automaticamente en los sistemas SAP cuando crea una tabla.
Luego estan los índices secundarios, que pueden ser únicos o no únicos. Estos son creados en el DDIC.
Normalmente se usan para optimizar el rendimiento pero tambien 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 definicó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 indices secundarios se crearán solo par alas tablas BD donde los accesos de lectura son más críticos en el tiempo que lo saccesos de escritura, ya que cada índice creado debe mantenerse para los accesos de escritura.
El numero de índices y campos creados en el índice debe mantenerse lo mas pequeño posible. De lo contrario, se requiere más esfuerzo para cambiar los accesos a la BD y el optimizador es más probable que tome decisiones erróneas.
Los campos en lo sque se crean lo sí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 tambien 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 índice.
Para formular las clausulas where, el operador = y los enlaces AND siempre son compatibles de manera eficiente en el índice, es decir el optimizador para reducir el esfuerzo E/S siempre que sea tecnicamente posible, una lista de IN tambien entra en esta categoria porque representa en principio un multiplo = para la columna. Por lo tanto, se debe usar las condiciones = y IN siempre que sea posible. Se debe evitar las condiciones negativas como un EQUAL, DISTINCT porque no se pueden admitir de manera eficiente en el índice, si es posible se debe incluir tales condiciones como condiciones de forma positivo.
Indices de la BD en SAP HANA: con SAP HANA, se puede distinguir entre índices invertidos y compuestos.
Los indices compuestos tienen un requisito de memoria más alto debido a las estructuras de memoria para una columna interna adicional.
Por lo tanto, se recomienda trabajar lo más prosible 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 indices tambien 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 s edeben mantener múltiples estructuras de memoria.
Si se está migrando un sistema existente a 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 no son suficientes sin un índice. En este caso, se debe crear un índice para las condiciones selectivas, siempre que no esén cubiertas por el índice primario.
Significado de la Regla 4 para SAP HANA: una aplicación coherente de esta cuarta regla para BD clásicas lleva a un menor esfuerz de E/S, optimiza el consumo de memoria en el caché, reduce el consumo de CPU y optimiza la transferencia de red porque se transfieren menos datos.
La cuarta regla cambia en SAP HANA, y su cumplimiento tiene una prioridad más baja porque en muchos casos no se requerie ningun índice en SAP HANA. Si se requerie un índuce para tablas muy grandes, las reglas para la definicio del índice cambian.
En estos casos, el consumo de CPU se reduce por el índice.
En SAP HANA, los índices genralmente se rean para columnas individuales.
Los índices que abarcan varias columnas son la excepcón.
- Reducir la carga en la BD: la BD es un recurso central en el sistema SAP. Por este motivo, se debe mantener la carga para operaciones repetidas en la BD lo mas pequeña posible.
Utilizando Buffers: los siguientes buffers cross usuario estan disponibles en el servidor de aplicaciones: Objetos compartidos, Buffer compartido, memoria compartida, buffer de tabla.
Los siguientes buffers especificos del usuario también están disponibles dentro de una sesion de usuario: memoria SAP, memoria ABAP, programacion especifica 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 BD tambien para SAP HANA.
Esto se debe a que, entre otras cosas, la memoria principal del servidor de aplicaciones se encuentra en el mismo servidor en el que se ejecuta el programa ABAP.
El acceso al buffer de la tabla es aproximadamente 10 veces mas rapido que el acceso a los datos en la BD.
Las reglas siguen siendo las mismas para los demas buffers (por ejemplo, objetos compartidos, memoria compartida, buffer compartido, tablas internas, memoria ABAP, memoria SAP).
Esto significa que se debe continuar almacenando en dichos buffers todos los datos que requieren muco mas tiempo para obtener o calcular, y cualquier dato utilizado más de una vez. Esto aliviará la BD de consultas costosas repetidas.
Ordenando: si el ordenamiento en la BD no se puede asignar a través de un índice que se utiliza para la seleccion entonces se debe ordenar con el AS ABAP, especialmente si la aplicacion 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 relacion con el valor del pedido) el ordenamiento debe realizarse en la BD.
Evitando accesos idénticos: se debe evitar la lectura múltiple de datos idénticos.
Esto no solo reduce el número de accesos a la BD (tal como se menciona en la regla 3) sino que también evita cargas innecesarias en la BD.
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 BD clásicas conduce a un menor consumo de CPU y a una carga reducida en la red.
El esfuerso de E/S también puede reducirse evitando accesos múltiples.
Tambien 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 BD de accesos innecesarios.
Esto significa, por ejemplo, que se puede ejecutar cálculos complejos a través de la inserción de código en la BD 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 ejecucion de cálculos complejos en grandes conjuntos de datos.
Se debe ejecutar dichos cálculos en la BD.
Sin embargo, no tiene sentido enviar siempre los mismos cálculos o accesos a los mismos datos a la BD.
por este motivo, se puede formular la quinta regla para SAP HANA de la siguiente manera:
Aliviar la BD de accesos innecesarios.
Asi formulada, esta regla se alica sin cambios y con la misma prioridad a SAP HANA porque los recursos de la CPU y de la red tambien se pueden liberar de la misma forma.