ORACLE DATABASE 12C IN-MEMORY, ¿es la respuesta de Oracle a SAP Hana?

Oracle presentó, hace algún tiempo, Oracle Database In-Memory, una nueva opción adicional a Oracle Database Enterprise Edition 12c, en respuesta al nuevo empuje hacia la industria de bases de datos residentes en memoria que ofrecen otros proveedores tanto  IBM (DB2 10.5 with BLU Acceleration) como SAP (Hana).

Comparativa Oracle vs SAP

Necesidad de negocio a cubrir	Oracle Database In-Memory	SAP HANA
¿Trabaja de manera contra aplicaciones de inteligencia de negocio previamente existentes y herramientas de "reporting"?	100 por ciento compatible con todas las herramientas Oracle y herramientas (ISV)  además de aplicaciones personalizadas por el cliente.	Mucho menos funcionalidad. Requiere nuevas aplicaciones o el registro de las aplicaciones existentes.
¿Es compatible with cloud computing, big data y data warehousing?	No hay límite de tamaño de la base de datos; utiliza dinámica de acceso aleatorio memoria (DRAM), flash, y el disco de forma transparente. No hay un gasto excesivo en el almacenamiento ya que los usuarios no tienen que poner toda su base de datos en la DRAM.	La base de datos entera debe encajar en la memoria DRAM que es costosa, y los datos que residen en sistemas DW  o en Big Data  no caben. También consolidación de la base de datos de nube no es factible. SAP afirma que los usuarios pueden combinar HANA con otras bases de datos como Sybase para migrar los datos desde y hacia HANA, pero esto es una arquitectura frágil, compleja y lenta.
¿Asegura la disponibilidad del dato y su seguridad?	La arquitectura de máxima disponibilidad de la base de datos Oracle  se hereda en Oracle  en memoria, mitigando las interrupciones planificadas o no. la duplicación de memoria evita el tiempo de inactividad en caso de fallo de nodo.	Al se un producto inmaduro las  funciones de alta disponibilidad faltan, por lo que lo  hacen que el tiempo de inactividad inevitable. Sin rápida recuperación de fallo de un nodo. falla de seguridad es un agravante.
¿Necesidades especiales de hardware o condiciones limitantes?	Base de Datos Oracle en memoria funciona en cualquier plataforma que ejecuta Oracle 12c de base de datos.	HANA sólo funciona en SAP en equipos informático que cuenten con la certificación  HANA basados en arquitecturas x86 . Los clientes no pueden hacer funcionar HANA en equipos no certificados.
¿Aprovecha el talento de de los elementos de la plantilla IT existentes (DBAs, desarrolladores)?	No se requieren nuevas APIs y los nuevos comandos DBA son mínimos, lo que hace de la base de datos Oracle en memoria algo trivial de implementar y mantener.	Debido a que Hana es una nueva "plataforma" se necesita formación para el equipo que explote esta plataforma.
¿Es escalable tanto para aplicaciones de análisis de datos o OLTP?	Base de Datos Oracle en memoria de formato dual, único que  permite la escala transparente tanto para el análisis y las cargas de trabajo OLTP corriendo juntos.	HANA utiliza un formato de columna para análisis de alto rendimiento, que tiene limitaciones arquitectónicas severas para el rendimiento y la escalabilidad OLTP.

En contraste En contraste con la bases de datos relacionales organizadas por filas, almacenadas en disco, un nuevo concepto se extendía a lo largo de los círculos académicos. Capitalizando esta tendencia y con la ayuda de unas pocas adquisiciones, principal competidor de aplicaciones empresariales tradicionales de Oracle, SAP comenzó a apostar por su propia base de datos de memoria llamada Hana. Mientras que SAP siempre ha sido el líder del mercado en el segmento de ERP, los clientes de SAP suelen optar por Oracle como base de datos back-end para sus aplicaciones SAP.
Ahora se está dibujando otro ecosistema para una instalación de SAP ERP:

• Base de datos: SAP Hana
• Middleware: SAP NetWeaver

Con todo este panorama, Oracle respondió introduciendo una capacidad revolucionaria, con una memoria caché residente columna que trabaja en conjunto con su caché fila tradicional.

Las bases de datos se suelen almacenar en discos que giran, en formato de fila y los conjuntos de datos activos se leen en la memoria basada en las memorias caché en hileras, donde los datos están protegidos por el registro de transacciones, mientras que los usuarios de negocios interactuaron a través de las aplicaciones empresariales. El rendimiento de base de datos se incrementó con los avances en el hardware, como las tecnologías de flash y el aumento de la capacidad de DRAM. Si bien esta arquitectura funcionó bien para manipulaciones de datos con sistemas OLTP y obtuvo buenos resultados para el análisis de consultas que impliquen estructuras de datos con un pequeño número de filas y el gran número de columnas. 

No estaba a la altura de almacenamiento de datos con los sistemas OLAP que lleva a cabo el análisis complejo multidimensional un gran número de filas con unas pocas columnas. Debido a esto, se tomó la costumbre de separar los sistemas de análisis,  de sistemas transaccionales cosa que hacía que diseñar un sistema de toma de decisiones fuera prácticamente imposible.

¿Que paso?

Mientras que Oracle dominaba el mercado RDBMS, otros proveedores se aprovecharon de esta oportunidad para proporcionar las bases de datos analíticas especializadas para el almacenamiento de datos, como NCR Teradata e IBM Netezza. El costo de memoriDRAM cayó, algunos proveedores, especialmente SAP, introducen nuevas tecnologías de bases de datos diseñadas para ejecutar bases de datos completas en memoria con las estructuras de datos de columna organizada. Si bien este enfoque aumenta el rendimiento de consulta de múltiples órdenes de magnitud, el rendimiento transaccional se vio afectado negativamente. SAP Sybase propuso utilizar para la transformación y carga de datos de columna organizada transaccionales en Hana para el procesamiento analítico de alto rendimiento. IBM y algunos otros jugadores de nicho también se unieron en la búsqueda para el diseño de bases de datos en memoria.

Respuesta de Oracle

Oracle se tomó un tiempo para hacer un movimiento agresivo, para proteger su producto estrella Con la arquitectura existente de Oracle completamente intacta, incluyendo la caché de fila y los mecanismos de registro de transacciones, Oracle ha diseñado una nueva caché columna que sólo existía en memoria. Como los datos organizada fila se lee desde el disco, Oracle rellena simultáneamente ambas memorias caché: 

• Caché de fila 
• Caché de columna

Con lo que mantiene dos copias de los datos en memoria: una fila organizada y la otra columna organizada. 
A continuación, el optimizador de consultas utiliza automáticamente la caché adecuado para satisfacer cada tipo de consulta, con capacidad para dos tipos de consultas dentro de una única base de datos, manteniendo al mismo tiempo la integridad transaccional a través de ambas cachés. Cuando se consulta la caché de la columna, Oracle utiliza aceleradores de hardware de vectores en las CPU para procesar conjuntos de datos completos en una sola operación atómica. En entornos RAC, cachés de la columna se copian en los nodos de alta disponibilidad. Mediante el uso de esta arquitectura, todas las funciones de base de datos anteriores continuaron el trabajo, que no requiere cambios en las aplicaciones para utilizar la caché de la columna en memoria.
Para utilizar la base de datos en memoria, todo lo que necesita es de dos sencillos pasos:

• En primer lugar, establecer el tamaño de la caché de columna utilizando un parámetro de inicialización.
• En segundo lugar, marcan todas las tablas y particiones para almacenar en caché utilizando un flag DDL. En este punto, las consultas se ejecutarán desde 100 a 1000 veces más rápido.

Puede mejorar aún más el DML (SQL de manejo de datos) eliminando todos los índices, excepto:

• clave primaria
• clave externa
• los índices de clave de referencia

con lo que se duplicará el rendimiento transaccional.

Bonus article: El seguimiento de las instrucciones de DDL en las tablas de base de datos Oracle en caché

Cuando se emite una instrucción DDL en una tabla de base de datos Oracle en caché, esta declaración puede ser rastreado en la tabla de base de datos TT_version_DDL_L. Inmediatamente el trigger TT_version_schema-ID_DDL_T se dispara para insertar una fila en la tabla, donde la versión es un número interno de TimesTen (el producto de que deriva Oracle database caché)  y el esquema-ID es el ID de usuario al que pertenece la tabla de base de datos Oracle en caché. 

Un trigger se crea para cada usuario de base de datos Oracle que posee tablas en caché. Una tabla de seguimiento DDL se crea para almacenar instrucciones DDL emitidos en cualquier tabla de base de datos Oracle en caché. El usuario de administración de caché es propietaria de la tabla TT_version_DDL_L y el trigger TT_version_schema-ID_DDL_T.

sql

Por defecto, las sentencias DDL no realizan un seguimiento, para poder hacer lo e ha de hacer o siguiente:

• Llamar al procedimiento almacenado ttCacheDDLTrackingConfig como el usuario administrador de caché. 

% ttIsql "DSN=cachealone1;UID=cacheuser;PWD=timesten;OraclePWD=oracle"
SQL> CALL ttCacheDDLTrackingConfig('enable');