Control de las replicación de datos en SAP HANA desde el iPad

La replicación de datos en SAP HANA es el proceso por el cual se transfiere o actualiza la información en SAP HANA database, para controlar este tipo de procesos, en cualquier entorno…


La replicación de datos en SAP HANA es el proceso por el cual se transfiere o actualiza la información en SAP HANA database, para controlar este tipo de procesos, en cualquier entorno, los administradores o responsables, deben conectarse vía “escritorio remoto” o mecanismos similares, si es que no desean desplazarse personalmente donde se encuentra la infraestructura física.  Con SAP HANA, podríamos gestionar la replicación de datos desde un iPad o iPhone, un pequeño detalle, pero que contribuye a que SAP HANA sea única y diferente. 

Desde SAP Replication Manager for iPad es posible, entre otras cosas, observar en tiempo real el progreso de la replicación, iniciar o detener los “jobs” de replicación.

Referencia: iTunes (aquí y aquí)

SAP: «BW para todo y para todos»

Después de varios «días cocción», el Post ya está listo, consultores y clientes/usuarios pueden estar tranquilos, BW gana la batalla, SAP HANA no sustituirá a BW. Steve Lucas, responsable de la división Business Analytics, publicó ayer miércoles, su respuesta a la pregunta que se le planteo vía Twitter: ¿SAP BW sería necesario si un cliente, en una nueva instalación, comprase SAP HANA?


Después de varios «días cocción», el Post ya está listo, consultores y clientes/usuarios pueden estar tranquilos, BW gana la batalla, SAP HANA no sustituirá a BW.  Steve Lucas, responsable de la división Business Analytics, publicó ayer miércoles, su respuesta a la pregunta que se le planteo vía Twitter: ¿SAP BW sería necesario si un cliente, en una nueva instalación, comprase SAP HANA?

SAP Consulta la Wikipedia

Lo primero que nos causa sorpresa, es que un alto ejecutivo de SAP busque la definición de sus productos en Wikipedia.  Nadie mejor que el fabricante para informar qué es y no es lo que produce.

Contradicciones

La supuesta rivalidad entre BW y HANA, se niega basándose en la gran cantidad de implementaciones y la cantidad desarrollos de terceros.  La «cantidad» nunca ha sido una razón suficiente para negar la capacidad disruptiva de una innovación, como podría ser HANA.  Como ejemplo, recordamos un caso muy recurrido por SAP, sobre las cámaras digitales y las analógicas, señalar la cantidad de usuarios de las cámaras tradicionales, no fue un argumento para negar la validez de esta innovación.  Claro, aquí hay un factor particular, la tecnología tradicional y la innovación, es controlada por el mismo fabricante.

Otro hecho contradictorio que hemos encontrado, es cuando se señala que HANA es una base de datos, cuando desde hace meses se «ajusto» el mensaje y se señalaba que SAP HANA era más que una base de datos, era la plataforma in-Memory Computing sobre la que se desplegarán la nueva generación de aplicaciones.

HANA mejora BW (BW is MUCH better on HANA)

Por otro lado, se señala que BW sobre un motor de base de datos tradicional, tiene un rendimiento pobre, la sugerencia general es utilizar SAP BW sobre SAP HANA y si es posible utilizar SAP BusinessObjects BI.

Situaciones

En el post de referencia se definen una serie de preguntas o situaciones, las cuales en todos los casos la respuesta es la misma: Ud. requiere SAP BW.  Los casos que se plantean son los siguientes:

  • Tengo SAP ECC y BW, ¿qué debo hacer? Respuesta: Utilizar BW sobre HANA. Se obtendría cargas de datos e informes en menores tiempos.  Se señala que más de 50 implementaciones en el ramp-up lo respalda: it is a simple migration of your database and SAP has a cookbook to help you do this.
  • Tengo SAP ECC y deseo BW, ¿qué debo hacer? Depende:
    • Si usarás SAP BPC, requieres BW.
    • Si deseas consolidar los datos corporativos, centralizados en una BBDD de “confianza” para el análisis y con “versión única de la verdad”, requieres BW. 
    • Si los sistemas transaccionales de SAP son la principal fuente de información, requieres BW. No descartando, en este caso, el uso de SAP BusinessObjects Rapid Mart.
  • Tengo SAP ECC, ¿podría usar SAP BusinessObjects Rapid Mart?. Depende:
    • SAP Rapid Marts no sustituye a un data warehouse, contiene lo necesario para brindar una respuesta inmediata sobre las áreas clave de SAP ECC, debe ser visto como un punto de partida en las organizaciones que cuenten con poco personal especializado.
  • Tengo SAP ECC, ¿podría hacer un DW desde cero?, Respuesta: No invente la rueda, use SAP BW.

Agregaría una situación más:

Han pasado algunos años (SAP HANA recién cumplirá su primer año el 18 de junio de 2012) y un partner o «tercero» replica en HANA gran parte las cargas predefinidas y demás best practices para cargar desde SAP ECC, además incluye las vistas de análisis predefinidas para explotar la información (como una propuesta mejorada de Rapid Marts powered by SAP HANA), la empresa comprará SAP HANA y requiere un DW, ¿debería comprar SAP BW?… que conteste el futuro…

Referencia: aquí

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.


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”.


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).


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)