Search for a command to run...
Ingeniero informático, Oracle ACE, DBA y Arquitecto OCI, con más de 15 años de experiencia en plataformas Oracle. Certificado en OCI Certified Architect Professional y OCI Migration and Integration Certified Professional.
No comments yet. Be the first to comment.
Después de aplicar los parches en algunas databases, revisando el alert log después de aplicarlo me encontré con la siguiente aviso: 2024-01-15T08:06:20.218720+01:00 NET (PID:9914): Archived Log entry 5188 added for T-1.S-5146 ID 0x52522246 LAD:1 20...
En el artículo de hoy vamos a ver las Calendar functions en 26ai, diseñadas para simplificar la "vida" a los desarrolladores. Antes de su existencia, esto se resolvía con ingeniosas combinaciones usan
![[26ai] SQL: Calendar functions/Aggregation Filters "CALENDAR"](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F587e3328-9877-4c7a-aad7-7811e251f81e.png&w=3840&q=75)
En el artículo de hoy vamos a ver como podemos recrear una PDB$Seed de manera fácil en caso que se quede corrupta y no tengamos backup. sys@> alter pluggable database PDB$SEED open read only; alter pl
![[OCI] Recreación PDB$SEED](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F289ede5b-558c-4f93-b5c0-fa04680c91ca.png&w=3840&q=75)
El artículo también se encuentra publicado en Ingles English version. En el artículo de hoy vamos a ver como podemos clonar una PDB usando RMAN Active Duplicate o bien usando una instrucción DDL entre
![[OCI] Clone PDB](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F8ce0c665-4a5d-459d-91cf-ffe3f47d8176.png&w=3840&q=75)
El artículo también se encuentra publicado en Ingles English version. En el artículo de hoy voy a compartir un sh que utilizo para ver de una manera rápida los jobs que se ejecutan desde Oracle Databa
![[OCI] Check Jobs DBCli](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F1376a869-58fa-491e-926a-a6ead08f9c80.png&w=3840&q=75)
El artículo también se encuentra publicado en Ingles English version. En el artículo de hoy vamos a ver la nueva sintaxis introducida para simplificar aún más los joins evitando errores comunes, hacie
![[26ai] JOIN_TO_ME](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F16a23f6e-ec4c-4f0a-9529-2c8a2af2ef5e.png&w=3840&q=75)
Vamos a tratar de solucionar el siguiente error que teníamos presente en el alert log.
__(3):joxcsys: release mismatch, 19.0.0.0.230718 1.8 in database (classes.bin) vs 19.0.0.0.231017 1.8 in executable pid 35577 cid 3
2024-01-29T09:27:44.180287+01:00
Parece un error poco común a nivel de Java.
Para ver si tenemos algún error en la BBDD con Java, vamos a intentar ver si la api de DBMS_JAVA funciona con normalidad
SQL> select dbms_java.get_jdk_version() from dual;
select dbms_java.get_jdk_version() from dual
*
ERROR at line 1:
ORA-29548: Java system class reported: release of Java system classes in the
database (19.0.0.0.230718 1.8) does not match that of the oracle executable
(19.0.0.0.231017 1.8)
No da respuesta. Mirando en la página de Oracle, concretamente la nota Doc ID 2934546.1 indica que uno de los motivos de error puede ser el siguiente "The Oracle JVM component became invalid after applying or rolling back an OJVM PSU patch to the database"
Así que vamos a realizar los siguientes pasos que nos indican a ver si conseguimos solucionar el error
SQL> shu immediate
SQL> startup upgrade
....
SQL> alter pluggable database all open upgrade ;
SQL> quit
[oracle@~]$ cd $ORACLE_HOME/OPatch
[oracle@OPatch]$ datapatch -verbose
SQL Patching tool version 19.21.0.0.0 Production on Mon Jan 29 09:35:34 2024
Copyright (c) 2012, 2023, Oracle. All rights reserved.
....
Una vez aplicado cada paso anterior de manera exitosa y al ejecutar el OPatch, tenemos que recompilar siempre los objetos con el script @?/rdbms/admin/utlrp.sql.
SQL> shu immediate
SQL> startup
SQL> alter pluggable database all open;
SQL> @?/rdbms/admin/utlrp.sql
Una vez finalizamos y vemos que el script se ha ejecutado bien, volvemos a ejecutar la api DBMS_JAVA a ver si nos devuelve información
SQL> select dbms_java.get_jdk_version() from dual;
DBMS_JAVA.GET_JDK_VERSION()
--------------------------------------------------------------------------------
1.8.0_391
Bien, a nivel de CDB$ROOT funciona, probamos a nivel de PDB
SQL> select dbms_java.get_jdk_version() from dual;
select dbms_java.get_jdk_version() from dual
*
ERROR at line 1:
ORA-29548: Java system class reported: release of Java system classes in the
database (19.0.0.0.230718 1.8) does not match that of the oracle executable
(19.0.0.0.231017 1.8)
Vaya, seguimos con el mismo error, ¿Qué sucede?.
Revisando el alert log vemos que el motivo de error es porque las versiones han quedado desalineadas entre CDB$ROOT y la PDB
(3):joxcsys: release mismatch, 19.0.0.0.230718 1.8 in
database (classes.bin) vs 19.0.0.0.231017 1.8 in executable pid 74271 cid 3
Para alinear ambas versiones, lo que vamos hacer es ejecutar el script @?/javavm/install/update_javavm_db.sql a nivel de PDB, no a nivel de CDB$ROOT
SQL> @?/javavm/install/update_javavm_db.sql
....
Una vez que se ejecute con éxito, probamos de nuevo
SQL> select dbms_java.get_jdk_version() from dual;
DBMS_JAVA.GET_JDK_VERSION()
--------------------------------------------------------------------------------
1.8.0_391
Perfecto, ya funciona DBMS_JAVA a nivel de PDB. Espero que os sirva.