Data Warehouse y BBDDs – Página 3

Consideraciones básicas para el despliegue de “BW on HANA” (I)

Complementando la entrada anterior, si contáramos con SAP Netweaver BW powered by SAP HANA” (BW on HANA ) se debería considerar los siguientes aspectos al planificar su configuración:

Complementando la entrada anterior, si contáramos con SAP Netweaver BW powered by SAP HANA (BW on HANA ) se debería considerar los siguientes aspectos al planificar su configuración:

SAP no da soporte al despliegue de múltiples sistemas SAP NW BW en un sistema productivo SAP HANA.
SAP brinda soporte al despliegue de múltiples sistemas SAP NW BW on HANA en arquitecturas de nodo único o multinodo con fines distintos a un entorno productivo, con una base de datos por cada sistema SAP NW BW.
El servidor de base de datos de un sistema BW es desplegado en un esquema de la base de datos SAP HANA. La instancia central del sistema BW y todas las aplicaciones de servidor asociadas no se instalan en el appliance SAP HANA, son instalados en un servidor aparte.
Con respecto al párrafo anterior, existen “excepciones” señaladas en la nota 1661202 que permiten aplicaciones residan en el sistema SAP HANA en un entorno productivo. Si una aplicación que no figura en el listado de excepciones es instalada en BW on HANA en un entorno productivo, esta aplicación no tendría soporte por parte de SAP. En un entono distinto a producción si tendría soporte.
BW on HANA permite la aplicación de técnicas de alta disponibilidad (High Availability – HA) y tolerancia a fallos (Disaster Tolerance – DT). En cuanto a HA sigue los mismos mecanismos que un sistema SAP HANA, a través de la activación de nodos pasivos. En general, especialmente en los casos de DT, estas técnicas pueden variar en función del proveedor de Hardware.
Las técnicas que se aplican en un sistema SAP HANA para evitar que los datos en memoria se pierdan ante un fallo en el servicio eléctrico también incluye los datos de BW on HANA.
Es recomendable tener por los menos tres nodos en un sistema SAP HANA en el que se despliegue BW on HANA. En el nodo principal estarían las tablas con almacenamiento basado en filas y en lo nodos esclavos se tendría las particiones de los infocubos y ODSs (Ref. nota 1702409).
Para información adicional y futuras novedades sobre los aspectos comentados en esta entrada revisar las notas 1666670 y 1661202.

Consideraciones para el despliegue de más de una base de datos SAP HANA

Con el término SAP HANA Appliance se hace referencia a un servidor o un sistema SAP HANA el cual puede estar compuesto por un único nodo o por un conjunto (cluster) de nodos (arquitectura con escalabilidad horizontal o sclae-out) dónde en al menos un nodo reside la base de datos SAP HANA y los componentes del sistema.

Con el término SAP HANA Appliance se hace referencia a un servidor o un sistema SAP HANA el cual puede estar compuesto por un único nodo o por un conjunto (cluster) de nodos (arquitectura con escalabilidad horizontal o sclae-out) dónde en al menos un nodo reside la base de datos SAP HANA y los componentes del sistema.

Hace unos días leíamos un listado de acrónimos y términos vinculados al mundo SAP HANA, una buena referencia, pero faltaría considerar otros como MCOS que corresponden a las iniciales de “Multiple Components One System” que describen la arquitectura de múltiple nodo que se señala en el párrafo anterior. Otro término que también se utiliza en el contexto SAP HANA es “Multi-SID” o MSID (Multiple Database on one SAP HANA appliance) que hace referencia a la posibilidad de configurar más de una base de datos en un sistema SAP HANA.

Cabe recordar que en un entorno productivo HANA sólo tendrá soporte si tiene una única base de datos en el sistema (SIDS). Es posible tener más de una base de datos HANA, pero sólo debería ser considerado en entornos que no son con fines de producción, tales como los clásicos entornos de pruebas o desarrollo. Esta consideración se aplica tanto si se trata de una arquitectura de un nodo o multinodo.

Un appliance HANA, recién entregada por los partners de hardware, lo encontraremos con una base de datos SAP HANA, usando “On-Site Configuration tool” se podrá configurar una base de datos adicional, para lo cual deberá considerar lo siguiente:

No debería realizarse en un entorno productivo.
Se debería contar con la configuración de hardware necesaria para soportar el despliegue de más de una base de datos (especialmente en cuanto a memoria).
Se debe tener en cuenta que se puede perder rendimiento o velocidad en la ejecución de varios procesos.
Si hubiera problemas en el sistema y se solicitará el servicio de soporte de SAP, podría indicarse detener las bases de datos para comprobar si el problema es originado por la configuración de las bases de datos adicionales.
Para más información y futuras novedades revisar las notas 1681092 y 1661202.

Restricciones técnicas en objetos de SAP NW BW

Cuando comentamos las sugerencias de buenas prácticas o restricciones que se deben tener en cuenta al diseñar modelos en SAP Business Planning and Consolidation (SAP BPC especialmente en entornos NetWeaver), los usuarios técnicos, habituados al uso de SAP NW BW, no pueden evitar las comparaciones, afirmando en ocasiones que en entornos BW no existen limitaciones.

Cuando comentamos las sugerencias de buenas prácticas o restricciones que se deben tener en cuenta al diseñar modelos en SAP Business Planning and Consolidation (SAP BPC especialmente en entornos NetWeaver), los usuarios técnicos, habituados al uso de SAP NW BW, no pueden evitar las comparaciones, afirmando en ocasiones que en entornos BW no existen limitaciones.

Por supuesto que menos amplias que en SAP BPC, pero las restricciones técnicas también existen en entornos SAP NW BW, algunas de estas restricciones han sido recopiladas en la nota de referencia, tenerlas en cuenta ayudará en la eficiencia de los procesos.

Referencia: SAP Note 1837308 «FAQ: Technical limitations of Infoproviders and Characteristics in BW«

Opciones de instalación de «SAP LT Replication Server»

SAP LT Replication Server (LT = Landscape Transformation) es la tecnología para replicar en sistemas SAP HANA información provenientes de fuentes de datos SAP y no-SAP. Los servidores SAP LT Replication identifican los cambios en las bases de datos origen a través de disparadores (triggers) para luego llevarla a SAP HA Database con la frecuencia definida.

SAP LT Replication Server (LT = Landscape Transformation) es la tecnología para replicar en sistemas SAP HANA información provenientes de fuentes de datos SAP y no-SAP. Los servidores SAP LT Replication identifican los cambios en las bases de datos origen a través de disparadores (triggers) para luego llevarla a SAP HA Database con la frecuencia definida.

Dependiendo del tipo de la fuente de datos y de la configuración de los sistemas, se optará por un tipo u otro tipo de despliegue:

Un servidor dedicado (Para fuentes de datos SAP. Enfoque de 3 capas). Necesario en los casos que el sistema SAP origen no se ajuste a los requerimientos básicos de nivel de actualización de SAP Netweaver y SAP Kernel. Lo positivo: Mayor flexibilidad en el despliegue al no existir dependencia del mantenimiento del software. Lo negativo: Inversión y manteamiento en una nueva instancia de servidor NW.

Instalación en el sistema origen (Para fuentes de datos SAP. enfoque 2 capas). Opción posible si los sistemas están alineados con el nivel de actualización requerido. Positivo: Mínima inversión y lo Negativo: Podría haber un menor rendimiento con relación a la opción anterior y habría una dependencia en el mantenimiento del software el cual debería ir alineado entre los sistemas fuentes y el servidor de SAP LT Replication.

Instalación para fuentes de datos no-SAP. En estos casos se requiere un servidor dedicado de SAP LT Replication.

Referencia: Doc. SAP HANA

SAP HANA en el «Magic Quadrant for Data Warehouse Database Management Systems 2013»

El informe de la consultora Gartner, sobre el sector de las bases de datos relacionales utilizadas como repositorios de datos, ha sido publicado el día de hoy, para nosotros, segundo en importancia después del informe sobre Plataformas de Business Intelligence. Los informes anuales “Magic Quadrant” de Gartner cubren las diversas tecnologías y son referentes para toda la industria informática.

En el “Magic Quadrant for Data Warehouse Database Management Systems” sólo se mencionan a fabricantes, en cuanto a sus productos aparecen en los comentarios. SAP no figura en estos informes hasta la edición de 2011, cuando se considera como fabricante de base de datos por la adquisición de Sybase en mayo de 2010.

¿Teradata ganador?

Un artículo de ZDNet señala que el ganador es Teradata, pero por los comentarios del informe no lo vemos totalmente claro, los fabricantes que figuran en el cuadrante de líderes tienen importantes “deberes” que podrían afectar su futuro inmediato. Teradata, el que muchos apuntan como el “ganador” de este informe, tiene una estrategia comercial que complica nuevas adquisiciones e inclusive actualizaciones y por otro lado, no existen los suficientes especialistas en Teradata que brinden el soporte necesario en la instalación y mantenimiento de esta base de datos.

SAP HANA, el protagonista

Es la segunda vez que se menciona a SAP HANA en estos informes, pero creemos que en esta última edición es el gran protagonista, totalmente distinto a la edición del 2012, entonces totalmente desconocido para Gartner:

We mention SAP HANA here, but we do not have any production references at the time of this analysis. Sybase has thousands of Sybase IQ customers worldwide.

Se señala que a diciembre de 2012, SAP HANA ya contaría con más de 1.000 clientes, lo que significa que tiene una tasa de crecimiento del 48%, muy lejos de la media del sector que oscila el 14,8%.

En cuanto a los motivos por qué se compra SAP HANA, esta muy claro:

45% para SAP BW powered by HANA
45% para data marts en memoria
10% otros usos

En cuanto a las precauciones o cuidado sobre SAP, por partes, pareciera que se estuviera describiendo fortalezas. Observamos que el gran problema es la falta de claridad en el mensaje, especialmente sobre los siguientes aspectos:

Papel de SAP Sybase IQ y de SAP HANA, hay confusión del uso o utilidad que puede brindar cada uno como Data Warehouse
Uso de sus productos para las necesidades Big Data

Referencia: