anibal goicochea

Los «Delta Merges» de SAP HANA

Las actualizaciones de las tablas con almacenamiento columnar de SAP HANA a través de sentencias tales como INSERT, UPDATE o DELETE no son inmediatamente volcadas a la base de datos, estos cambios son guardados en una zona, a la que podríamos calificar como intermedia, denominada “Delta Storage”. Estos datos serán actualizados en la base de datos (Main Storage) a través de un proceso denominado “Delta Merge” el cual se ejecuta en determinados períodos de tiempo.

Las actualizaciones de las tablas con almacenamiento columnar de SAP HANA a través de sentencias tales como INSERT, UPDATE o DELETE no son inmediatamente volcadas a la base de datos, estos cambios son guardados en una zona, a la que podríamos calificar como intermedia, denominada “Delta Storage”. Estos datos serán actualizados en la base de datos (Main Storage) a través de un proceso denominado “Delta Merge” el cual se ejecuta en determinados períodos de tiempo.

Este mecanismo resulta imperceptible para el usuario que explote o consulte la información, porque las operaciones de lectura tomarán en cuenta tanto los datos del almacenamiento principal como del Delta Storage. SAP HANA utiliza esta técnica para disminuir el acceso a disco y evitar la pérdida de rendimiento.

Las operaciones de Delta Merge se ejecutan en segundo plano, de manera automática o manual, forzada o condicionada. Información sobre cómo configurar, monitorizar y más información técnica sobre los Delta Merge puede encontrarse en la nota SAP 2057046.

SAP vuelve a cambiar nombres, esta vez en BPC 10.1

Podríamos señalar que el cambio de nombres a los productos y/o a los componentes que lo conforman, es el paso inevitable por el que transcurre la gran mayoría de productos SAP hacia su maduración. Esta vez, le ha tocado al recientemente estrenado SAP Business Planning and Consolidation 10.1 para NetWeaver.

Podríamos señalar que el cambio de nombres a los productos y/o a los componentes que lo conforman, es el paso inevitable por el que transcurre la gran mayoría de productos SAP hacia su maduración. Esta vez, le ha tocado al recientemente estrenado SAP Business Planning and Consolidation 10.1 para NetWeaver.

Tal como ya hemos comentado en alguna ocasión, en BPC 10.1 NW es posible crear entornos similares a los que conoces en la versión 10.0, a los que SAP nos enseñó, inicialmente, denominar como Clásicos (Classic). Por otro lado, en instalaciones de BPC 10.1 sobre SAP HANA, tenemos la posibilidad de crear estructuras para modelos de planificación que obtengan el máximo beneficio de la plataforma in-memory de SAP, esta otra categoría SAP nos indicó que se denominaba Unificado (Unified).

Pues bien, a través de la nota 2117885, SAP nos comunica que a partir del Support Package 3 (SP3) de BPC 10.1 NW, todo lo que conocíamos cómo Classic pasa a denominarse Standard y todo lo que conocíamos cómo Unified, ahora se denomina Embedded.

Alternativas Cloud para SAP BusinessObjects BI

Lo más usual para implementar una plataforma SAP BusinessObjects Business Intelligence es utilizando una infraestructura propia, modalidad usualmente denominada on-premise. Pero la alternativa Cloud o en la nube va ganando mayor aceptación en casos como en una plataforma SAP BusinessObjects BI, en la que las necesidades de recursos de hardware, especialmente memoria, pueden fluctuar en el tiempo.

Lo más usual para implementar una plataforma SAP BusinessObjects Business Intelligence es utilizando una infraestructura propia, modalidad usualmente denominada on-premise. Pero la alternativa Cloud o en la nube va ganando mayor aceptación en casos como en una plataforma SAP BusinessObjects BI, en la que las necesidades de recursos de hardware, especialmente memoria, pueden fluctuar en el tiempo.

En la actualidad SAP brinda soporte a la instalación de SAP BO BI sobre Amazon Web Services (AWS) y en SAP HANA Enterprise Cloud, en este último caso es desplegado y gestionado por SAP. Para la propuesta cloud de Microsoft, MS Azure, por el momento no se brinda soporte, pero hay planes futuros de incluirla en esta lista (para más información consulta la nota 2106331.

AWS ofrece servicios de infraestructura que pueden ser utilizados para el despliegue de productos de SAP. En la nota 1656099 se describe los productos de SAP, combinaciones de bases de datos/sistemas operativos y los tipos de instancia AWS EC2 compatibles y soportados actualmente.

Verdades a medias sobre SAP HANA (y Parte III)

Continuamos con la última entrega de esta serie (Parte I, Parte II) sobre las verdades a medias o conceptos erróneos que circulan sobre SAP HANA (más información en el documento de referencia):

Continuamos con la última entrega de esta serie (Parte I, Parte II) sobre las verdades a medias o conceptos erróneos que circulan sobre SAP HANA (más información en el documento de referencia):

En escenarios de escalabilidad horizontal (scale-out) las tablas con almacenamiento columnar no se almacenan en el nodo principal (master node). Es usual que varias tablas con almacenamiento en columnas se encuentren en el nodo principal en un escenario de escalabilidad horizontal. Pero es importante que las tablas de gran tamaño y/o críticas sean movidas a los nodos auxiliares o esclavos (slave nodes). Por ejemplo, en un entorno BW, infocubos, DSOs y PSAs deberían ser movidos a nodos esclavos.
En un escenario de escalabilidad horizontal el almacenamiento en filas es sólo en el nodo principal. Esta afirmación es correcta desde una perspectiva de aplicaciones, pero sin embargo, los nodos esclavos tendrán una mínima implementación técnica de tablas con almacenamiento en filas.
La sentencia UPDATE es siempre aplicable a operaciones DML (Data Manipulation Language). Esta afirmación no es siempre cierta. SAP HANA utiliza sentencias UPDATE también en operaciones DDL (Data Definition Language). Por ejemplo, la sentencia UPDATE para optimizar la compresión del almacenamiento columnar.
El motor Join (Join Engine) sólo procesa sentencias join. Esta afirmación es incorrecta. El motor join (ver aquí entrada sobre los motores SAP HANA) también es utilizado por ciertas consultas sobre una única tabla que realiza agregaciones o se utiliza la cláusula GROUP BY.

Referencia: SAP Note 2100010

Verdades a medias sobre SAP HANA (Parte II)

Continuamos con la entrada anterior, sobre las verdades a medias o conceptos erróneos que circulan sobre SAP HANA:

Continuamos con la entrada anterior, sobre las verdades a medias o conceptos erróneos que circulan sobre SAP HANA:

SAP HANA es una base de datos en memoria pura. SAP HANA es una base de datos en memoria, sin embargo, hay una serie de operaciones de lectura y escritura en disco que tienen impacto en el rendimiento global del sistema, tales como:
- Carga de tablas con almacenamiento en filas al iniciar el sistema
- Carga de columnas
- Acceso LOB (Large Objects)
- Ejecución de savepoints y snapshots
- Volcados a base de datos (commits)
- Copias de seguridad (backups)
Todas las tablas están permanentemente en memoria. No todas las tablas SAP HANA están permanentemente y completamente en memoria. Se debe tener presente lo siguiente:
- Las tablas con almacenamiento en filas y las columnas LOB no son cargadas en memoria.
- Las tablas con almacenamiento columnar no son cargas sino son utilizadas o son descargadas por problemas de memoria.
- Así mismo, la información histórica que muy rara vez se accede, no debería ser cargada en memoria
Las funcionalidades de almacenamiento en filas y almacenamiento en columnas están apartadas. Tradicionalmente estas dos técnicas o funcionalidades provienen de tipos distintos de bases de datos, pero en SAP HANA han sido integradas, por lo que ambos tipos de almacenamiento pueden ser combinados para procesar la información.