Oracle 11g XE "alter table drop column" causes ORA-00600

Question

On Oracle 11g XE I ran the following statement:

alter table le_customer drop column profile_id;

and then removed the equivalent column reference from a simple view on the table and recompiled the view successfully.

I then ran some PL/SQL that referenced the view and I started getting getting

ORA-00600: internal error code, arguments: [kkdcsaccc2], [], [], [], [], [], [], [], [], [], [], [] 

(however if I changed the PL/SQL to reference the table directly then the code worked)

I have dropped and recreated the view and also run "alter table le_customer move ..." successfully, however the error continues to occur with 100% consistency.

I have shut the database down and run dbv against the database .dbf files - no errors were reported.

I am running on a VM so I rolled the code back and removed the profile_id column reference from the view without physically removing the column from the le_customer table ...and everything then worked fine with my code. Then I ran alter table le_customer drop column profile_id; again and immediately the ORA-00600 re-occurred.

I rolled the VM back again then ran

alter table le_customer rename column profile_id to donald_duck;

.......then tested and everything worked fine.

I then ran

alter table le_customer drop column donald_duck;

...then tested again and got the ORA-00600 immediately.

So I am very sure that the problem is being caused by the "alter table le_customer drop column ;" statement and i am lost as to how to resolve it.

So, if anyone has seen this or has any ideas regarding a test / workaround I would greatly appreciate any info you are able to share - thanks!

Answer 1

My previous conclusion was incorrect ...as I have again seen the exact same problem, this time on 2 completely separate database builds. The problem table however remained the same one as before (ie. le_customer) and:

1. the schemas were identical on both databases
2. the identical query behaviour was consistent on both database
3. the query behaviour was consistent regardless of whether the simple view or base table was queried
4. The query consistently succeeded when no where clause was present
5. the query consistently failed as soon as as a simple where clause was added ie. "where id = 123"
6. failure occurred regardless of the where clause content ie. "where code = 'ABC'" also failed
7. the "where clause" continued to cause query failure even after all indexes were dropped from the table

...I began dropping constraints one by one from the table, rerunning the query each time

And on removing the following constraint, the query started working!

constraint le_cus_bus_case_chk check(allow_case_boo = 'F'
                                     or
                                     case_master_template is not null
                                    )

A fairly innocuous constraint on the following 2 columns, where noticeably case_master_template is an xmltype stored "out of row"

 ...
 allow_case_boo varchar2(1) 
 case_master_template        xmltype
 ...
)
xmltype column case_master_template store as clob (disable storage in row)

To confirm this constraint to be the problem, on the other database deployment where the same behaviour was manifesting - and all indexes and constraints still existed on the table - , I dropped the above constraint only. Immediately the problem disappeared and the query started working reliably.

I then removed all constraints, indexes, foreign keys from the table other than this one, and the query continued to manifest the ORA-00600 reliably. On removing this constraint last, the ORA-00600 disappeared from both view and table query (regardless of where clause existence).

So while i have no visibility of the internal workings, I do believe that I have identified the culprit, and can fairly confidently provide the recommendation to others to first check constraints on xmltype type columns that may exist should ORA-00600 "kkdcsaccc2" appear. And I will be removing the constraint from the table.

I hope this proves useful to someone.