ORA-00600 [17287] During UTLRP in Oracle 19c EBS PDB After 19.31 Patch — Issue and Resolution

Overview

Recently, while working on an Oracle E-Business Suite database running on Oracle Database 19c with CDB/PDB architecture, we faced an unusual issue during post-patching activity.

The database was already upgraded/patched to:

19.31.0.0.0

After running utlrp.sql, the recompilation process completed, but near the end of the script it failed with an internal Oracle error:

BEGIN dbms_registry_sys.validate_components; END;
/

The error reported was:

ORA-00600: internal error code, arguments: [17287], 
[0x7FEBC46AA008], [0x07FAAAFF8], [], [SYS], [INITJVMAUX], [11], [1], [], [], [], []

The issue was later resolved by running datapatch specifically for the EBS PDB.

 

Environment

The environment was:

Application      : Oracle E-Business Suite R12.2
Database         : Oracle Database 19c
Database Version : 19.31.0.0.0
Architecture     : CDB/PDB
PDB Name         : EBSTST

 

 

Issue Description

After running:

@$ORACLE_HOME/rdbms/admin/utlrp.sql

the script reported invalid objects and then failed during the final validation stage.

The output showed:

OBJECTS WITH ERRORS
-------------------
33

ERRORS DURING RECOMPILATION
---------------------------
0

This was important because it confirmed that the recompilation itself was not throwing runtime exceptions.

However, at the end of utlrp.sql, the following statement failed:

BEGIN dbms_registry_sys.validate_components; END;
/

with:

ORA-00600: internal error code, arguments: [17287], ..., [SYS], [INITJVMAUX], ...

The INITJVMAUX reference initially suggested a possible Oracle JVM-related issue.

 

 

Initial Investigation

We first checked the Oracle JVM and related database components:

select comp_id, comp_name, status
from dba_registry
where comp_id in ('JAVAVM','CATJAVA','XML','XDB');

The result showed:

JAVAVM   JServer JAVA Virtual Machine      VALID
CATJAVA  Oracle Database Java Packages     VALID
XML      Oracle XDK                        VALID
XDB      Oracle XML Database               VALID

So, the Java-related registry components were valid.

We also checked for invalid Java objects:

select owner, object_name, object_type, status
from dba_objects
where object_name like '%JAVA%'
and status='INVALID';

No invalid Java objects were found.

This confirmed that the issue was not due to a broken JVM installation.

---

Invalid Objects Found

The remaining invalid objects were mostly related to application-level dependencies.

Most of them were under:

APPS
OPER

The APPS invalid objects were mainly due to missing or unresolved database links, such as:

LNK_DBSLIVE.US.ORACLE.COM
LNK_DSSFLOW.US.ORACLE.COM

Typical errors included:

ORA-12154: TNS:could not resolve the connect identifier specified
ORA-02019: connection description for remote database not found
ORA-04052: error occurred when looking up remote object
PLS-00352: Unable to access another database

Some OPER schema objects were invalid because UTL_MAIL was not accessible:

PLS-00201: identifier 'UTL_MAIL.SEND' must be declared
PLS-00201: identifier 'SYS.UTL_MAIL' must be declared

These invalid objects were application or dependency-related and were not the direct cause of the ORA-00600.

 

Important Observation

When we manually executed:

BEGIN dbms_registry_sys.validate_components; END;
/

it completed successfully.

However, when utlrp.sql was executed again, the same ORA-00600 appeared.

This suggested that the issue was not a permanently broken DBMS_REGISTRY_SYS.VALIDATE_COMPONENTS package. Instead, it appeared during the full utlrp.sql flow, most likely due to an internal SQL patch or registry mismatch inside the PDB.

 

Root Cause

The actual issue was that the Oracle Home was already patched to 19.31, but the SQL patching was not fully applied inside the EBS PDB.

In Oracle 19c multitenant architecture, patching has two major parts:

1. Binary patching using OPatch

This updates the Oracle software binaries in the Oracle Home.

Example:

opatch apply

2. SQL patching using datapatch

This applies the required SQL changes inside the database dictionary and registry.

Example:

cd $ORACLE_HOME/OPatch
./datapatch -verbose

In a CDB/PDB environment, the required PDB must be open when datapatch is executed. Otherwise, the SQL patch may not be applied inside that PDB.

In our case, the PDB EBSTST had pending or incomplete SQL patching. This created a mismatch:

Oracle Home binaries : 19.31
PDB SQL registry     : not fully patched to 19.31

This mismatch caused utlrp.sql to fail during its final component validation stage with:

ORA-00600 [17287] in SYS.INITJVMAUX

---

Resolution

The issue was resolved by running datapatch specifically for the affected PDB:

cd $ORACLE_HOME/OPatch

./datapatch -verbose -pdbs EBSTST

After this completed successfully, utlrp.sql was executed again and the ORA-00600 issue was resolved.

---

Validation After Fix

After running datapatch, we validated the SQL patch registry:

set lines 200
col description format a70
col status format a15
col action format a15

select con_id,
       patch_id,
       patch_uid,
       action,
       status,
       description,
       action_time
from cdb_registry_sqlpatch
order by action_time;

The patch entries showed successful application.

We also checked the component registry:

select con_id,
       comp_id,
       comp_name,
       version,
       status
from cdb_registry
order by con_id, comp_id;

The important components were valid:

JAVAVM   VALID
CATJAVA  VALID
XML      VALID
XDB      VALID

Then utlrp.sql was executed again:

@$ORACLE_HOME/rdbms/admin/utlrp.sql

This time the issue did not occur.

---

Useful Commands for Troubleshooting

Check database version

select version_full
from product_component_version
where product like 'Oracle Database%';

Check registry components

select comp_id, comp_name, version, status
from dba_registry
order by comp_id;

Check SQL patch status

select patch_id,
       action,
       status,
       description,
       action_time
from dba_registry_sqlpatch
order by action_time;

Check CDB-wide SQL patch status

select con_id,
       patch_id,
       action,
       status,
       description,
       action_time
from cdb_registry_sqlpatch
order by con_id, action_time;

Check invalid objects

select owner,
       object_type,
       count(*)
from dba_objects
where status='INVALID'
group by owner, object_type
order by owner, object_type;

Check detailed invalid object errors

select owner,
       name,
       type,
       line,
       position,
       text
from dba_errors
order by owner, name, sequence;

---

Key Lesson Learned

In Oracle 19c CDB/PDB environments, especially with Oracle E-Business Suite databases, always ensure that datapatch is successfully executed for the required PDB after applying an RU or one-off patch.

It is not enough to only patch the Oracle Home binaries using OPatch.

The complete patching flow should include:

opatch apply

followed by:

cd $ORACLE_HOME/OPatch
./datapatch -verbose

or, if required for a specific PDB:

cd $ORACLE_HOME/OPatch
./datapatch -verbose -pdbs <PDB_NAME>

Also ensure that the required PDB is open before running datapatch.

---

Final Root Cause Statement

The utlrp.sql script was failing with:

ORA-00600 [17287] in SYS.INITJVMAUX

because the EBS PDB had pending or incomplete SQL patch application after the Oracle Home was patched to 19.31.

Running:

./datapatch -verbose -pdbs EBSTST

applied the missing SQL patch actions inside the PDB, synchronized the PDB dictionary with the patched Oracle Home, and resolved the ORA-00600 error during utlrp.sql.

---

Recommendation

After every Oracle Database RU or one-off patch in a multitenant environment, always verify:

select con_id,
       patch_id,
       action,
       status,
       description,
       action_time
from cdb_registry_sqlpatch
order by action_time;

and make sure all required PDBs show successful SQL patch application.

This simple check can prevent unnecessary troubleshooting of invalid objects, JVM components, and ORA-00600 errors during post-patching activities.