Archivo de la categoría: Bases de Datos

FAQ sobre copias de seguridad en SAP HANA

En muchas ocasiones, para buscar información sobre los nuevos productos de SAP, la mejor fuente de información o documentación la encontramos en el área de ayuda y soporte de SAP Marketplace, si utilizamos las palabras adecuadas podemos encontrar Notas Técnicas con información clara y actualizada, inclusive, más útil que los manuales oficiales.  Una muestra es la nota 1642148, se trata de un listado de preguntas frecuentes (FAQ – Frequently Asked Questions)  sobre copias de seguridad en SAP HANA.

La esencia de las técnicas que emplea SAP HANA para ofrecer tiempos reducidísimos de acceso a la información, es tener los datos en memoria, sin embargo el sistema in-memory de SAP también tiene los datos en disco, así si se produce un fallo eléctrico, el sistema puede reiniciarse sin ningún problema.  La puesta en práctica de un procedimiento de copias de seguridad en cualquier organización es indispensable y con SAP HANA también.

Revisando la nota técnica de referencia, destacamos lo siguiente:

  • Las copias se realizan en línea, sin interrumpir o afectar los tiempos de respuesta del sistema.
  • Se  copias los datos y los logs del sistema
  • Para iniciar el proceso se puede hacerse a través de SAP HANA Studio, sentencias SQL, además de dos vía adicionales.
  • No pueden solaparse procesos de copias de seguridad, si se intenta lanzar una segunda copia, cuando no ha finalizado la primera, el segundo proceso no se inicia.
  • La copia y recuperación se realiza sobre el total de la base de datos, no es posible copiar o restaurar parcialmente.
  • Es posible configurar la ubicación destino de las copias de seguridad (por razones de seguridad se sugiere una ubicación externa)

Referencia: (aquí)

Sin tapujos, Oracle vs SAP, por el liderazgo del in-Memory Computing

Hasta una semana, la hostilidad entre Oracle y SAP por lo que podríamos denominar la cuota de mercado de las bases de datos con procesamiento en memoria (in-memory Computing) parecía más ilusión de la prensa, pero por lo visto en los últimos días, la “guerra es abierta” y el  “combate es cuerpo a cuerpo”.

Oracle no cesa en afirmar que SAP HANA no es producto que pueda afectar a su tradicional negocio de base de datos, pero cada vez que tiene que hablar de sus propuestas in-Memory, habla de SAP HANA, algo similar como lo que sucede con aquel entrenador de futbol que cuando debe hablar de su equipo, habla de otro equipo.

Hace una semana Oracle publicaba una presentación que ha desatado la furia en SAP, generando respuestas inmediatas hasta del Vicepresidente Ejecutivo de SAP, Steve Lucas, quién ha considerado el documento de referencia un ataque por la cantidad de errores e inexactitudes que contiene.

No conocemos la propuesta in-memory de Oracle, pero particularmente nos parece algo compleja, repartida entre Exadata (entendemos que es la base de datos in-memory genérica) y Exalytics (la propuesta in-memory para necesidades de Business Intelligence) que al parecer, vista la documentación, necesitaríamos “vincular”

Comparar Oracle Exalytics con SAP HANA, nos parece tan “lógico” como comparar naranjas con manzanas, las dos pueden ser muy buenas, pero responden a necesidades distintas.  Oracle la percibimos como una base de datos y SAP HANA como una plataforma sobre la que se están desarrollando una nueva generación de aplicaciones, inclusive SAP ERP.

Unos de los aspectos que más críticas a suscitado ha sido la comparativa de funcionalidades entre Oracle Exalytics y SAP HANA, una primera impresión podría conllevar a la conclusión que la propuesta de Oracle “tiene más” o “es mejor”, pero resulta que la mayoría de características que figuran en esta tabla, tales como los agregados o índices, no son incluidas en la tecnología de SAP porque son innecesarias y no contribuyen a una mejor eficiencia.  Como señala el post de Steve Lucas, es como comparar la tecnología de un carruaje tirado por caballos y un automóvil, el primero ya puede señalar que incluye el cubo y una pala para recoger los excrementos de los animales.

Otro aspecto que para SAP es incorrecto, es la referencia de precios, en el artículo del Vicepresidente de SAP, se señala que se cobra por la estimación de datos a procesar,  según esto se determina las necesidades memoria y unidades a utilizar (1 unidad = 64 GB) la cual valdría a 13 euros por unidad.  Si algo tienen en común estas tecnologías es que utilizan un hardware específico, pero mientras de Oracle es sólo Sun, SAP HANA está disponible con el hardware de Fujitsu, Dell, IBM y HP.

Nuestra apuesta para procesamiento in-memory es SAP HANA.  Al igual que otras opiniones, tenemos la sensación que las propuestas de Oracle han sido diseñadas apresuradamente sobre su modelo tradicional de bases de datos y no descartamos que en el futuro inmediato presenten un nuevo producto.

Referencia: (documento de Oracle)

SAP HANA a prueba para BI

SAP ha publicado los resultados de una prueba del rendimiento de SAP HANA para necesidades de Business Intelligence.  Para lo cual definió un escenario de ventas con cinco años de transacciones que equivalían a 100 TB de información (aplicando una compresión de 20X, en base de datos ocupó 3,78 TB).

Para este entorno de pruebas se configuró unas características de hardware detalladas en informe adjunto y se definieron una serie de consultas SQL que equivalen a las consultas que se generan en un entorno de BI.

La conclusión más relevante es que el acceso a los cien mil millones de filas (100.000.000.000) consumieron entre uno y dos segundos para el caso de los informes con opciones de drill-down (profundizar o detallar la información) y hasta un promedio de 3,8 segundos para las consultas de tipo analíticas, las cuales implican mayor complejidad al incluir combinación de tablas y comparaciones de períodos.  Estos tiempos de acceso es lo que algunos llaman “Real-time BI”.

Referencias: (informe)

Vías para replicar los datos en SAP HANA

Si vemos a SAP HANA database como un datawarehouse o conjunto de datmarts, deberemos pasar los datos de las fuentes origen al entorno HANA, para lo cual contamos con tres vías:

  • Log-based replication. Basada en Sybase Replication Server, es la vía más rápida, pero es compatible sólo para bases de datos UNICODE, no reconoce algunos tipos de tablas SAP y no brinda posibilidades de transformación.
  • Trigger-based replication. Método recomendado para instalaciones con fuentes de datos SAP, replicación en tiempo real e incremetal, la replicación se ejecuta cuando las fuentes de datos origen tienen cambios. (SAP Landscape Transformation – LT – Replication).
  • ETL-based replication. Basada en SAP BusinessObjects Data Services, el método universal y más flexible para replicar datos en HANA, es compatible con cualquier tipo de fuente de datos, permite amplia variedad de transformaciones y programación de los procesos. 

Oracle y SAP HANA, sin puntos de comparación

Compartimos la idea que el concepto de base de datos se está transformando, como en situaciones similares, ante un importante cambio que redefine los pilares en el que se basa un producto o servicio, los protagonistas actuales niegan la validez de la nueva propuesta.  Un ejemplo de esta situación, es la respuesta de Oracle a SAP HANA.

Muchos se apuran en comparar las propuestas de Oracle con SAP HANA, pero esta comparativa puede resultar carente de toda lógica.  Actualmente, las propuestas de Oracle están dirigidas a ofrecer una base de datos con fines de reporting y análisis de información y SAP HANA es una plataforma con procesamiento en memoria para el despliegue de aplicaciones transaccionales, analíticas, móviles e inclusive el ERP de SAP.  HANA es tanto para soluciones SAP como de otros fabricantes.

Pero si de igual modo desea realizar una comparativa entre SAP HANA y el resto de propuestas para el procesamiento de grandes volúmenes de información (Big Data), el documento que adjuntamos debería tenerlo presente para la elaboración de dicho estudio.

Documento Adjunto: (aquí)

SAP HANA Studio, validación de modelos inmediatamente

Después de la infraestructura de hardware y de la base de datos, el componente más relevante de una plataforma SAP HANA es SAP HANA Studio, con esta herramienta se realiza el modelado y la administración de los datos.

Con el componente Information Modeler de SAP HANA Studio, se diseñan las vistas de los datos transaccionales que serán usados en el análisis, para este fin, se diseñan los siguientes modelos:

  • Attribute view (las dimensiones o perspectivas de análisis, p.e.: Tiempo, Producto o Cliente).
  • Analytic View (una vista multidimensional u OLAP, a partir de una tabla de hechos y los Attribute views. p.e.: Costes de productos según períodos de tiempo).
  • Calculation View (una vista que utiliza tablas de datos y otras vistas para cubrir necesidades específicas de análisis del negocio, p.e.: comparativa de ventas de un producto en una región determinada, en dos períodos de tiempo).

SAP HANA Studio es una herramienta gráfica que permite probar o validar los modelos inmediatamente, así lo podemos observar en un breve vídeo de SAP SDN.

Novedades de OBIEE 11g (Oracle BI) pendientes en SAP BusinessObjects

Oracle esta de tour, presentado en las principales ciudades del mundo, la última versión de su plataforma Business Intelligence, OBIEE 11g.  Según algunos analistas, señalan esta nueva versión de Oracle BI, como la mejor propuesta de Business Intelligence en la actualidad, leyendo las principales nuevas funcionalidades, identificamos algunas que vendrían muy bien en SAP BusinessObjects (SAP BO) y que se vienen anunciando su incorporación desde hace muchos meses y esta no se concreta.

Entre las novedades que se mencionan, están las siguientes:

  • Capa semántica única. Lo que equivaldría en SAP BO a los universos, anunciado en muchos eventos como la “Common Semantic Layer” (CSL), pero sin fecha concreta de presentación, facilitaría la conexión entre los datos y las herramientas de BI, definición que se haría una sola vez, sin tener que utilizar diversos mecanismos de conectividad.
  • Conexiones entre OBIEE y aplicaciones Oracle. La conectividad entre los componentes SAP BI BO y otras aplicaciones, no es tan fluida como anuncia Oracle con sus productos que se podrían definir a través de servicios Web y la definición de procesos de negocio.
  • El “Action Framework”. Las herramientas de Business Intelligence deberían conducir con claridad a la acción, y ente punto muy pocas o ninguna herramienta lo lograr realizar con claridad. El “Marco de Acción” de OBIEE, a través de la definición de una serie de parámetros sugeriría una serie de acciones concretas en función de la información presentada.
  • BI Colaborativo. Mejoras en las funciones de navegación en la interfaz de usuario y capacidades de colaboración que permiten a los usuarios compartir, comentar y hacer cambios a los informes y otros objetos de análisis.

Otras funcionalidades de menor repercusión que incluye OBIEE 11g, encontramos las siguientes:

  • Posibilidad de analizar fuentes de datos XML.
  • Editor de informes que permite la publicación de informes interactivos para entornos Web y documentos estáticos de alta calidad.
  • La nueva herramienta Oracle Scorecard and Strategy Management, que permite enlazar objetivos con los indicadores claves de rendimiento.

Como tareas pendientes, OBIEE debe mejorar sus funciones cloud computing y al igual que SAP BusinessObjects, deben incorporar el procesamiento y análisis en memoria.

Asumimos que SAP recuperará su ventaja con sus próximos lanzamientos, sobre todo, los programados para el último trimestre del año, como el de SAP BusinessObjects XI 4.0.

Referencia: SearchOracle.com

OBIEE 11g, la nueva propuesta BI de Oracle

El 7 de julio en Londres, Oracle realizará la presentación oficial de la nueva versión de su plataforma de BI; Oracle Business Intelligence Enterprise Edition – OBIEE 11g.

Según Oracle, la nueva versión ofrece más velocidad, nuevas funcionalidades y una “experiencia única” para el usuario final, el que podrá disponer cuadros de mando altamente interactivos, amplia gama de opciones de gráficas animadas, búsqueda integradas, entre otras funcionalidades.

A destacar, la mayor integración que tendrá OBIEE con la suite de soluciones de gestión del rendimiento de Oracle (Performance Management) especialmente con Hyperion Planning e Hyperion Financial Management. También esta el ofrecimiento para la próxima edición, inclusión de funcionalidades BI en la soluciones Fusion.

Referencia:

BWA: Consultas en tiempo real

Revisando la revista AUSAPE de abril 2010, encontramos un artículo que nos cuenta los beneficios que brinda SAP Netweaver BW Accelerator (BWA), una solución de 64 bits de hardware y software, para disminuir sustancialmente el tiempo de respuesta de las consultas.

Aunque en el artículo se afirma como una practica del pasado,… Para mejorar el rendimiento en un entorno tradicional de SAP Netweaver Business Warehouse es necesario, utilizar mecanismos propios del sistema, entre otros:

  • Cache OLAP
  • Agregados
  • Particionamineto conceptual (multicubos)
  • Particionamiento físico (a nivel de tabla)

Todas estas medidas serían innecesarias en un sistema con SAP BWA, que indexa SAP BW con tecnología  TREX que luego carga en memoria y los utiliza para dar respuesta a las consultas.

Si se cuenta con BWA, soluciones como SAP BusinessObjects Explorer permite adaptarla en su configuración para beneficiarse de esta arquitectura.  A futuro se prevé que otros componentes de SAP BusinessObjects también podrán disminuir su tiempo de respuesta, utilizando BWA.

BWA no es para todos

Se recomienda el uso de BWA en los casos en que los agregados relacionales u otros métodos específicos de BI para mejorar el rendimiento no son suficientes, son demasiado complejos, o tiene otras desventajas.

Por otro lado, al tratarse de una arquitectura física certificada (IBM, HP, Fujitsu, Dell, Cisco, Sun/Oracle y Teradata son partners de SAP BWA), el costo de esta solución tiene dos fuentes, el software y el hardware; y si la implementación se realiza a través de otro partner, los costes podrían incrementarse aun más.

Un artículo de SearchSAP.com (o aquí por si pide usuario/contraseña), hace un estimado del costo de un proyecto de instalación de BWA, por lo que recomienda evaluar si se puede seguir haciendo las tareas habituales de mantenimiento del rendimiento o buscar otras vías para optimizar el acceso a la información como el almacenamiento near –line.

Referencia: Una versión mejorada de BWA, otro anuncio para 2010

Una versión mejorada de SAP BWA, otro anuncio para 2010

Si nos ponemos a contar con los dedos, es probable que necesitemos las dos manos, para enumerar las nuevas versiones o características de los componentes SAP BI BusinessObjects que deberían estar disponibles en 2010,  y si somos muy exhaustivos, quizás terminemos descalzándonos y contando con los dedos de los pies.

Pero de todos estos anuncios que se han realizado, personalmente nos quedaríamos satisfechos si contáramos con la primera versión de Pioneer y la versión 7.5 de SAP BPC, ambos se encuentran en “ramp-up”, la última fase del desarrollo de un producto SAP, disponible sólo para un reducido grupo de usuarios.

Una nueva versión SAP BW Accelerator

Otro de los grandes anuncios es la disposición de una versión mejorada de SAP BW Accelerator. SAP BWA es una solución para arquitecturas de 64 bits que puede llegar a ejecutar consultas 200 veces más rápido de lo normal, sin la necesidad de hacer labores de optimización (índices, agregaciones,…) de la plataforma BW.

La nueva versión incluiría en sus algoritmos de optimización, SAP BusinesssObjects Data Services, especialmente SAP BusinessObjects Data Integrator.  Esto permitiría la integración de datos no-SAP, además de los datos BW. Estas nuevas capacidades permitiría la “indexación” en SAP BusinessObjects Explorer de diversos tipos de fuentes de datos.

Referencia: