Categoría: In-memory computing

Cuando algo nuevo surge en el mundo de tecnología el desconocimiento se hace presente en forma de mitos, verdades a medias o conceptos erróneos. En el ámbito de SAP HANA esta situación ya se está produciendo, por ello SAP ofrece una breve aclaración de los conceptos que se están tergiversando.

A continuación señalamos los siguientes conceptos o afirmaciones erróneas:

• Todas las tablas de datos de SAP HANA se procesan con almacenamiento columnar (column-oriented). SAP HANA permite, tanto, tablas con almacenamiento en filas como en columnas. Las tablas con almacenamiento en filas son accedidas del mismo modo que las bases de datos relacionales tradicionales. Basándose en la experiencia y en el conocimiento, se puede decidir, de manera individualizada, que tipo de almacenamiento debe tener cada tabla para obtener el mejor rendimiento.
• El almacenamiento en columnas ofrece mejor rendimiento que el almacenamiento en filas. En algunos casos es así, por ello, SAP tiende al mayor uso posible de tablas con almacenamiento en columnas, pero sin embargo, hay algunos casos en que el almacenamiento basado en filas ofrece un mayor rendimiento. (aquí tips a tener en cuenta).
• Los índices no son necesarios. SAP HANA puede analizar grandes cantidades de datos, incluso sin la existencia de índices. Sin embargo hay situaciones en las que los índices son útiles, por ejemplo si se requiere realizar un acceso selectivo en repetidas ocasiones (para un entorno Business Suite on HANA, sugerimos la nota 1794297).
• Los índices no se conservan en el disco. Los índices conformados por más de una columna de las tablas con almacenamiento columnar, son generalmente almacenados en disco. Los índices conformados por sólo una columna, son considerados como parte de la definición o estructura de la columna, no son almacenados en disco, se recrean automáticamente cuando la columna es cargada. Los índices de las tablas con almacenamiento en filas no se almacenan en disco, se crean cada vez que el sistema se pone en marcha.

La principal técnica que utiliza SAP HANA Database para ofrecer un inmediato acceso a la información es manteniendo los datos en memoria, si la información fuese actualizada, estos cambios se reflejarían tanto en la memoria como en disco, es en este punto que interviene el concepto de Savepoints (aquí más información).

Los datos que se cargan a memoria son agrupados en “páginas”, todas las páginas que fuesen modificadas en un período de tiempo determinado, son volcadas a disco en los denominados Savepoints (el cual podríamos traducir como “puntos de sincronización” o “puntos de salvaguarda”).

Es una instalación del tipo “scale-out” conformada por más de un host, se debe tener en cuenta que cada host gestionará sus propios Savepoints.

La disponibilidad de un savepoint reciente conllevará a un reinicio del sistema más rápido porque habrá menos logs que procesar. Un Savepoin es desencadenado por las siguientes vías:

• Intervalo predefinido. La parametrización por defecto establece que automáticamente habrá un punto de salvaguarda cada 5 minutos (global.ini >> [persistence] >> savepoint_interval_s = 300).
• Comando del sistema. Puede utilizarse una sentencia en SAP HANA Studio para ejecutar un savepoint manualmente (ALTER SYSTEM SAVEPOINT)
• Cierre del sistema del tipo Soft. Un “soft shutdown” ejecuta un savepoint antes de detener los servicios. Un “hard shutdown” no realiza un savepoint, lo que incrementaría el tiempo de reinicio del sistema.
• Después de iniciar el sistema. Finalizado el reinicio del sistema, se realiza un savepoint.
• Snapshots. Las instantáneas conllevan un savepoint que no se ven afectados por siguientes savepoints.

Las actualizaciones del software de SAP HANA son liberadas bajo dos modalidades o categorías que difieren en su denominación con respecto a otros productos SAP a los que estamos más habituados. Estos paquetes de actualización se denominan Support Package Stacks (SPS) y Revisions.

 Los SPS son las actualizaciones principales de SAP HANA los cuales incluyen nuevas funcionalidades y significativos cambios. Las Revisiones son parches al software con el fin de corregir errores o brindar pequeñas mejoras. En ambos casos, SAP recalca que los cambios y mejoras no son disruptivos. Comparando el sistema de actualización del software de SAP HANA con SAP BusinessObjects BI (BI4), podríamos señalar que los SPS de HANA equivalen a los SP de BI4 (Support Pack) y una “Revision” equivale a un ”Patch”.

No hay un ciclo definido de liberación de las actualizaciones del software de SAP HANA, pero se estiman dos actualizaciones del tipo SPS al año, y usualmente una antes de mayo y la otra antes de noviembre, aproximadamente. Meses después de la liberación de un paquete, SAP podría finalizar el ciclo de vida de una actualización anterior, por lo que la aplicación de las actualizaciones no debería postergarse demasiado.

En cuanto a las “Revisions”, también denominadas Support Package (SP), se liberan sin seguir ningún patrón de frecuencia, son publicadas cuando SAP lo vea necesario. Hay dos tipos de revisiones: “SAP HANA Datacenter Service Points”, revisiones comprobadas en los sistemas de producción de SAP y “SAP HANA Maintenance Revisions” las cuales pueden contener un mayor número de corrección de errores pero suelen basarse en SPS antiguos, por ejemplo, revisiones en base al código del SPS 07 cuando ya se ha liberado el SPS 08.