JRockit, Hotspot, solo puede quedar uno, ... como en los Inmortales

Un poco de historia

En 2008 BEA es comprada por Oracle, lo que causó algunas dudas en el equipo, pero aparentemente el equipo fue poco a poco ganando protagonismo y atención. Y probablemente en breve tanto lo que era la máquina virtual de Sun, HotSpot, como la de Oracle, jRockit se juntarán en una única solución mucho más potente.

Conocí a uno de los autores en un evento que organizó  BEA Systems España, y fue allí donde empecé a conocer esta Java Virtual Machine, JVM.

¿Qué es una JVM?

Una máquina virtual de Java (JVM) es un programa que traduce el código Java en el código de máquina para una plataforma de hardware específica. Las JVM son las que hacen de Java portable; una aplicación Java debe ser capaz de funcionar en cualquier JVM, aunque cada JVM está escrito específicamente para una sola plataforma.

Pero basta de de historias de la guerra del abuelo, veamos que ocurre en momentos mas actuales

Para la mayoría de los nuevos sistemas y / o desarrollo, Oracle recomienda usar JVM / JDK 7.  Java 7 release 7u55 incluye JavaFX y muchas nuevas correcciones de errores y parches de seguridad. Para la mayoría de los nuevos sistemas y / o desarrollo, Oracle recomienda usar JVM / JDK 7. A veces, se prefiere JVM / JDK 8. Java 7 release 7u55 incluye JavaFX y muchas nuevas correcciones de errores y parches de seguridad.

Las características importantes de Java 8 incluyen:

• Lambda Expressions, una nueva característica de lenguaje, que le permite tratar la funcionalidad como un argumento de método o codificar como datos.
• Las anotaciones de tipo permiten aplicar una anotación en cualquier lugar donde se utilice un tipo, no sólo en una declaración.     
• Cliente TLS 1.2 habilitado por defecto.
• Algoritmos más fuertes para cifrado de contraseñas.
• Integración con Solaris 8 y mejoras de rendimiento relacionadas.

Debes de comprobar la matriz de compatibilidad de software aplicable para obtener recomendaciones actualizadas sobre la versión recomendada para su aplicación o implementación.

¿JRockit esta aún soportado?

JRockit y HotSpot se fusionan en una sola JVM, incorporando las mejores características de ambos. El resultado será aportado gradualmente a OpenJDK. JRockit se libera bajo Binary Code License Agreement  (BCL).

Aquí hay un enlace para ver la presentación oficial de Oracle de su nueva política, si estas mas interesado.

Oracle planea soportar el último lanzamiento de JRockit 6 - R28.2.7 hasta el 2017 JRockit Support. Las actualizaciones de esta versión estaban disponibles para el público durante el tiempo JDK 6 estaba disponible para el público. Tenga en cuenta las advertencias de texto en rojo en la página de descarga, ya que esta versión no está actualizada con los parches de seguridad. No se recomienda utilizar esta versión en producción ya que las nuevas versiones Java con parches de seguridad no están disponibles en Jrockit. Aún así, se podría usar la versión pública de JRockit 6 sin un cargo, siempre y cuando se cumplan los requisitos de BCL.

Las actualizaciones de Oracle a JRockit 6 hechas después de febrero de 2013 ahora sólo están disponibles para soporte a los clientes. Si un cliente ya tiene JRockit y quiere quedarse con JRockit, Oracle recomienda mantenerlo al día con las actualizaciones de $eguridad, que ahora requieren un contrato de $oporte.

Tenemos un cliente que usa Flight recorder y Mission Control con JRockit, se van a perder estas características con JRockit.

A pesar de que Java SE 7u40 fue lanzado en el otoño de 2013, todavía hay cierta confusión acerca de las características y funciones en las últimas versiones de Java.  

El Mission Control de java (JMC) y las características de Java Flight Recorder (JFR) de JDK/JRE SE 7u40 debería ser técnicamente equivalente a JRockit Java en este momento.

JConsole ha sido una herramienta popular a través de los años y proporciona un seguimiento básico de las aplicaciones. Para una mejor integración en la pila de Oracle, intenta utilizar Java Flight Recorder y Java Mission Control combinados con WebLogic Diagnostics Framework (WLDF)

(WLDF) es un marco de monitoreo y diagnóstico que define e implementa un conjunto de servicios que se ejecutan en los procesos de WebLogic Server y participan en el ciclo de vida del servidor estándar. Mediante WLDF, puede crear, recopilar, analizar, archivar y acceder a los datos de diagnóstico generados por un servidor en ejecución y las aplicaciones desplegadas dentro de sus contenedores. Estos datos proporcionan información sobre el rendimiento en tiempo de ejecución de los servidores y las aplicaciones y permiten aislar y diagnosticar fallas cuando se producen.

Si bien puede parecer que el recorte en las opciones de la Plataforma Java reduce las opciones y la flexibilidad, la convergencia resultará una planificación simplificada. Con Java Flight Recorder y Java Mission Control incluidos en la última versión de JVM 7, los diagnósticos, el monitoreo y el análisis de eventos se pueden realizar con una versión estándar de Java con relativa confianza en futuras versiones y actualizaciones de aplicaciones.

Puesto: DBA No SQL, eso, ... ¿existe?

Tengamos claro que soluciones del tipo NoSQL o Big Data están tomando el mundo por montera  y son cada vez más usados en entornos corporativos para mejorar el tiempo de puesta en producción y aumentar la agilidad de desarrollo. En resumen beneficios y eso nos importa a todos.

Con el advenimiento de novedades en el mundo de los sistemas de gestión de datos que se acumulan en principios distintos del álgebra relacional, una creciente duda ha crecido en torno a la necesidad y el papel del administrador de base de datos (nuestros “amados” DBAs) en este escenario. Incluso si la mayoría de estos nuevos sistemas son totalmente dependientes de los equipos de desarrollo y todos los esfuerzos de mantenimiento parecen redundantes (a partir de aquí el gerente de Dilbert, deja de leer, :) ). Una vez que se consideran todas las demandas de la puesta y mantenimiento en producción: 

• La disponibilidad 24x7
• La plena coherencia transaccional
• La estrategia de recuperación fiable 

Queda claro que los DBA tienen que seguir siendo una parte vital de la cadena de responsabilidad de la empresa. Aun cuando la tecnología subyacente se aleja del sistema de gestión de base de datos relacional - ya sea  transaccional o de tipo datawarehouse. 

La siguiente tabla representa el paisaje actual del ecosistema de gestión de datos, con las convenciones de nombres que se utilizan.

	RDBMS	NoSQL	Big Data
Ecosistema	Base de datos	Datastore	Dataset
Propietario	DBA	Desarrollador	Analista de datos
Propiedades	ACID	BASE	CAP
Clustering	Todo compartido	Nada compartido	Nada compartido
Madurez	mMás de 40 años	Más de 10 años	Más de 10 años
Cuota de mercado estimada	75%	20%	5%

Aunque los términos "NoSQL" y "Big Data" a menudo se utilizan indistintamente, la distinción es evidente, con respecto a sus áreas de uso, utilidad estrategia de negocio y la capacidad para gestionar tráfico concurrente. Dicho esto, NoSQL se ajusta más al espacio OLTP y Big Data es más de un tipo de datawarehouse (DWH).

En el paisaje que evoluciona rápidamente de soluciones de gestión de datos, será cada vez más importante, para aprovechar la mayor cantidad de conocimientos y experiencias relacionales en la arquitectura y la ingeniería de DWH y conjuntos de datos.

• Manejar una auditoría Sarbanes-Oxley o del ENS, en España, 
• Manejar una actualización en marcha, 
• Realizar una migración con tiempo de inactividad casi cero.
• Recuperarse de un desastre

Esos conocimientos, ya están dentro del know-how del DBA del dia a dia. Sólo necesita que se extiende hacia las disciplinas de gestión de datos de reciente introducción.

	Programador	Analista bbdd	Diseñador bbdd	Arquitecto BBDD	DBA	Especialista Sistemas	Especialista Almacenamiento	Especialista Red	Especialista Seguridad	Arquitecto Solución
Diseño BBDD	indirecto	indirecto	directo	indirecto	indirecto					directo
Desarrollo BBDD	directo		directo	indirecto	directo	indirecto	indirecto	indirecto	indirecto	indirecto
Arquitectura BBDD				directo	directo	indirecto	indirecto	indirecto	indirecto	indirecto
Análisis Datos	directo	directo		directo	indirecto
Instalación/ actualización bbdd	indirecto			directo	directo	indirecto	indirecto			indirecto
Optimizador Consultas	directo	directo	indirecto	indirecto	directo
Copia Restauración bbdd				indirecto	directo	indirecto	indirecto			indirecto
Aprovisionamiento Nube			indirecto	directo	directo	directo	directo	directo	directo	directo
Operaciones Almacenamiento				indirecto	indirecto	directo	directo			indirecto
Operaciones Red				indirecto	indirecto	directo	indirecto			indirecto
Control Seguridad				indirecto	indirecto	directo	indirecto	indirecto	directo	indirecto

El dato es el rey

Observando la evolución del panorama de los sistemas de gestión de datos desde el año 2000, es una apuesta bastante segura suponer que la tecnología en sí comenzará a perder su importancia, mientras que las habilidades tecnológicas prosperarán como el panorama de software de gestión de datos se expande y se diversifica. Aunque NoSQL y Big data ofrecen  nuevas técnicas para el tratamiento de la información, esta proposición está todavía lejos de ser completa y es aquí donde los DBA pueden llenar el vacío.

Esto a su vez induce un cambio importante en la perspectiva y la forma de pensar de los expertos en tecnología relacional actuales. Técnicas, algoritmos y patrones que son comunes a NoSQL y big data pueden ser implantados en los sistemas de bases de datos para mejorar la disponibilidad, la capacidad y el rendimiento. 

Esto ya ha empezado: Map Reduce ha sido utilizado en los datawarehouse durante muchos años, sólo con una terminología diferente. Del mismo modo, los patrones de acceso de clave y valor de los DWH no son nuevos en absoluto a las bases de datos que eran capaces de trabajar de forma asíncrona desde hace décadas. Lo que hizo fue el cambio continuo avance en la tecnología de hardware ligada a la evolución de los requisitos de disponibilidad y tamaño de los datos. A punto de romper la ley de Moore y justo por delante de la próxima revolución en-memoria, puede resultar que todos los sistemas de gestión de datos usen ambas aproximaciones de mana conjunta.

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');