Tip rápido: Componentes de registro de base de datos Oracle 19c no válidos, tras un parcheo

 

Oracle JVM es un entorno estándar compatible con Java que ejecuta cualquier aplicación Java pura. Es compatible con las especificaciones JLS estándar y JVM. Es compatible con el formato binario estándar de Java y las API estándar de Java. Además, Oracle Database se adhiere a la semántica del lenguaje Java estándar, incluida la carga dinámica de clases en tiempo de ejecución.

Java en Oracle Database presenta los siguientes términos:

• Sesión (session)

Una sesión en el entorno Java de Oracle Database es idéntica al uso estándar de Oracle Database. Una sesión suele estar limitada, aunque no necesariamente, por el momento en que un solo usuario se conecta al servidor. Como usuario que llama a un código Java, debe establecer una sesión en el servidor.

• Llamada (call)

Cuando un usuario hace que un código Java se ejecute dentro de una sesión, se denomina llamada. Una llamada se puede iniciar de las siguientes formas diferentes:

• Un programa de cliente SQL ejecuta un procedimiento almacenado de Java.
• Un desencadenador ejecuta un procedimiento almacenado de Java.
• Un programa PL / SQL llama a un código Java.

En todos los casos definidos, comienza una llamada, se ejecuta alguna combinación de código Java, SQL o PL / SQL hasta su finalización y la llamada finaliza.

Los siguientes componentes de JAVAVM no son válidos durante la revisión de la base de datos 19c.

Es necesario ejecutar los siguientes pasos para reparar los componentes dañados de la base de datos.

Primero: Verifica que el componente JAVAVM no sea válido

col comp_id for a10

col version for a11

col status for a10

col comp_name for a37

select comp_id,comp_name,version,status from dba_registry;

Segundo: Valida el componente JAVAVM

execute sys.dbms_registry.invalid(‘JAVAVM’);

execute sys.dbms_registry.valid(‘JAVAVM’);

SQL> execute sys.dbms_registry.invalid(‘JAVAVM’);

PL/SQL procedure successfully completed.

SQL> execute sys.dbms_registry.valid(‘JAVAVM’);

PL/SQL procedure successfully completed.

SQL> col comp_id for a10

col version for a11

col status for a10

col comp_name for a37

select comp_id,comp_name,version,status from dba_registry;

¿Hay vida más allá de Oracle? Psi-probe para Apache Tomcat

 

Psi-probe es un monitor de Apache Tomcat que nació como un fork de Lambda Probe, debido a la falta de soporte sobre el mismo y las dudas en cuanto a su futuro.

Psi-probe es un proyecto con licencia GPLv2 que, según describen en su propia documentación, permite monitorizar en remoto el estado del servidor en los siguientes aspectos:

• peticiones: dispone de un monitor de tráfico en tiempo real,
• sesiones: analizar atributos en sesión, estimar el peso de las mismas,
• jsp: navegar, ver el código fuente, recompilar!.
• fuentes de datos: analizar el uso del pool de conexiones, ejecutar queries.
• logs: ver el contenido, descargar, cambiar el nivel de trazabilidad en caliente.
• hilos: ver la pila de ejecución, «matarlos».
• conectores: ver el estado, usando gráficas.
• cluster: ver el estado, usando gráficas.
• JVM: ver el uso de memoria, lanzar el GC, reiniciar la JVM.
• Sistema: uso de CPU, memoria,…

Está documentada su instalación tanto en Apache Tomcat como en Jboss Application Server, con el objetivo de reemplazar el tomcat manager ofreciendo mucha más funcionalidad, para el primero, o simplemente de disponer de un monitor online de la salud de tu servidor, para el segundo.

• Hardware: Portátil Compaq  (2.4 GHz Intel Core i7, 4GB DDR3).
• Sistema Operativo: Windows 10 64 bits
• Apache Tomcat 9.0.13.
• Apache Maven: 3.6.3.
• psi-probe 3.5.2.

Instalación en Apache Tomcat.

Tras descargar el paquete de instalación lo único que tenemos que hacer es «tirar el war» probe.war en el directorio de despliegue de Apache Tomcat y, en función de si tenemos configurado el despliegue automático o no, configurar la aplicación web como tal, por defecto, no habría que hacer nada más que revisar la política de autenticación y autorización de tomcat definida en el fichero tomcat-users.xml del directorio conf.

Se pueden definir 4 niveles de autorización, asumiendo que manager es la más alta, con lo que si ya tenías definido un usuario con ese rol para el Tomcat Manager, no necesitas tocar nada.

Por último, si quieres acceder a toda la información de la JVM desde probe debes habilitar el acceso en remoto a la consola de JVM.

 Monitorización.

Una vez levantado el servidor y a través de la url que da acceso al contexto de la aplicación http://localhost:8080/probe podremos acceder con el usuario y contraseña configurados en Tomcat a la aplicación de monitorización.

La primera interfaz que se muestra es la de las aplicaciones instaladas en la que se puede comprobar que aparece el propio probe.

Pulsando sobre una aplicación podemos acceder a un breve detalle de toda la información que se recolecta sobre la misma:

En este caso he arrancado la demo de MyFaces Tobago. Tobago es un "framework"y una "libreria" de componentes JavaServer Faces (JSF). Que proporciona una forma cómoda de diseñar pantallas de aplicaciones similares a las de un escritorio con una apariencia y sensación coherentes. Tobago enfatiza la separación de estructura y diseño de pantallas. Próximamente haré una introducción a este "framework"

Pulsando sobre la sección correspondiente podemos analizar información sobre las sesiones activas:

se pueden eliminar las sesiones, estimar el tamaño que ocupan y pulsando sobre la misma podemos ver todos los objetos que se mantienen en la sesión del usuario en el servidor; pudiendo incluso realizar un segundo nicel de estimación del tamaño que ocupan dichos objetos en la memoria del servidor.

Existen más opciones en el menú izquierdo, entre ellas la de visualizar el contenido del descriptor de despliegue:

los servlets configurados y los parámetros de inicialización y de contexto de los servlets.

En la opción de logs podemos acceder a un listado de los ficheros que trazamos. 

y pulsando sobre uno de ellos, se puede visualizar el log, como si hiciéramos un "tail", sobre él mismo. del fichero:

Información sobre el sistema, sobre fuentes JDBC (en este ejemplo, no figuran)

Descripción del sistema

Conectores

En la pestaña de conectores podemos acceder a la monitorización de las peticiones que se realizar a través de los distintos conectores, disponiendo de información gráfica sobre número de peticiones, tiempo de proceso y volumen del tráfico de estas conexiones.

La última de las opciones es un chequeo rápido de la salud del servidor teniendo en cuenta el uso de las fuentes de datos, la memoria, el número de descriptores de fichero disponibles y si las aplicaciones están levantadas o no.

Está en vuestras manos ponerlo en producción. Si no, en cualquier entorno, incluso en el de desarrollo te puede servir como soporte de una monitorización del sistema durante pruebas de carga o estrés.

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.