In-memory computing – Página 7

«SAP HANA System Replication» no es lo mismo que «SAP HANA LT Replication Server»

En cada actualización de SAP HANA, además de nuevas funcionalidades también va madurando y mejorando los aspectos de seguridad dad y estabilidad del dato. Con respecto a la alta disponibilidad (High Availability) y Recuperación ante desastres (Disaster Recovery), SAP HANA brinda un sistema de replicación, denominado SAP HANA System Replication.

En cada actualización de SAP HANA, además de nuevas funcionalidades también va madurando y mejorando los aspectos de seguridad dad y estabilidad del dato. Con respecto a la alta disponibilidad (High Availability) y Recuperación ante desastres (Disaster Recovery), SAP HANA brinda un sistema de replicación, denominado SAP HANA System Replication.

SAP HANA System Replication ofrece la posibilidad de copiar y sincronizar continuamente una base de datos HANA a una ubicación secundaria, en el mismo u otro data center. Por el nombre de esta técnica se podría confundir con SAP HANA LT Replication Server (SLT. LT = Landscape Transformation), técnica que permite cargar datos desde sistemas ABAP y no ABAP a SAP HANA Database.

Consideraciones un sistema de replicación en SAP HANA Database:

Tanto el sistema primario como el secundario deben estar en funcionamiento, independientes y deben tener igual número de nodos activos.
Toda la configuración se realiza en nodo maestro.
La versión y actualización del sistema secundario debe ser igual o superior al del sistema primario.
El sistema secundario debe tener el mismo SID y número de instancia del sistema principal.
Los cambios en ficheros INI en un sistema deben ser efectuados en el otro sistema de manera manual.
Se recomienda realizar una copia de seguridad antes de activar el sistema de replicación
Es posible que el sistema secundario tenga un fin propio de un entorno de desarrollo o pruebas, mientras que el primario sea un entorno de producción. Si este fuera el caso, se debe tener en cuenta que el 10% de los recursos del sistema secundario se dedican al sistema de replicación.
La distancia entre los data centers determinará el métodos de replicación que se utilice.

Referencia: SAP Note 1999880

Tips de una implementación SAP HANA

En los blogs de SAP SCN hallamos muchas entradas, algunas muy útiles desde el punto de vista técnico, sobre SAP HANA, encontramos un breve relato sobre la experiencia de la Universidad de Amsterdam al adoptar esta plataforma para sus sistemas de BW (BW on HANA – BWoH) y ECC (Suite on HANA – SoH).

En los blogs de SAP SCN hallamos muchas entradas, algunas muy útiles desde el punto de vista técnico, sobre SAP HANA, encontramos un breve relato sobre la experiencia de la Universidad de Amsterdam al adoptar esta plataforma para sus sistemas de BW (BW on HANA – BWoH) y ECC (Suite on HANA – SoH).

A continuación algunos tips que extraemos del post de referencia:

Motivo: El hardware de la organización era obsoleto y de muy costoso mantenimiento.
Situación: Como consecuencia del punto anterior, el rendimiento de los sistemas era pésimo.
Otras alternativas que se valoraron: En una comparativa de costos de licencias entre Oracle y HANA puede resultar más atractiva la primera, pero aspectos tales como la integración de los sistemas ECC y BW sobre la base de datos HANA fue el principal aspecto que primó sobre el precio.
Papel de SAP: Al parecer: La colaboración de los representantes de SAP sólo se enfocaron en aspectos técnicos, no ayudaron a construir el “business case” desde el punto de vista funcional requeridos en estos casos (este comentario ya lo hemos escuchado más de una vez).
Expectativas: Además de la implementación de los sistemas en una plataforma in-memory, las posibilidades de adoptar SAP HANA Live for Business Suite (el sistema de análisis y reporting en tiempo real para ECC) causó gran expectativa entre los usuarios de negocio.
Enlaces de referencia: SuiteOnHANA y ExperienceSAPHANA
Dimensionamiento: SAP ofrece recursos tales como informes que ayudan a estimar el tamaño requerido de la infraestructura SAP HANA. Como es conocido, las necesidades de disco se reducen significativamente con SAP HANA. En esta experiencia puntual, la base de datos de BW pasó de 1.8 TB a 300 GB y la de ECC de 550 GB a 250 GB.
Hardware: Esperar hasta el último momento la compra del hardware, debido a la competencia entre los proveedores, las mejoras y precios pueden cambiar drásticamente en tan sólo unas semanas.
Actualización y Migración: Según SAP la actualización y migración se podría efectuar en un solo paso (Data Migration Option of SAP Upgrade Manager – DMO of SUM), pero por motivos de seguridad se optó por realizar esta operación en dos pasos. Se sugiere optar por la última versión y actualización disponible de los componentes, así mismo, verificar el nivel de revisión del software. La migración no es muy distinta a cualquier otra migración SAP. Además del uso de los clásicos entornos que puede tener una organización, se sugiere un primer paso a través de un Sandbox con la finalidad de hacer pruebas, comprobaciones y comprender el proceso.
Código: Un factor positivo es el poco código personalizado que se tuviese, sin embargo, SAP provee informes que analizan tanto código SAP y código personalizado con el fin de brindar sugerencias para que funcione mejor en una plataforma SAP HANA.
Contratiempos: No se encontraron problemas significativos al realizar el proceso de actualización y migración, salvo con tablas que tenían un gran tamaño, contratiempo que se superó “truncándolas”.
Resultado: El rendimiento de BW y ECC ha mejorado de manera significativa y no ha habido problemas con las bases de datos o la plataforma HANA. Sin embargo, hay algunas transacciones que funcionan peor, que están siendo revisadas por SAP.
La Prueba: …Hemos experimentado con sólo «tirar del enchufe» para simular una desconexión inmediata, inesperada de HANA. Después de arrancar, no notamos ninguna pérdida o corrupción de datos.

Referencia: Blogs SAP SCN

EarlyWatch Alert para SAP HANA Database

El EWA o EarlyWatch Alert es el automatismo que nos informa, periódicamente, sobre el estado de una plataforma, brindando alertas o sugerencias sobre mejoras en la parametrización y aplicación de actualizaciones sobre los componentes que conforman un sistema.

El EWA o EarlyWatch Alert es el automatismo que nos informa, periódicamente, sobre el estado de una plataforma, brindando alertas o sugerencias sobre mejoras en la parametrización y aplicación de actualizaciones sobre los componentes que conforman un sistema. Desde hace un tiempo ya es posible configurar un EWA sobre un sistema SAP HANA, inclusive si este no hace una referencia a un sistema ABAP.

En la nota 1958910 se señala los requisitos, modo de configuración y otras consideraciones.

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.

Particionado de Tablas en SAP HANA (II) – Tipos de Partición

Seguimos señalando las características básicas sobre el particionamiento de los datos en SAP HANA Database (ver entrada anterior)
Tipos de particionamiento

Seguimos señalando las características básicas sobre el particionamiento de los datos en SAP HANA Database (ver entrada anterior)

Tipos de particionamiento

HASH. Los registros son asignados a particiones basados en un algoritmo hash, por lo que no se requiere un conocimiento profundo del contenido de la tabla (no hay una separación lógica de los datos). En la configuración de esta tipo de partición se debe indicar las columnas cuyos valores se utilizarán para determinar el valor hash. Si las tablas tienen columnas índices, estas deben ser utilizadas en este proceso. De fácil configuración, no requieren mantenimiento. Durante las consultas todas las particiones deben ser exploradas a menos que se indique explícitamente las particiones a consultar (parámetros “=” o “IN” de la cláusula “WHERE”).

ROUND-ROBIN. Se utiliza para lograr una distribución uniforme de los datos en las particiones, a diferencia del caso anterior, no es necesario especificar columnas para definir el criterio de este proceso. Los nuevos registros de van asignando rotativamente. Las tablas no deben tener claves primarias. Son de fáciles configuración, no requieren mantenimiento. En consultas, todas las particiones deben ser exploradas. No hay separación lógica de los datos.

RANGE. Los registros son asignados a particiones utilizando los rangos de particiones definidos. Es la única que define la asignación de particiones bajo un criterio lógico, en consecuencia, es la mejor vía para optimizar el acceso a los datos. Para una adecuada configuración, es necesario conocer los datos y sus aplicaciones. Es necesario un regular mantenimiento (p.e. para definir nuevas particiones o eliminar otras cuyos datos han sido archivados). Es necesario el uso de una clave principal. Sólo es aplicable para tipos de datos (cadenas, enteros y fechas).

Cualquier definición de partición utilizando uno de los métodos anteriores, dará lugar a un particionamiento simple (single-level partioning). Si cada partición es particionada nuevamente por otros criterios, estaríamos hablando un particionamiento multinivel (multi-level partitioning).