Notas SAP sobre SAP BPC 10.0 NW powered by SAP HANA

Si tienes la suerte de estar trabajando con SAP HANA como plataforma y base de datos in–memory computing, o simplemente te estas preparando para cuando surja la oportunidad, una Nota SAP que deberías tener presente es la …


Si tienes la suerte de estar trabajando con SAP HANA como plataforma y base de datos in–memory computing, o simplemente te estas preparando para cuando surja la oportunidad, una Nota SAP que deberías tener presente es la 1734706, este documento agrupa las referencias a las notas de SAP de SAP Business Planning and Consolidation sobre SAP HANA (HANABPC), no contiene todas, pero figuran las más relevantes

Referencia: NT 1734706

¿SAP HANA-Optimized Infocubes?

En el anterior post se señalaba cómo SAP BPC NW 10.0 se puede beneficiar si se configura sobre SAP HANA y se utilizan los cubos optimizados. Si se lleva SAP NW BW sobre una plataforma SAP HANA (SAP NW BW powered by SAP HANA) el criterio que debería predominar es que se aplique toda la tecnología que nos permitirá obtener el mayor beneficio del procesamiento in-memory computing. Unas de estas técnicas a poner en marcha son los denominados SAP HANA Optimized Infocubes.


En el anterior post se señalaba cómo SAP BPC NW 10.0 se puede beneficiar si se configura sobre SAP HANA y se utilizan los cubos optimizados (Nota: SAP BPC NW 10.0 requiere SAP NW BW 7.3 y SAP NW BW 7.3 puede ser configurado sobre SAP HANA).  Si se lleva SAP NW BW sobre una plataforma SAP HANA (SAP NW BW powered by SAP HANA) el criterio que debería predominar es que se aplique toda la tecnología que nos permitirá obtener el mayor beneficio del procesamiento in-memory computing.  Unas de estas técnicas a poner en marcha son los denominados SAP HANA Optimized Infocubes.

Estos infocubos optimizados para SAP HANA se basan en que en la construcción del denominado “modelo en estrella”, físicamente no se crean tablas de dimensiones, ratios y características físicamente son incluidos en la tabla de hechos.  El concepto de dimensiones tal como se conoce en entornos BW se mantiene, como un “concepto lógico” con el fin de facilitar el uso de herramientas como BEx Query Designer.  Esta arquitectura, unida al almacenamiento en columnas, y la ausencia de dos tablas de hechos (Tabla E, datos comprimidos y Tabla F, datos de entrada no comprimidos) optimizará el rendimiento de cualquier aplicación.

Para convertir un tradicional infocubo a un infocubo optimizado, se utiliza una transacción que permite seguir utilizando la plataforma a los usuarios (excepto las cargas de datos), la operación de conversión tardará en función del volumen de datos, algunas estimaciones señalan entre 10 y 20 minutos para cubos con cientos de millones de registros.  Para esta conversión sólo se espera que el cubo origen no tenga más de 233 ratios (key figures) y un máximo de 248 características.

Referencias: aquí

Fórmulas para el “sizing” en SAP HANA

Según SAP, la vía “más segura” o recomendable para estimar las necesidades de hardware de un nuevo producto como puede ser SAP HANA, es el uso del Quick Sizer. Pero además de los resultados que se pudieran obtener con esta herramienta, para el caso de SAP HANA, existen unas fórmulas que brindan valores preliminares que no se alejarían de los valores definitivos.


Según SAP, la vía “más segura” o recomendable para estimar las necesidades de hardware de un nuevo producto como puede ser  SAP HANA, es el uso del Quick Sizer.  Pero además de los resultados que se pudieran obtener con esta herramienta, para el caso de SAP HANA, existen unas fórmulas que brindan valores preliminares que no se alejarían de los valores definitivos.

El sizing consiste en estimar las necesidades de memoria, almacenamiento en disco y la capacidad de procesamiento (CPU).  Las fórmulas son las siguientes:

  • Memoria. Para el cálculo de este valor se toma como referencia el tamaño utilizado actualmente, ya sea por el actual SAP NW BW y/o SAP ERP, considerando que no se debería incluir el espacio utilizado por logs, temporales y agregados (en el caso de BW).  Toda la información será cargada en memoria, pero para este fin SAP HANA utiliza mecanismo de compresión que por norma general equivalen a la quinta parte.  Así mismo, para procesos internos, HANA necesita espacio, que se estiman igual al tamaño utilizado por los datos, una vez cargados en memoria.

Memoria = ((Espacio actual) / 5) * 2

  • Disco. Se estima en función del valor obtenido en el cálculo de las necesidades de memoria. Se calcula tanto para datos, como para los logs de transacciones, cada uno de estos datos se obtienen en cada factor de la siguiente fórmula:

Disco = (Memoria * 4) + (Memoria)

  • CPU (basado sobre el número de cores que incluyen) se debe estimar en función del número de usuarios activos, los cuales pueden fluctuar entre 20% y 40% del número de usuarios nominales.  Se estima que para gestionar un usuario activo se requiere 0,2 de un core de CPU:

CPU = 0,2 * (Usuarios activos)

Information Composer para el «self service» en SAP HANA

Tener la base de datos más veloz del mundo sirve de muy poco si los usuarios de negocio contaran con datos adicionales, necesarios para su análisis, y tuviesen que esperar que el equipo técnico responsable los cargue y los prepare para que los puedan utilizar. Para evitar este tipo de situaciones, SAP ofrece una aplicación Web como parte de su plataforma SAP HANA para que los usuarios de negocio “avanzados”, con la debida autorización, puedan hacer básicamente dos cosas: Cargar ficheros de datos personales (Upload) y preparar vistas de información HANA para procesar sus datos (Compose).


Tener la base de datos más veloz del mundo sirve de muy poco si los usuarios de negocio contaran con datos adicionales, necesarios para su análisis, y tuviesen que esperar  que el equipo técnico responsable los cargue y los prepare para que los puedan utilizar. Para evitar este tipo de situaciones, SAP ofrece, Information Composer, una aplicación Web como parte de su plataforma SAP HANA para que los usuarios de negocio “avanzados”, con la debida autorización, puedan hacer básicamente dos cosas: Cargar ficheros de datos personales (Upload) y preparar vistas de información HANA para que puedan procesar sus datos (Compose).

Evidentemente no hay punto de comparación entre SAP HANA Studio y SAP HANA Information Composer (IC), lo único en común, es que ambas son aplicaciones cliente, por lo demás, sobran las diferencias, Studio es la herramienta completa que utilizarán los usuarios técnicos encargados del modelado de datos.

En Information Composer se pueden cargar ficheros MS Excel (.xls o .xlsx) ficheros delimitados por comas (.csv) o lo que hubiese en el portapapeles (clipboard).  Luego de seleccionar la fuente origen, los datos podrían ser “depurados” (modificación y eliminación de valores o combinación de columnas) y luego clasificados (identificación de las columnas que serán tratadas como atributos  y cuales como medidas), para finalmente guardar los datos en la base de datos SAP HANA.

No siempre el usuario deberá cargar datos, podría utilizar directamente la funcionalidad para diseñar vistas de información.  La funcionalidad Compose permite diseñar una nueva vista a partir de otras dos vistas o de los datos que hubiese cargado el usuario.  La vista resulta, al igual que los datos, podrían ser compartidos con otros usuarios.

Referencias: (aquí, aquí y aquí)

SAP HANA Database, una base de datos que procesa en memoria y también almacena en disco

Cuando se señala que SAP HANA es una base de datos in-memory computing (procesamiento en memoria) o cuando se explica que los datos constantemente están en la memoria principal, la primera preocupación que surge en forma de pregunta es ¿qué sucede si se produce un corte de energía?


Cuando se señala que SAP HANA es una base de datos in-memory computing (procesamiento en memoria) o cuando se explica que los datos constantemente están en la memoria principal, la primera preocupación que surge en forma de pregunta es ¿qué sucede si se produce un corte de energía?

La principal razón que explica la rapidez de SAP HANA en sus tiempos de respuesta, es que los datos siempre se encuentran en la memoria principal, la cual por sus características, libre de piezas mecánicas como las que tienen los disco duros (dispositivos utilizados en las tradicionales bases de datos), permite alcanzar tiempos de acceso hasta 100.000 veces menores que la denominada memoria secundaria o discos duros.

La memoria utilizada en la memoria principal es volátil, es decir, ante un fallo o corte en el suministro eléctrico, todos los datos cargados en memoria se pierden, por este motivo SAP HANA también almacena los datos en disco, pero como una operación en segundo plano, con una frecuencia por defecto de 5 minutos, HANA graba en disco los cambios realizados a los datos, sin interrumpir o ralentizar el procesamiento de la información.  

En HANA los datos en memoria son agrupados en páginas, cuando una transacción cambia los datos, la página que contiene las modificaciones es «marcada» para luego guardarla en disco en los intervalos regulares que se hallan definido.  Por otro lado,  todas las operaciones con los datos son guardado en logs contenidos en dispositivos no-volátiles. De este modo, si ocurriese un fallo en el suministro eléctrico, SAP HANA podría reiniciarse cargando todas sus páginas de datos con los últimos cambios realizados.  Quizás al hablar sobre SAP HANA, además de señalar que es “in-memory Computing” a continuación deberíamos señalar “with hard disk storage” o algo similar que haga hincapié que los datos también se guardan en disco.