ORACLE JVM DIAGNOSTICS | Article

Oracle JVM is one of those components that silently breaks and stays broken until something downstream explodes at the worst possible moment. This post walks through every diagnostic layer — from registry presence checks down to memory pool analysis — so you can triage a JVM issue in minutes rather than hours.

All queries run as DBA in SQL*Plus against an OPEN database. Written against Oracle 11.2.0.3.2; notes for 19c / 21c are included where behavior diverges.

The Diagnostic Checklist at a Glance

Before diving into each step, here is the full picture. Work through these in order — the early checks are fast and eliminate the obvious causes first.

#	Check	Object queried	What you are looking for
1.1	Component banners	`ALL_REGISTRY_BANNERS`	JServer JAVA Virtual Machine and Oracle Database Java Packages present
1.2	Component registry	`DBA_REGISTRY`	`JAVAVM` and `CATJAVA`, both `VALID`
1.3	Engine option flag	`V$OPTION`	`Java = TRUE`
2.1	Java object counts	`DBA_OBJECTS`	SYS ≥ ~19,000 JAVA CLASS; zero INVALID rows
2.2	DBMS_JAVA package	`DBA_OBJECTS`	All PACKAGE and PACKAGE BODY entries `VALID`
2.3	Invalid object list	`DBA_OBJECTS` + `sys.javasnm$`	no rows selected
2.4	Java Pool memory	`V$SGASTAT`	Pool present; free memory > 5 MB
2.5	Java roles	`DBA_ROLES`	All five core roles present

The Diagnostic CheckList

Part 1 — Is JVM Actually Installed?

1.1 ALL_REGISTRY_BANNERS

This view is the quickest sanity check. It lists every component that has completed installation and registered itself as valid. Two lines must be present for JVM to be considered operational.

SELECT *
FROM all_registry_banners;

Healthy output — both of these lines must appear:

JServer JAVA Virtual Machine          Release 11.2.0.3.0 - Production
Oracle Database Java Packages         Release 11.2.0.3.0 - Production

Full example of a healthy database:

BANNER
-------------------------------------------------------------------
Oracle Database Catalog Views         Release 11.2.0.3.0 - 64bit Production
Oracle Database Packages and Types    Release 11.2.0.3.0 - Production
Oracle Workspace Manager              Release 11.2.0.3.0 - Production
JServer JAVA Virtual Machine          Release 11.2.0.3.0 - Production
Oracle XDK                            Release 11.2.0.3.0 - Production
Oracle Database Java Packages         Release 11.2.0.3.0 - Production
Oracle Expression Filter              Release 11.2.0.3.0 - Production

Example of a database without JVM:

BANNER
-------------------------------------------------------------------
Oracle Database Catalog Views         Release 11.2.0.3.0 - 64bit Production
Oracle Database Packages and Types    Release 11.2.0.3.0 - Production
Oracle Workspace Manager              Release 11.2.0.3.0 - Production
Oracle Expression Filter              Release 11.2.0.3.0 - Production

If either JVM banner is missing, do not stop here. Proceed to DBA_REGISTRY to determine whether the component is absent or merely invalid.

1.2 DBA_REGISTRY

DBA_REGISTRY gives you the full story: not just whether a component is present, but its exact status. This is where you distinguish between JVM not installed (no rows) and JVM installed but broken (INVALID status). The distinction matters — they have different remediation paths.

SELECT comp_id, comp_name, version, status
FROM dba_registry;

Healthy output — both component IDs present and VALID:

COMP_ID	COMP_NAME	VERSION	STATUS
EXF	Oracle Expression Filter	11.2.0.3.0	VALID
OWM	Oracle Workspace Manager	11.2.0.3.0	VALID
CATALOG	Oracle Database Catalog Views	11.2.0.3.0	VALID
CATPROC	Oracle Database Packages and Types	11.2.0.3.0	VALID
JAVAVM	JServer JAVA Virtual Machine	11.2.0.3.0	VALID
XML	Oracle XDK	11.2.0.3.0	VALID
CATJAVA	Oracle Database Java Packages	11.2.0.3.0	VALID

Three possible outcomes:

JAVAVM and CATJAVA absent — JVM was never installed. Requires a full JVM installation via $ORACLE_HOME/javavm/install/initjvm.sql.
JAVAVM or CATJAVA present with status INVALID — JVM installed but corrupted. Requires reinstallation or targeted recompilation.
Both present and VALID — proceed to the remaining checks.

Oracle 19c / 21c — Multitenant note: JVM is a PDB-level component in CDB architectures. Run this query connected to the target PDB, not CDB$ROOT. CDB$ROOT will not show JAVAVM or CATJAVA regardless of JVM state in the PDBs.

1.3 V$OPTION

This check is easy to overlook and it catches a specific class of problem: JVM objects can be fully installed and valid while the Java engine option is disabled at the instance level. In that state, no Java will execute — all you get is ORA-29549: class ... has changed, Java session state cleared or similar runtime errors.

SELECT *
FROM v$option
WHERE parameter = 'Java';

PARAMETER	VALUE
Java	TRUE

TRUE means the option is licensed and active. FALSE means Java execution is disabled at the engine level — re-linking the Oracle binary with the Java option enabled is required, which is an OS-level operation on the database host.

Oracle 19c / 21c note: Oracle Database XE and certain Oracle Cloud managed configurations ship with Java = FALSE even when the schema objects exist. If you are on a managed platform, verify with your cloud provider whether Java execution is supported in your tier.

Part 2 — Java Object Inspection

2.1 Java Object Counts in SYS

A complete JVM installation loads tens of thousands of Java class, resource, and data objects into SYS. If the counts are well below the expected range, the installation was likely interrupted or partially applied. Use these numbers as reference — not hard thresholds, since patch level affects counts slightly.

SELECT owner, object_type, status, COUNT(*)
FROM dba_objects
WHERE object_type LIKE '%JAVA%'
GROUP BY owner, object_type, status
ORDER BY owner, object_type, status;

Reference thresholds for SYS on 11.2.0.3:

OBJECT_TYPE	Minimum expected	Typical healthy value
JAVA CLASS	~19,000	~20,500
JAVA DATA	~250	~317
JAVA RESOURCE	~700	~761

Example of a healthy result:

OWNER	OBJECT_TYPE	STATUS	COUNT(*)
EXFSYS	JAVA CLASS	VALID	47
EXFSYS	JAVA RESOURCE	VALID	1
SYS	JAVA CLASS	VALID	20,500
SYS	JAVA DATA	VALID	317
SYS	JAVA RESOURCE	VALID	761
SYS	JAVA SOURCE	VALID	2

Any INVALID rows in the SYS section, or object counts significantly below the minimums, are a signal to run the full invalid-object query in section 2.3.

Oracle 19c / 21c note: Expect JAVA CLASS counts in SYS to be in the 30,000–40,000 range due to expanded core libraries. Anything below ~25,000 on a default 19c install warrants investigation.

2.2 DBMS_JAVA Package Validity

DBMS_JAVA is the primary PL/SQL bridge to the JVM. If its package body is invalid, any code calling it will fail — even if all underlying Java objects are fine. This check also catches broken public synonyms, which cause user-facing resolution errors.

SELECT owner, object_name, object_type, status
FROM dba_objects
WHERE object_name LIKE 'DBMS_JAVA%'
   OR object_name LIKE '%INITJVMAUX%'
ORDER BY owner, object_name, object_type;

Expected output — every row must be VALID:

OWNER	OBJECT_NAME	OBJECT_TYPE	STATUS
PUBLIC	DBMS_JAVA	SYNONYM	VALID
PUBLIC	DBMS_JAVA_DUMP	SYNONYM	VALID
PUBLIC	DBMS_JAVA_TEST	SYNONYM	VALID
SYS	DBMS_JAVA	PACKAGE	VALID
SYS	DBMS_JAVA	PACKAGE BODY	VALID
SYS	DBMS_JAVA_DEFINERS	PACKAGE	VALID
SYS	DBMS_JAVA_DEFINERS	PACKAGE BODY	VALID
SYS	DBMS_JAVA_DUMP	PACKAGE	VALID
SYS	DBMS_JAVA_DUMP	PACKAGE BODY	VALID
SYS	DBMS_JAVA_TEST	PACKAGE	VALID
SYS	DBMS_JAVA_TEST	PACKAGE BODY	VALID

An INVALID PACKAGE BODY in SYS with a valid PACKAGE spec typically means the installation was partially applied. A missing PACKAGE BODY row entirely indicates the install script did not complete.

2.3 Enumerate All INVALID Java Objects

This query joins against sys.javasnm$ to resolve the short internal object names that Oracle uses internally back to their full class names. Without this join you get meaningless truncated identifiers that tell you nothing about which class is broken.

SELECT owner, NVL(longdbcs, object_name) long_name, object_type, status
FROM dba_objects, sys.javasnm$
WHERE object_type LIKE '%JAVA%'
  AND status <> 'VALID'
  AND short (+) = object_name
ORDER BY owner, long_name, object_type;

Expected result on a healthy system:

no rows selected

If rows appear in SYS, a full JVM reinstallation is usually the correct remediation — attempting to recompile individual SYS Java classes manually tends to be a rabbit hole. For invalid objects in user schemas, targeted recompilation via DBMS_JAVA.compile_class is usually sufficient.

2.4 Java Pool Memory

Valid objects and a correct installation mean nothing if the Java Pool is exhausted or misconfigured. Class loading happens at runtime against this pool, and a too-small pool produces cryptic errors — ORA-29553, JVM initialization failures, or silent class-not-found behaviour — rather than an obvious memory error.

SELECT *
FROM v$sgastat
WHERE pool = 'java pool' OR name = 'free memory'
ORDER BY pool, name;

Example of a healthy result:

POOL	NAME	BYTES
java pool	JOXLE	15,821,568
java pool	free memory	16,906,304
java pool	joxs heap	826,560
large pool	free memory	8,585,216
shared pool	free memory	107,256,528

How to interpret the result:

Condition	Assessment
`java pool` rows absent entirely	Pool not configured — check `JAVA_POOL_SIZE` parameter
`free memory` > 5 MB	Acceptable for light JVM usage
`free memory` < 1 MB	High risk of `ORA-29553` and class-loading failures under load
Total java pool < 32 MB	Increase to 32–64 MB minimum for any active JVM workload

To inspect and resize the pool:

-- Check current configured size
SELECT name, value
FROM v$parameter
WHERE name = 'java_pool_size';

-- Resize online (only when SGA_TARGET is not managing memory automatically)
ALTER SYSTEM SET java_pool_size = 64M SCOPE=BOTH;

Oracle 19c / 21c note: With Automatic Memory Management (MEMORY_TARGET) or Automatic SGA Management (SGA_TARGET), java_pool_size will report 0 — this is expected, not a problem. The pool is sized dynamically by the memory manager. Verify actual runtime allocation through v$sgastat under representative load instead of relying on the parameter value.

2.5 Java Roles

The JVM installation creates a set of database roles that control access to Java execution privileges. If the core roles are missing, user-level Java code will fail with privilege errors even though SYS-level JVM is functional.

SELECT role
FROM dba_roles
WHERE role LIKE '%JAVA%'
ORDER BY role;

Expected output:

ROLE	Notes
JAVADEBUGPRIV	Required for Java debugging
JAVAIDPRIV	Identity privilege for Java
JAVASYSPRIV	System-level Java privilege
JAVAUSERPRIV	Standard user Java privilege
JAVA_ADMIN	Administrative Java privilege
JAVA_DEPLOY	Deprecated since Oracle Database 18c — absence on 18c+ is expected

If any of the five core roles (JAVAUSERPRIV, JAVASYSPRIV, JAVAIDPRIV, JAVADEBUGPRIV, JAVA_ADMIN) are missing, the JVM installation is incomplete and the role creation scripts from the JVM install set need to be re-run.

Oracle 19c / 21c — Multitenant note: Roles are PDB-local. Run this check connected to the target PDB. Querying from CDB$ROOT will show an incomplete or empty set regardless of the PDB state.

Summary

If you have worked through all eight checks and everything is green, the JVM is installed, valid, and has the resources to run. If you found issues, the most common remediation paths are:

JAVAVM / CATJAVA absent in DBA_REGISTRY — full JVM installation required via $ORACLE_HOME/javavm/install/initjvm.sql and related scripts.
Status INVALID in DBA_REGISTRY or DBMS_JAVA — re-run JVM installation scripts; consider a full reinstall if targeted recompilation does not resolve it.
Low Java Pool free memory — increase java_pool_size or allow the memory manager more headroom under SGA/AMM.
Missing roles — re-run the role creation portion of the JVM install scripts from $ORACLE_HOME/javavm/install/.

These eight queries take under two minutes to run and give a complete picture of JVM health. Worth adding to any DBA runbook as a pre-flight check before deploying anything that depends on Oracle JVM.