where we are upgrading oracle database to 19.27 from 19.18, we are encountering so many ora-600 errors, out of 1 this ora-600 error can able to fix it, via help from Oracle Support Guidance, where you can’t export of table, can’t access to that table, nor analyze or rebuilding indexes will fix your issue, there is not other option to update of metadata of that object in db level, this requires downtime. The Env, which we have faced is Oracle ExaCS CDB/PDB with 19.27 db version.

The Problem

Every attempt to access a specific table failed immediately.

SELECT COUNT(*)
FROM ADMIN.DEEDS;
ORA-00600: internal error code, arguments:
[kqrpre: maximum retries exceeded]

No SQL against this table was executable.

Initial Investigation

The trace file pointed to repeated failures inside Oracle’s row cache.

kqrpre: retry required
kqrCreateUsingSecondaryKey()
hash mismatch
>>> SYS_IL0000093934C00488$$
Looking up the object showed it was the internal LOB index for one of the table's SecureFile LOB columns.
SELECT owner,
       table_name,
       column_name
FROM dba_lobs
WHERE index_name='SYS_IL0000093934C00488$$';

However, every query still failed with ORA-00600. This suggested the problem was not segment corruption, but dictionary metadata inconsistency.

Finding the Real Cause

Looking inside Oracle’s dictionary revealed something unusual.

SELECT obj#,
       name,
       type#
FROM sys.obj$
WHERE name='SYS_IL0000093934C00488$$';
Two rows existed for the same internal object.
OBJ#      TYPE#
1239787      1
1240900      1

The trace file referenced both object IDs, indicating Oracle’s row cache was repeatedly finding conflicting metadata and eventually exhausting its retry mechanism.

Repairing the Dictionary Metadata

Warning: Direct updates to SYS.OBJ$ are unsupported and should only be performed under Oracle Support guidance or with a complete understanding of the risks. Always take a backup before modifying Oracle data dictionary tables.

First, open the affected PDB in restricted mode.

ALTER PLUGGABLE DATABASE P_DBA1 CLOSE IMMEDIATE INSTANCES=ALL;
ALTER PLUGGABLE DATABASE P_DBA1 OPEN RESTRICTED INSTANCES=ALL;

Create a backup of the dictionary table.

CREATE TABLE obj_backup_20260725
AS
SELECT *
FROM sys.obj$;
Verify the backup.
SELECT COUNT(*) FROM sys.obj$;
SELECT COUNT(*) FROM obj_backup_20260725;
75345
UPDATE sys.obj$
SET type# = 10
WHERE obj# = 1239787;
COMMIT;

Restart the PDB.

ALTER PLUGGABLE DATABASE P_SB1_QA1 CLOSE FORCE INSTANCES=ALL;
ALTER PLUGGABLE DATABASE P_SB1_QA1 OPEN RESTRICTED INSTANCES=ALL;

Finally reopen the PDB normally.

ALTER PLUGGABLE DATABASE P_SB1_QA1 CLOSE IMMEDIATE INSTANCES=ALL;
ALTER PLUGGABLE DATABASE P_SB1_QA1 OPEN INSTANCES=ALL;

The Result

After the duplicate metadata entry was removed, the table became accessible again.

SELECT COUNT(*)
FROM ADMIN.DEEDS;
810403

The ORA-00600 [kqrpre: maximum retries exceeded] error disappeared because Oracle could now resolve the row cache metadata without conflicting object definitions.

Why This Worked

Instead, Oracle’s dictionary contained duplicate metadata for the same internal LOB index object.

During row cache lookups, Oracle repeatedly encountered conflicting metadata, retried multiple times, and finally raised:

ORA-00600
[kqrpre: maximum retries exceeded]

Removing the stale dictionary entry restored metadata consistency.

Oracle Metalink notes tells this is bug which got fixed in 19.24 version, but don’t know why we got in after upgrading to 19.27 version. Bug 35778398 – [ROW CACHE] 19c Tracking Bug for Row Cache Bug Fixes on top of 34304965 (Doc ID 35778398.8)
Bug 35285891 – SageASM-e hit ora 600 [kqrpre: maximum retries exceeded] (Doc ID 35285891.8)

Fix it interesting so thought of sharing it everyone.