Archivo de la etiqueta: SAP HANA Performance

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


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

Anuncios

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:

  • 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. 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.

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.

Reglas de oro para diseñadores SAP HANA


En SAP SCN encontramos un post que será muy útil para todos aquellos que estén comenzando a diseñar modelos de datos o a desarrollar aplicaciones en una plataforma SAP HANA. Por el momento se señalan seis “reglas de oro” que seguro se podrán ir ampliando en la medida que SAP HANA siga evolucionando al ritmo que lleva, presentando grandes cambios en cada actualización.

  1. Nunca utilices tablas con almacenamiento basado en filas.  SAP HANA está preparado para trabajar con los dos tipos de almacenamiento de tablas (basado en filas y en columnas), el sistema ya cuenta con mecanismos necesarios para optimizar la grabación de datos en tablas con almacenamiento columnar.  Una de las claves de éxito de HANA es el almacenamiento en columnas, son muy pocos los casos en que se recomienda las tablas con almacenamiento en filas, especialmente la tablas de parámetros o configuración.
  2. No crear índices. El almacenamiento columnar, equivale a tener un índice por cada columna, por lo que crear índices secundarios, tal como se estila hacer en un sistema de base de datos relacional tradicional, no ayuda a reducir los tiempos de acceso a los datos.  Sólo podría ser útil en el caso de tener una tabla muy grande sobre la que se realiza una selección muy pequeña de un conjunto de datos.
  3. Utilizar la Perspectiva Development de SAP HANA Studio.  SAP HANA Studio es la herramienta que facilita todas las tareas de administración y desarrollo en la plataforma HANA.  Las capacidades que ofrece SAP HANA Studio están divididas en Perspectivas (véase como paneles o ventanas), dependiendo de las necesidades y autorizaciones disponibles se podrán habilitar las perspectivas. Para los desarrolladores se ofrecen varias perspectivas entre ellas System, Modeler  y Debug, se sugiere el uso de la perspectiva Development, debidamente configurada se puede contar con todos los recursos necesarios en una única perspectiva.
  4. No utilizar SQLScript, a menos que sea necesario.  SAP HANA ofrece una implementación SQL, la cual se denomina SQLScript, este lenguaje puede ser muy útil en determinadas circunstancias, pero en muchos casos lo que se realice con este lenguaje se podría hacer con vistas de información (de atributos, analíticas y de cálculos) las cuales son más eficientes dado que SQLScript no paraleliza la ejecución de procesos (hasta la reciente actualización SPS07 este es el comportamiento de SQLScript, quizás más adelante se ofrezca una actualización que mejore este comportamiento).
  5. Si utiliza SQLScript, no utilice cursores o SQL dinámico. El uso de estas sentencias ocasiona pérdida de rendimiento, especialmente el uso de SQL dinámico para referirse a nombres de columnas en sentencias INSERT o SELECT, hay otras alternativas disponibles, como las vistas de información (para los SELECTs) o el uso del lenguaje Python (para cargar datos).
  6. Evitar Joins en grandes volúmenes de datos. Unir tablas con más de cien mil filas resultará ineficiente, en su lugar se sugiere normalizar vía el uso de vistas analíticas, para luego unir vía una vista calculada.

Referencia: SAP SCN

CPUs de un sistema SAP HANA a la máxima frecuencia


Puede suceder que después de reiniciar un sistema SAP HANA o realizar una actualización del sistema, se observe que los CPUs no estén trabajando a la máxima frecuencia disponible. Existe la posibilidad de monitorizar esta información a través de la vista M_HOST_INFORMATION la cual sólo se actualiza al iniciar el sistema.

Consulta de la frecuencia de los procesadores en un sistema SAP HANA

Las diferencias entre las frecuencias del “CPU model” y el “CPU clock” se podrían deber a la parametrización del denominado “CPU governor”, parámetro a nivel del sistema operativo (SUSE Linux), que para el caso de un sistema SAP HANA, en el que se espera un sistema de alto rendimiento y un sistema de bases de datos con procesamiento paralelo, no debe tener asignado ningún valor equivalente a ahorro de energía (“ondemand” o similar), el valor recomendado es “performance”. En los enlaces de referencia se explica el procedimiento para ajustar este parámetro.

Referencia: SAP Note 1890444 y OpenSuse.org