Close Menu
Oracle Troubleshooting

ORA-29548 — Java System Class Reported: Dictionary Version Mismatch

HenriqueBy 5 Mins Read

This post is also available in: Português (Portuguese (Brazil))

ERROR at line 1:
ORA-29548: Java system class reported: release of Java system classes
in the database (19.0.0.0.210420 1.8) does not match that of the oracle
executable (19.0.0.0.0 1.8)

This error surfaces when Oracle detects a version mismatch between the Java installed in the Oracle Home (on the filesystem) and the Java classes loaded in the data dictionary. In the vast majority of cases, it shows up right after applying a Release Update (RU) or PSU that updated the Oracle binary but left the internal JVM out of sync.

💡 In Practice

ORA-29548 is not an application bug — it’s the direct result of an incomplete patch cycle. The opatchauto or opatch apply command updates the Oracle Home, but the Java classes in the data dictionary need a separate update step, either through datapatch or a manual script. When that step is skipped or silently fails, any operation that invokes the internal Oracle JVM will trigger this error — including Java stored procedures, DBMS_SCHEDULER jobs using Java classes, and even Data Pump in certain scenarios.

Why It Happens

Oracle keeps Java in two separate places:

  1. In the Oracle Home ($ORACLE_HOME/javavm/) — the filesystem binaries, updated by OPatch.
  2. In the data dictionary — the Java classes loaded inside the database (SYS.JAVA$CLASS$MD5$TABLE and related structures), which must be synchronized separately.

When an RU or PSU is applied, component (1) gets updated. Component (2) stays at the previous version until the post-patch step completes. Oracle catches this divergence at runtime and raises ORA-29548 on any call that touches the internal JVM.

Common scenarios where this occurs:

  • RU/PSU applied without running datapatch after the database restart
  • datapatch ran but encountered a silent error in the OJVM component
  • Patch rollback that included the OJVM component
  • Database created from an already-patched Oracle Home without running datapatch on the new instance

Diagnosis

Before fixing, confirm the version mismatch:

-- Version loaded in the data dictionary
SELECT dbms_java.get_jdk_version() FROM dual;

-- Version in the Oracle Home (run in the shell)
-- $ORACLE_HOME/jdk/bin/java -version

If the SELECT returns ORA-29548, the mismatch is confirmed. The error message itself shows both conflicting versions — use this to verify after the fix.

Also check the patch status in the dictionary:

SELECT patch_id, version, action, status, description
FROM   dba_registry_sqlpatch
ORDER  BY action_time DESC
FETCH FIRST 10 ROWS ONLY;

If the last OJVM-related patch shows status WITH ERRORS, datapatch did not complete cleanly — go directly to Solution 1 below.

Fix

Solution 1 — Manual script (fastest and safest)

⚠️ Prerequisite: The database must be in OPEN state, not MOUNT. Run as SYS.

sqlplus / as sysdba
SQL> @?/javavm/install/update_javavm_db.sql

This script reloads and synchronizes the Java system classes in the data dictionary. Execution time ranges from a few minutes to tens of minutes depending on the environment. Do not interrupt it.

For CDB/Multitenant environments: the script must be run in CDB$ROOT and in each PDB where the error occurs:

-- In CDB$ROOT
SQL> @?/javavm/install/update_javavm_db.sql

-- Switch to each affected PDB and repeat
SQL> ALTER SESSION SET CONTAINER = your_pdb_name;
SQL> @?/javavm/install/update_javavm_db.sql

ℹ️ In RAC environments, the data dictionary is shared across instances. Running the script once from any node is sufficient — no need to repeat on each node.

Solution 2 — Via datapatch (recommended after an RU/PSU)

If the database was patched with a recent RU and datapatch was not executed correctly, run it now:

$ORACLE_HOME/OPatch/datapatch -verbose

In RAC, datapatch runs from a single node. The data dictionary is shared across the cluster.

ℹ️ If datapatch was already executed but ORA-29548 persists, the OJVM component may not have been included in the applied RU, or there was a silent error during patching. Use Solution 1 as a fallback.

Validation

After applying the fix, confirm that the versions are in sync:

SQL> SELECT dbms_java.get_jdk_version() FROM dual;

DBMS_JAVA.GET_JDK_VERSION()
--------------------------------------------------------------------------------
1.8.0_201

1 row selected.

If the query returns a version without error, the JVM is synchronized and the issue is resolved.

Quick Reference

-- 1. Confirm the error
SELECT dbms_java.get_jdk_version() FROM dual;

-- 2. Check the last OJVM patch status
SELECT patch_id, version, action, status, description
FROM   dba_registry_sqlpatch
ORDER  BY action_time DESC
FETCH FIRST 5 ROWS ONLY;

-- 3a. Fix via script (database open, run as SYS)
@?/javavm/install/update_javavm_db.sql

-- 3b. Alternative via datapatch (shell)
-- $ORACLE_HOME/OPatch/datapatch -verbose

-- 4. Validate
SELECT dbms_java.get_jdk_version() FROM dual;

References

  • Oracle Database Error Messages — ORA-29548
  • Oracle Patching Documentation: Post-Patch SQL Actions (datapatch)
  • MOS Note 1609718.1 — Using the datapatch Utility (verify)
Share.

Related Posts

Add A Comment
Leave A Reply