Dear Readers,

Good evening!

Trust you are doing well.

Today, I’m writing about an issue we observed in an Oracle Database running version 19.27 on an OCI ExaCS environment. This database was recently cloned from a source database running on ExaCC, both using the same DBRU patchset.

During the health check, we found intermittent occurrences of ORA-00600 [kcbzib_6]. The complete error is shown below:

2025-12-11T00:42:19.717270+05:30
Errors in file /u02/app/oracle/diag/rdbms/prod_oci/PRD1/trace/PRD1_ora_149145.trc (incident=275016):
ORA-00600: internal error code, arguments: [kcbzib_6], [0], [12], [], [], [], [], [], [], [], [], []
Incident details in: /u02/app/oracle/diag/rdbms/prod_oci/PRD1/incident/incdir_275016/PRD1_ora_149145_i275016.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2025-12-11T00:42:19.720360+05:30
Please look for redo dump in pinned buffers history in incident trace file, if not dumped for what so ever reason, use the following command to dump it at the earliest. ALTER SYSTEM DUMP REDO DBA MIN 302 6 DBA MAX 302 6 SCN MIN 1;

---

An internal routine has requested a dump of selected redo.
This usually happens following a specific internal error, when
analysis of the redo logs will help Oracle Support with the
diagnosis.
It is recommended that you retain all the redo logs generated (by
all the instances) during the past 12 hours, in case additional
redo dumps are required to help with the diagnosis.

---

During further investigation, we found that the query used for tablespace monitoring was failing with the mentioned error. We narrowed down the issue by running a simple COUNT(*) on all dictionary views involved to identify the actual culprit. The issue was traced to the DBA_FREE_SPACE view.

SQL> SELECT count(*) FROM dba_free_space;
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcbzib_6], [0], [12], [], [], [], [], [], [], [], [], []

We were basically unable to query DBA_FREE_SPACE. Further investigation allowed us to narrow down the issue to a specific tablespace, as shown below:

SQL> select count(*) from dba_free_space where tablespace_name='TBS_APPS1';
select count(*) from dba_free_space where tablespace_name='TBS_APPS1'
                     *
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcbzib_6], [0], [12], [], [], [],
[], [], [], [], [], []

SQL> select count(*) from dba_free_space where tablespace_name!='TBS_APPS1'; 

COUNT(*)
----------
      8956

So the issue was specifically related to checking free space in the TBS_APPS1 tablespace, while the rest of the tablespaces appeared clean.

The first basic check is to verify whether there is any Oracle dictionary corruption. You can refer to the following link:

Using DBMS_DICTIONARY_CHECK

The dictionary check returned a couple of warnings, but they appeared to be ignorable.

Next, we performed an RMAN VALIDATE to check for any potential corruption, but the results were clean as well.

During futher investigation I came across Oracle internal Bug 34432053 – ORA-600 [KCBZIB_6] ON 19C CLONED DATABASE which is closed as duplicate of Bug 32455516 – ORA-600 [KTSL_ALLOCATE_DISP:KCBZ_OBJDCHK] ORA-600 [KCBZIB_6] SECUREFILE DOUBLE ALLOCATION

Although the fix was included in the current patchset, the issue points to a double-allocation problem caused by a SecureFile LOB bug, which was later addressed under patches 31877391 / 31741039 / 29652040. These fixes prevent future double allocations, but for objects that are already corrupted, we may need to rebuild the tablespace bitmaps.

The existing bitmap corruption or double allocation is preventing queries on X$KTFBFE / DBA_FREE_SPACE, leading to failures. The corruption is specific to space metadata or space bitmap blocks, which track free and used space. While RMAN performs block checks and checksum validations, there is currently no mechanism for RMAN to validate space metadata.

Solution:

execute dbms_space_admin.tablespace_rebuild_bitmaps( <tablespace_name>);

===> For the scenario TS is already cloned.

We followed the same action plan to resolve the issue:

SQL> select count(*) from dba_free_space;
select count(*) from dba_free_space
*
ERROR at line 1:
ORA-00600: internal error code, arguments: [kcbzib_6], [0], [12], [], [], [], [], [], [], [], [], []

SQL> execute dbms_space_admin.tablespace_rebuild_bitmaps('TBS_APPS1');

PL/SQL procedure successfully completed.


SQL> select count(*) from dba_free_space;

 COUNT(*)
----------
    39532

Issue resolved 🙂

Hope you will find this post very useful!!

Let me know for any questions and any further information in comments or LinkedIn.