Oracle Database java component not valid !

I have faced strange problem when applying July 2019 CPU patch in Oracle 12cR2 (12.2.0.1) database !

So I wanted to share it in my blog in case somebody faced a similar issue.

Symptoms:

Java component is not valid

select * from dba_registry;

when you execute utlrp for recompilation

SQL> @?/rdbms/admin/utlrp.sql

The following error is displayed:

### validate_javavm caught -29548

In the alert log file…the following error is thrown:

joxcsys: release mismatch, 12.2.0.1.190416 1.8 in database (classes.bin) vs 12.2.0.1.190716 1.8 in executable pid 28179 cid 0

SQL> select dbms_java.longname(‘TEST’) from dual;

select dbms_java.longname(‘TEST’) from dual

*

ERROR at line 1:

ORA-29548: Java system class reported: joxcsys: release mismatch,

12.2.0.1.190416 1.8 in database (classes.bin) vs 12.2.0.1.190716 1.8 in Executable

Proposed solution:

the first way: shutdown the database and listener and perform relinking

make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk javavm_refresh ioracle

The second way:

Roll-back the OJVM patch and re-apply the patch again:

SQL> shutdown immediate;

lsnrctl stop listener_db11

$ORACLE_HOME/OPatch/opatch rollback -id 29774415

SQL> startup upgrade;

cd $ORACLE_HOME/OPatch

./datapatch –verbose

After roll-back is successful….apply the patch again and execute utlrp.sql to ensure JAVA component is now valid !

I hope this blog post helps !

synchronize & upgrade Oracle standby database after primary database upgrade

This guide will illustrate the required steps to Upgrade & Synchronize physical standby database after upgrading primary oracle database. Note that physical standby is not setup based on “data guard” technology.

In this simulation…i am simulating that primary database was upgraded from Oracle 12cR1 to 12cR2 ( this is still applicable with newer releases).

1. before proceeding with upgrading primary database, put the physical standby database in read-only mode

sqlplus / as sysdba

SQL> shutdown immediate;
SQL> STARTUP NOMOUNT;
SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

SQL> ALTER DATABASE OPEN READ ONLY;

SQL> select OPEN_MODE,DATABASE_ROLE from v$database;

OPEN_MODE DATABASE_ROLE

——————– —————-

READ ONLY PHYSICAL STANDBY

2. upgrade the primary database – please refer Oracle documentation for Oracle database upgrade documentation….also you can reference my own previous articles:

https://geodatamaster.com/2019/06/01/oracle-database-new-auto-upgrade-tool-simulation/

https://geodatamaster.com/2018/08/28/upgrading-oracle-database-from-12cr2-to-18c-in-windows/

https://geodatamaster.com/2017/04/02/upgrading-oracle-database-from-12cr1-to-12cr2-in-windows-environment/

3. After successfully upgrading the primary Oracle database,move the new and patched binries from the “primary” database server to the “standby” database server

mkdir /stdby/orcl/

cd /stdby/orcl/
tar -cf oraInventory.tar -P $ORACLE_BASE/product/oraInventory

tar -cf 12cR2.tar -P $ORACLE_BASE/product/12.2

4. go to the database standby server

**** shutdown standby database

sqlplus / as sysdba

SQL> shutdown immediate;

*** update your user profile to point to the new binaries
cd

vi .profile

%s/12.1/12.2/g
*** rename old database binaries

cd /app/orcl/product

mv 12.1 12.1.old

*** refresh your user profile exit the shell and enter again

echo $ORACLE_HOME
*** untar the new binaries

cd /app/orcl/product

tar -xf /stdby/orcl/oraInventory.tar -P
tar -xf /stdby/orcl/12cR2.tar -P
*** startup the standby database in standby mode:

SQL> STARTUP NOMOUNT;

SQL> ALTER DATABASE MOUNT STANDBY DATABASE;

SQL> RECOVER AUTOMATIC STANDBY DATABASE;

SQL> select open_mode,database_role from v$database;
*** Remark: keep applying the logs and monitor standby database alert log file