Archivo de la etiqueta: SAP HANA – Administration

Aplicaciones y funcionalidades de SAP BusinessObjects Cloud


SAP BusinessObjects Cloud es la plataforma SaaS (Software as a Service) de SAP para el Business Intelligence y planificación, en algún momento se denominaba SAP Cloud for Analytics, pero al ampliarse funcionalidades, SAP encontró el pretexto para cambiarle el nombre. Esta propuesta SaaS se base sobre la plataforma SAP HANA Cloud.

SAP BusinessObjects Cloud, aplicaciones y funcionalidades

Dependiendo la suscripción contratada, se puede disponer de las siguientes aplicaciones:

  • SAP BusinessObjects Cloud for Business Intelligence
  • SAP BusinessObjects Cloud for Planning
  • SAP BusinessObjects Cloud for Predictive Analytics
  • SAP BusinessObjects Cloud for Governance, Risk and Compliance (GRC).

 Actualmente SAP BO Cloud tiene las siguientes capacidades:

  • Conectividad en tiempo real. Acceso en tiempo real a fuentes SAP HANA (on-premise y cloud)  a través del denominado “Live conecction”. A futuro se prevé acceso a BW y S/4HANA.
  • Adquisición de datos. Replicación de datos en SAP BusinessObjects Cloud desde fuentes BW, Universos, SAP BPC NW, SAP BPC MS, ficheros planos, Salesforce.com y Google Drive.
  • Visualización. Diseño de visualizaciones orientadas al negocio, personalización de pantallas, funcionalidades avanzadas de repoting y exportación a PDF.
  • Colaboración. A través de la aplicación móvil se ofrece funciones de chat,  visualización de eventos y tareas, gestión de notificaciones.
  • Administración. Gestión de usuarios y equipos, Monitorización.
  • Auditoria. Monitorización del rendimiento para un usuario o un modelo en cualquier período de tiempo.

Es posible contratar este servicio como una nube pública (multiple tenants) o nube privada, la diferencia se encuentra si se desea compartir recursos (no datos) con otros suscriptores o se desea unos recursos para uso exclusivo. Con recursos nos referimos a la capacidad y tiempo de procesamiento, memoria, aplicaciones y sistema operativo. En ambos casos se olvidaría de mantener las aplicaciones y la infraestructura que estas requieren, lo usual en una instalación clásica u on-premise.

De “powered by SAP HANA” a “edition for SAP HANA”


La arquitectura de todos los componentes o productos SAP, con futuro, vienen siendo revisados y redefinidos para que funcionen utilizando el potencial de SAP HANA Database de la mejor manera. Así, inicialmente fueron introducidos los “aceleradores”, los cuales básicamente replican las tablas más relevantes de una aplicación en HANA, obteniéndose un mejor tiempo de respuesta.

Recorrido de SAP BW hacia SAP HANA

Posteriormente hemos venido viendo soluciones “powered by SAP HANA” o simplemente “on SAP HANA”, caracterizadas por llevar, con mínimos cambios, los modelos de datos de las aplicaciones a SAP HANA y por consiguiente, el procesamiento de los datos es ejecutado en memoria obteniéndose importantes mejoras en los tiempos de respuesta.

Cambios en los objetos de SAP BW 7.5

El cambio más disruptivo que se está dando por SAP HANA es la irrupción de una nueva generación de aplicaciones, las denominadas “edition for SAP HANA”. La cual prescinde de todos los elementos u objetos que tuviese la aplicación original e impiden que sea más eficiente y veloz en SAP HANA. El primero y más relevante representante “edition for SAP HANA” es SAP BW 7.5, del cual destacamos los siguientes cambios:

  • La clásica interface SAP GUI del denominado Data Warehousing Worbench es sustituida por el denominado BW Modelling tolos in Eclipse.
  • Las funcionalidades o herramientas para el modelado BW han sido adaptadas en el entorno de modelado SAP HANA. Por el momento, hay algunos objetos que deben ser definidos en el Data Warehousing Workbench.
  • Algunos objetos ya no son soportados y serán sustituidos por uevos tipos de objetos especialmente diseñados para SAP HANA. En este enlace puedes ver estos cambios: aquí.
  • SAP Business Explorer (BEx) ya no será soportado nunca más (esto ya  lo han dicho más de alguna vez.  :-I). Las consultas o queries serán definidas con las herramientas de modelado BW de SAP HANA. Para la visualización de datos se recomienda el uso de Analysis for Office o Design Studio (o SAP BusinessObjects Lumira).

Road map de SAP BW

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

Los LOBs Hibridos de SAP HANA Database


Como veíamos en la entrada anterior, con los tipos de datos LOB de SAP HANA es posible almacenar datos de gran tamaño, tales como documentos, imágenes o videos. Ahora bien, pero toda esta información dentro de una estructura de tablas de la base de datos podría significar un gran consumo de recursos de manera innecesaria.  Desde la actualización SPS 07 de SAP HANA están disponibles los denominados LOBs híbridos, los cuales estarán en memoria sólo cuando son utilizados.

Con los LOB híbridos se puede almacenar datos LOB en el disco hasta que se necesite en lugar de tener que cargarlos en la memoria. Esto influye en el consumo de recursos, por lo tanto afecta a la puesta en marcha del sistema y los tiempos de respuesta. SAP HANA puede almacenar objetos binarios grandes (LOB) en el disco y no dentro de estructuras de columnas o filas de la memoria principal.

Los LOB híbridos residen primero en el disco y se hace referencia a este contenido únicamente por un ID en la columna de la tabla correspondiente. Si hay escasez de memoria, los datos LOB pueden ser descargados desde la memoria principal. A través de unos parámetros del sistema se puede determinar que los datos LOBs pequeños (por defecto, menos de 1.000 bytes) se mantengan en memoria, mientras que los de tamaño superior se mantengan en el disco.

Los cambios que introdujo la actualización SPS 07 de SAP HANA Database sobre los datos LOBs, derivó a que se introdujeran los términos  LOBs de memoria (el mecanismo inicial) y LOBs Híbridos (o LOBS de disco). SAP HANA ofrece un conjunto de sentencias SQL que permiten la parametrización, creación y gestión de estos tipos de datos.

Almacenamiento de gran tamaño en SAP HANA: Campos LOBs


Si estas necesitando almacenar contenidos de gran tamaño, tales como documentos o imágenes en una plataforma SAP HANA Database, debes pensar en los tipos de datos LObs (Large Objetcs), especialmente diseñados para este fin. Existen los siguientes tipos:

  • BLOB: Datos binarios. Por ejemplo, imágenes. Para tablas con almacenamiento por filas y columnas.
  • CLOB: Texto ASCII. Para tablas con almacenamiento por filas y columnas.
  • NCLOB: Texto UNICODE. Para tablas con almacenamiento por filas y columnas.
  • TEXT: Texto con características adicionales de búsqueda. Sólo para tablas columnares. Muchas funciones de cadenas no son aplicables a este tipo de dato.
  • BINTEXT: Texto y datos binarios con características adicionales de búsqueda. Con similares restricciones al tipo TEXT.  La definición de este tipo de dato genera una columna de tipo NCLOB.
  • Nota: El tipo de dato VARBINARY, a pesar que puede almacenar hasta 5.000 bytes no es considerado un tipo LOB, por lo que se carga en memoria cuando se acceda sin ninguna restricción como las que se podrían aplicar con los LOBs híbridos, señalados en próxima entrada.

Restricciones de los tipos de datos LObs

  • Un campo de un tipo LOB sólo puede tener un máximo de 2 GB. Hay alertas que permiten controlar esta situación (Check ID 450 – Tables with memory LOBs > 2 GB).
  • Una columna LOB no puede ser utilizada con la cláusula ORDER BY, GROUP BY, SLECT DISTINC, SELECT con funciones de agregación, FROM como operando en joins.
  • Una columna LOB no puede ser clave primaria

Tratamientos de cadena soportados

  • LENGTH para los tipos CLOB, NCLOB y BLOB. Retorna el tamaño de campo LOB en bytes.
  • SUBSTR para los tipos CLOB y NCLOB. Retorna una subcadena del campo LOB.
  • Las clausulas LIKE y CONTAINS para los tipos CLOB y NCLOB.
  • Cláusula IS NUL sólo para los tipos CLOB, NCLOB y BLOB.

Nota: Ver siguiente entrada sobre LOBs híbridos.

Referencia: SAP Note 2220627

Terminología sobre Correcciones y Mejoras en SAP HANA


En cuanto a las correcciones y mejoras que pueden liberarse en SAP HANA, existe una terminología similar a otras plataformas de SAP, quizás con ciertos matices que tratamos de aclarar a continuación:

  • Revisions. Se trata de correcciones para los componentes centrales o core tales como SAP HANA Database, Clientes, Application Fuction Library o SDA).
  • Support Packages (SP). Incluye correcciones o mejoras de todos los demás componentes de SAP HANA, que no cubre una revisión.
  • Support Package Stack (SPS). Se trata de nuevas capacidades o funcionalidades, las cuales tienen una ferecuencia de dos vesces al año. Incluyen las revisiones o SP previos.

La numeración de las SPS y revisiones están alineadas para facilitar su identificación. Por ejemplo, la revisión 90 se refiere a la primera revisión del SPS 09.

Revisiones, SP y SPS de SAP HANA

La distribución de tablas en SAP HANA


En un sistema de base de datos, las tablas pueden ser distribuidas en distintos hosts para brindar balanceo de carga y evitar problemas de tipo OOM (Out of memory). En SAP HANA la distribución de tablas sólo es posible en un escenario Scale-out (uso de múltiples procesadores como una sola entidad), a través de los siguientes mecanismos:

  • Diferentes tablas asignadas a diferentes Index Servers (Particionamiento de base de datos y distribución de tablas).
  • La misma tabla dividida a través de multiples Index Servers (Particionamiento de tablas)

Por defecto, las nuevas tablas se distribuyen en los Index Server disponibles, sin embargo es posible especificar que una tabla o partición se cree en uno en concreto. Por otro lado, existe la posibilidad de realizar una redistribución de tablas, la cual podría plantearse en los siguientes casos:

  • Antes de retirar un host
  • Después de adicionar un host
  • Optimizar la distribución de tablas actual
  • Optimizar la partición de tablas existente

Por lo general, después de añadir o eliminar nodos, la redistribución (Landscape Redistribution) debe llevarse a cabo. En base a la configuración se sugerirá un nuevo panorama. En este proceso se considera sólo las tablas basadas en columnas (column-store tables), no son consideradas las tablas del sistema, temporales y basadas en filas (row-store tables).

En un sistema SAP NW BW sobre SAP HANA, los datos son distribuidos, grosso modo, del siguiente modo:

  • Nodo Principal: Contiene las tablas con almacenamiento basado en filas, tablas del sistema ABAP y datos operacionales generales.
  • Nodo Esclavo o Worker Node: Contiene todos los datos maestros de BW, cubos, DSO y PSAs

Nota: Quizás, sea útil tener presente los siguientes conceptos:

  • Un host es una máquina (compuesto por CPU, memoria, almacenamiento, red y sistema operativo) que ejecuta parte del sistema SAP HANA.
  • Un sistema distribuido SAP HANA, es un sistema que es instalado en más de un host.
  • Una instancia SAP HANA es un conjunto de componentes de un sistema distribuido que es instalado en un host.
  • Cada instancia tiene un “index server”, “preprocessor server” y “name server”. El “statistic server” existe sólo uno por sistema.

Referencia: SAP Note 2081591

SAP HANA Smart Data Access


Desde la actualización SPS 06 de SAP HANA, existe la característica Smart Data Access, la cual consiste en acceder a datos externos sin tener que replicarlos en SAP HANA. Esta técnica, grosso modo, consiste en crear tablas virtuales en HANA que apuntan a tablas remotas ubicadas en distintas fuentes, luego de lo cual se podrían escribir consultas SQL en SAP HANA las cuales serían ejecutadas en la base de datos correspondiente y el resultado sería devuelto a la consulta HANA para completar la operación.

La comunicación entre SAP HANA database y la base de datos remota es vía ODBC (los drivers de la BBDD remota deben ser instalados), a partir de la reciente actualización SPS 10 se soportan las siguientes fuentes de datos: SAP HANA, SAP IQ, SAP ASE, SAP Event Stream Processor, SAP MaxDB, Teradata Database, Microsoft SQL Server 2012, Oracle 12c, IBM DB2, Hadoop Hortonworks HDP 2.3, IBM Netezza Appliance.

Los usos sugeridos por SAP son los siguientes:

  • Abordar proyectos Big Data conectándose a Hadoop para analizarlos con datos SAP HANA.
  • Utilizar datos inactivos (cold storage) aquellos que muy rara vez se acceden y se desean combinar en consultas con datos de uso frecuente (hot data) en SAP HANA.
  • Crear aplicaciones SAP HANA que accedan a diversas fuentes de datos.
  • Adicionalmente, cabe señalar que a través de la tabla virtual es posible realizar todo tipo de operaciones sobre la tabla remota, tales como seleccionar, actualizar, insertar, eliminar, etc.

Referencias: Notas SAP 2180119 y 18668209

El consumo de CPU en SAP HANA


En SAP HANA un alto consumo de CPU puede ser normal y aceptable, dado que el sistema podría estar utilizando los CPUs disponibles para la paralelización de operaciones complejas. Si el sistema estuviera procesando peticiones de base de datos simples con una gran cantidad de consumo de CPU, esto podría significar un cuello de botella crítico que podría evitarse, analizando y optimizando el consumo de CPU innecesarios.

Tipos de consumo de CPU

El consumo de CPU puede tener los siguientes tipos u orígenes:

  • User. El consumo de CPU se origina fuera del núcleo del sistema operativo, tales como operaciones que recorren tablas de gran tamaño o recuentan valores distintos. Operaciones de productos “no SAP HANA”, que se ejecutan en el mismo host, también podrían ser los causantes de un consumo elevado de CPU.
  • System. Se trata del consumo de CPU originado en núcleo del sistema operativo, por ejemplo: operaciones en segundo plano como la desfragmentación de la memoria o tiempos de espera por bloqueos y operaciones de E/S.
  • I/O Wait. Los tiesmpos de CPU para completar operaciones de E/S, pueden ser considerados como tiempo de inactividad.

 Cómo monitorizar el consumo DE CPU

Como la gran mayoría de tareas de administración y modelado de datos, el seguimiento del consumo de CPU se realiza en SAP HANA Studio a través de las siguientes vías:

  • Administration >> Overview >> CPU Usage
  • Administration >> Performance >> Load >> [System] CPU
  • Adicionalmente, a través de sentencias SQL (HANA_Resources_CPUAndMemory_History y HANA_Hosts_Overview) y definiendo algunos parámetros en el fichero global.ini se puede obtener mayor información.

Se debe tener presente que los casos típicos de un alto consumo de CPU pueden ser originados por sentencias SQL que requieran ser optimizadas (consumo de CPU del tipo User) o por consumo de tiempo de CPU del tipo System originadas por subprocesos tales como “garbage collection” con lentos accesos a tablas del sistema que requiere esta tarea. Para obtener más información sobre el consumo de CPU y cómo controlar su uso y monitorización, sugerimos la revisión períodica de documentos como la nota 2100040.

Las limitaciones y restricciones de SAP HANA


SAP HANA Database, al igual que cualquier otro motor de base de datos, tiene una serie de restricciones o limitaciones que se deben tener presente para garantizar el buen funcionamiento del sistema. A través de la nota 2154870 SAP señala las limitaciones y restricciones de sus base de datos en memoria. Muchos de los valores máximos señalados parecen más que suficientes, difícilmente de alcanzar, tales como las 16 columnas para conformar un índice o los 1.023 índices que puede tener una tabla.

A través de la vista M_SYSTEM_LIMITS se pueden obtener las principales restricciones, la cual puede variar según el nivel de actualización de la plataforma:, los siguientes valores corresponden a la actualización SPS 09:

Limitaciones de SAP HANA database a través de la vista M_SYSTEM_LIMITS

Otras restricciones que se deben tener presente son los siguientes:Otras restriciones de SAP HANA Database

Las siguientes limitaciones son configurables:Restrcciones SAP HANA parametrizables

Referencia: SAP Note 2154870