Etiqueta: SAP HANA Performance

Gestión de la carga de trabajo de SAP HANA (o Workload Management)

Toda gestión de recursos tiene como finalidad controlar su consumo, los cuales suelen ser limitados y de valor crítico, evitando cuellos de botella o contratiempos mayores. SAP HANA puede gestionar los siguientes tipos de carga de trabajo (Workload):


SAP HANA puede gestionar los siguientes tipos de carga de trabajo (Workload):

  • OLAP Workload: Por ejemplo, reporting sobre BW.
  • OLTP Workload: Por ejemplo, transacciones de un sistema ERP.
  • Workload mixto: Combinan los dos tipos de carga de trabajo anteriores, OLAP y OLTP, el cual se puede dar en sistemas transaccionales con funciones analíticas.
  • Workload interno: Generado por operaciones internas de SAP HANA, tales como backups, puntos de salvaguarda (savepoints).

Toda gestión de recursos tiene como finalidad controlar su consumo, los cuales suelen ser limitados y de valor crítico, evitando cuellos de botella o contratiempos mayores. Para el caso de SAP HANA, esta gestión se centra en la memoria, CPU y la Red (ancho de banda y latencia).

Para la gestión de la carga de trabajo de la memoria se puede configurar, entre otros, los siguientes aspectos:

  • Limitar el consumo de memoria para todas las sentencias SQL (desde la actualización SPS 08). Se debe tener en cuenta que la especificación es por host, si se señala un tope de 100 GB, y se tiene un escenario de escalabilidad horizontal (scale-out), los 100 GB se multiplicarán por el número de host que tuviese la instalación.
  • Limitar el consumo de memoria para sentencias SQL para un usuario en particular (a partir de la actualización SPS 09).
  • Establecer un consumo máximo de memoria por clase de carga de trabajo (a partir de la actualización SPS 10).

Ante un consumo elevado de CPU o los hilos de procesamiento (threads) activos, se sugiere, en primer lugar, realizar un análisis de rendimiento u optimización de los procesos que lo estuviesen provocando.  Adicionalmente se pueden establecer los siguientes límites.

  • Establecer un número máximo de hilos de procesamiento (threads). Si se superase este límite, el proceso generaría error.
  • Tiempo de espera en microsegundos antes de iniciar un nuevo proceso cuando se alcanza el límite máximo establecido.
  • Número de máximo de procesos concurrentes y otros parámetros que regulan el procesamiento paralelo.

En cuanto a la carga de trabajo de la red, si existiesen problemas debido a la latencia o ancho de banda, estos usualmente se resuelven optimizando la infraestructura de red. SAP HANA ofrece alertas y otros recursos para monitorizar el tráfico de la red, y algunos parámetros para determinar el comportamiento de los elementos que conforman una plataforma HANA (ver nota 2222200), pero que no serán tan gravitantes como puede ser una administración y monitorización de la red, ajena a HANA.

Referencia: SAP Note 2222250

Anuncio publicitario

Servidor de Estadísticas de SAP HANA

El servidor de estadísticas de SAP HANA (SAP HANA statistics server) es una herramienta de monitorización de la base de datos de SAP HANA, entre otras cosas, controla el rendimiento a través de las siguientes tareas:


El servidor de estadísticas de SAP HANA (SAP HANA statistics server) es una herramienta de monitorización de la base de datos de SAP HANA, entre otras cosas, controla el rendimiento a través de las siguientes tareas:

  • Verificación regular de situaciones críticas y generación de alertas.
  • Generación de información histórica de monitorización en tablas localizadas en el esquema _SYS_STATISTICS.

Para la consulta de la información generada por el servidor de estadísticas, hay una serie de sentencias SQL disponibles (Nota 1969700), en cuanto a las alertas, estas podrían ser monitorizadas y configuradas en SAP HANA Studio (la configuración de alertas se gestionan según el tipo de enfoque que se esté utilizando, ESS o SSS).

La implementación de las estadísticas tiene dos enfoques:

  • Embebido (Embedded Statistics Server , ESS). Denominado embebido porque se incluye dentro del Indexserver Process.
  • Independiente (Standalone Statistics Server, SSS). Es el enfoque antiguo, vigente, pero con importantes desventajas, tales como incremento del uso de memoria, innecesaria generación de datos históricos, datos históricos importantes no recopilados o recursos no compartidos con indexserver process.

Por lo expuesto en los párrafos anteriores, para el uso de estadísticas en SAP HANA, es recomendable el enfoque Embedded Statistics Server porque es más eficiente en el uso de recursos (memoria) y generación de información para la monitorización del sistema. Por otro lado, el enfoque Standalone ya no será mantenido, desde la revisión 74, SAP sugiere realizar la migración.

La migración se puede realizar manualmente, se debe tener presente que desde la actualización 93 las estadísticas Standalone Embebidas se activan automáticamente.

Referencia: Nota SAP 2147247

Solución de problemas de red en una plataforma SAP HANA

Si se percibe un problema de rendimiento en una plataforma SAP HANA, identificándose aumento de tiempos de acceso a los datos, quizás el problema no este centrado en SAP HANA sino en la red. SAP señala las causas que originarían problemas en la red y las acciones que podríamos realizar para comprobar y superar estos inconvenientes.


Si se percibe un problema de rendimiento en una plataforma SAP HANA, identificándose aumento de tiempos de acceso a los datos, quizás el problema no este centrado en SAP HANA sino en la red. SAP señala las causas que originarían problemas en la red y las acciones que podríamos realizar para comprobar y superar estos inconvenientes. Esta información, contenida en la nota 2081065, es aplicable a instalaciones SAP HANA SPS 08 (Revisión 80 – SPS = Support Package Stack) o con actualizaciones superiores.

Los aspectos que intervienen en el rendimiento de red, son los siguientes:

  • Latencia. Es el tiempo que tarda un paquete de cruzar una conexión de red, del emisor a receptor.
  • Ancho de banda (Bandwidth). Se refiere a la cantidad de datos que se puede llevar de un punto a otro en un período de tiempo (bps).
  • Pérdida de paquetes (Packet loss). Se refiere al fallo de uno o más paquetes transmitidos para llegar a su destino. De producirse, ocasionaría que el punto origen debería retransmitir el dato, percibiendo el usuario final un mal desempeño y retrasos.

Los problemas en la red, podrían repercutir en los siguientes aspectos en una instalación SAP HANA:

  • Comunicación entre los host SAP HANA (arquitectura Scale out u horizontal).
  • Comunicación entre SAP HANA Database y las aplicaciones cliente.
  • Replicación de base de datos SAP HANA.

Para encontrar las posibles soluciones a estos inconvenientes sugerimos la revisión de la nota de referencia.

Referencia: SAP Note 2081065

Particionado de Tablas en SAP HANA (y III) – Buenas Prácticas


A continuación señalamos algunas buenas prácticas (best practices) al definir particiones en SAP HANA Database. Cabe señalar que para los objetos BW on SAP HANA, la técnica de particionamiento es distinta (ver entradas anteriores: aquí y aquí):

  • Sólo aplicar el particionado de tablas cuando sea necesario y se observa un beneficio claro de esta técnica. Una alta cantidad de particiones innecesarias ocasionaría una sobrecarga en el sistema al ejecutar consultas, al tener que acceder a múltiples particiones para encontrar los datos solicitados.
  • Si se particiona por el límite de tamaño de tabla de los dos mil millones de registros, es aceptable si el tamaño de las particiones contienen hasta los 500 millones de registros.
  • Si el criterio de partición es por fecha, se debe evitar utilizar criterios granulares tales como día o semana, dado que generaría un gran número de particiones.
  • Si se utiliza el tipo de partición RANGE sobre una columna cuyo contenido no se distribuye uniformemente, se deben verificar la distribución de sus valores reales para definir los límites de los rangos en consecuencia
  •  Utilizar el menor número de columnas para definir el criterio de particionamiento. En el caso del tipo de partición HASH, a menudo es útil emplear sólo la columna clave más selectiva, para que las solicitudes de datos que incluye esta columna sólo accedan a una partición.
  •  Las buenas prácticas de los documentos de referencia, señalan que las particiones de una misma tabla estén contenidas en el mismo host si es que se cuenta con una estrategia scale-out (despliegue/escalabilidad horizontal)
  • Si se va a reparticionar una tabla, para lograr mayor eficiencia, elija un número múltiplo o divisor del número de particiones con respecto al actual.
  • Evitar la definición de particiones con restricciones únicas adicionales, por ejemplo índices secundarios, dado que las verificaciones posteriores significarían una sobrecarga importante.

Selección del motor para procesar consultas en BW on HANA

En entradas anteriores comentamos sobre los motores (engines) de SAP HANA, los cuales, según el tipo de consulta o cálculo, entran en ejecución para obtener los mejores tiempos de respuesta de todo un proceso que se demande. Para el caso de consultas en un entorno BW on SAP HANA, el motor especialmente diseñado y optimizado para este fin es OLAP Engine, es el que mejores tiempos de procesamiento debería brindar el ejecutar una consulta en SAP NW BW powered by SAP HANA.


En entradas anteriores comentamos sobre los motores (engines) de SAP HANA, los cuales, según el tipo de consulta o cálculo, entran en ejecución para obtener los mejores tiempos de respuesta de todo un proceso que se demande. Para el caso de consultas en un entorno BW on SAP HANA, el motor especialmente diseñado y optimizado para este fin es OLAP Engine, es el que mejores tiempos de procesamiento debería brindar el ejecutar una consulta en SAP NW BW powered by SAP HANA.

Sin embargo, analizando la ejecución de una determinada consulta puede ser posible que se observe que mejores tiempos de respuesta nos brinde el motor JOIN Engine, si fuese así, SAP señala que se trataría de un error el cual debería ser reportado a SAP Support.

Mientras se encuentre la solución al posible error señalado en el párrafo anterior, SAP ofrece un “workaround” el cual debe ser deshabilitado una vez que el problema se resuelva. La “solución temporal” consiste en señalar el motor que debe utilizarse, el cual puede ser señalado para todo el sistema (modificando el parámetro HDB_QUERY_ENGINE_SELECTION), un infoprovider (agregando una fila a la tabla RSDRS_HDB_ENGSEL) o para una determinada consulta (vía transacción RSRT). Para más información consultar la nota 1931671.