This post is also available in:
When running any operation that relies on Java inside the Oracle Database, you may encounter the following error:
SQL> 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.210420 1.8) does not match that of the oracle executable
(19.0.0.0.0 1.8)This error isn’t limited to dbms_java — it can appear on any call that uses Oracle’s internal JVM, including Java stored procedures, OJVM, DBMS_SCHEDULER with Java classes, and even Data Pump exports in certain scenarios.
In this article, I’ll explain why this error occurs, what the most common root cause is, and how to resolve it correctly and safely.
💡 In practice: In the vast majority of cases, this error appears after applying a Release Update (RU) or Patch Set Update (PSU) to the Oracle Home. The patch updates the Oracle executable, but the Java classes inside the data dictionary remain at the previous version until manually updated.
Why the ORA-29548 Error Occurs
The Oracle Database has an internal JVM (OJVM) that runs inside the database. This JVM has two components that must stay in sync:
- Java in the Oracle Home — the binaries and Java classes installed on the filesystem (
$ORACLE_HOME/javavm/) - Java in the data dictionary — the Java classes loaded inside the database (
SYS.JAVA$CLASS$MD5$TABLE, etc.)
When you apply a Release Update (RU) to the Oracle Home, component (1) gets updated. But component (2) — inside the database — stays at the previous version until explicitly updated.
The ORA-29548 error occurs when Oracle detects this version mismatch between the two components.
When does this happen
- After applying an RU/PSU to the Oracle Home without completing Java post-patching
- After a database upgrade where the OJVM update step was skipped
- After rolling back a patch that included the OJVM component
- In RAC environments where the patch was applied to the homes but
datapatchorupdate_javavm_db.sqlwas not executed on all instances
Diagnosis
Before fixing, confirm the version mismatch.
Check Java version in the Oracle Home (filesystem)
$ORACLE_HOME/jdk/bin/java -versionCheck Java version in the database
-- Connect as SYS
sqlplus / as sysdba
-- Check JAVAVM and CATJAVA components
SELECT comp_name, version, status
FROM dba_registry
WHERE comp_name LIKE '%JAVA%' OR comp_name LIKE '%JAVAVM%';Expected output (when there’s a mismatch):
COMP_NAME VERSION STATUS
------------------------------ -------------------- ----------
JServer JAVA Virtual Machine 19.0.0.0.0 VALID
Oracle Java Packages 19.0.0.0.0 VALIDIf VERSION doesn’t match the applied RU version (e.g., should be 19.21.0.0.0 after RU 19.21), Java is outdated.
Check if datapatch already ran
$ORACLE_HOME/OPatch/datapatch -verbose <strong>2</strong>><strong>&1</strong> | tail -20Or via SQL:
SELECT patch_id, action, status, description
FROM dba_registry_sqlpatch
ORDER BY action_time DESC
FETCH FIRST 10 ROWS ONLY;If the OJVM patch doesn’t appear as SUCCESS, it hasn’t been applied to the database.
Solution 1: Run update_javavm_db.sql (Most Common)
This is the direct method and works on all Oracle versions.
Step 1 — Connect as SYS AS SYSDBA
sqlplus / as sysdbaImportant: The script must be executed as
SYS AS SYSDBA. Any other user will result in permission errors.
Step 2 — Run the update script
@?/javavm/install/update_javavm_db.sqlThe ? is a SQL*Plus shortcut for $ORACLE_HOME. The full path would be:
@$ORACLE_HOME/javavm/install/update_javavm_db.sqlStep 3 — Wait for completion
⚠ Warning: This script can take 5 to 30+ minutes depending on database size and storage performance. Do not interrupt execution.
During execution, the script:
- Updates Java classes in the data dictionary
- Recompiles invalid Java objects
- Synchronizes the OJVM version with the Oracle Home
Step 4 — Validate
-- Should return without error
SELECT dbms_java.get_jdk_version() FROM dual;
-- Check component status
SELECT comp_name, version, status
FROM dba_registry
WHERE comp_name LIKE '%JAVA%';STATUS should be VALID and VERSION should match the applied RU.
Solution 2: Use datapatch (Oracle 12c+)
On Oracle 12c and later, datapatch is Oracle’s recommended method for applying patch changes to the data dictionary — including OJVM.
# Run as Oracle Home owner
cd $ORACLE_HOME/OPatch
./datapatch -verbosedatapatch automatically detects which patches have been applied to the Home and which haven’t been applied to the database yet.
Verify after execution
SELECT patch_id, action, status, description
FROM dba_registry_sqlpatch
ORDER BY action_time DESC
FETCH FIRST 5 ROWS ONLY;If the OJVM patch appears with status = SUCCESS, the issue is resolved.
Note: If
datapatchwas executed and ORA-29548 persists, the OJVM patch may not be included in the RU you applied, or there was a silent error. In that case, use Solution 1 as a fallback.
RAC Considerations
In Oracle RAC environments, the Java update needs to be executed on each instance of the cluster.
# Check which instance you're on
sqlplus / as sysdba
SQL> SELECT instance_name FROM v$instance;
# Run the script or datapatch on EACH node
# Node 1
sqlplus / as sysdba
@?/javavm/install/update_javavm_db.sql
# Node 2 (SSH and repeat)
ssh oracle@node2
export ORACLE_SID=DBNAME2
export ORACLE_HOME=/u01/app/oracle/product/19c/dbhome_1
sqlplus / as sysdba
@?/javavm/install/update_javavm_db.sqlRAC with datapatch: Running
datapatchon one node usually propagates to the shared database. But verify the status on all instances to be sure.
Quick Diagnostic Checklist
-- 1. Check Java version in the Home
-- (run in shell, not SQL*Plus)
-- $ORACLE_HOME/jdk/bin/java -version
-- 2. Check Java components in the database
SELECT comp_name, version, status
FROM dba_registry
WHERE comp_name LIKE '%JAVA%';
-- 3. Check patches applied to the database
SELECT patch_id, action, status, description
FROM dba_registry_sqlpatch
ORDER BY action_time DESC
FETCH FIRST 10 ROWS ONLY;
-- 4. Test if the error persists
SELECT dbms_java.get_jdk_version() FROM dual;Conclusion
The ORA-29548 error is caused by a version mismatch between Java in the Oracle Home and the version loaded in the data dictionary. In the vast majority of cases, it appears after applying a Release Update that wasn’t fully propagated to the database.
The correct diagnosis follows this order:
- Verify the mismatch — compare Java version in the Home vs the database
- Check if datapatch ran — check
dba_registry_sqlpatch - Apply the fix —
datapatch(preferred) orupdate_javavm_db.sql - Validate —
SELECT dbms_java.get_jdk_version() FROM dual - In RAC — ensure the fix was applied on all instances
Once versions are synchronized, the error disappears and all Java operations return to normal.
References:
