[英]Oracle 11g XE “alter table drop column” causes ORA-00600
On Oracle 11g XE I ran the following statement: 在Oracle 11g XE上,我运行了以下语句:
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 然后我运行了一些引用该视图的PL / SQL,我开始得到它
ORA-00600: internal error code, arguments: [kkdcsaccc2], [], [], [], [], [], [], [], [], [], [], []
(however if I changed the PL/SQL to reference the table directly then the code worked) (但是,如果我将PL / SQL更改为直接引用表,则代码可以正常工作)
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. 我已经删除并重新创建了视图,并且还成功运行了“alter table le_customer move ...”,但是错误继续以100%的一致性发生。
I have shut the database down and run dbv against the database .dbf files - no errors were reported. 我关闭了数据库并对数据库.dbf文件运行dbv - 没有报告错误。
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. 我在VM上运行,所以我回滚了代码并从视图中删除了profile_id列引用,而没有从le_customer表中物理删除列...然后一切都与我的代码一起正常工作。 Then I ran alter table le_customer drop column profile_id;
然后我运行了alter table le_customer drop column profile_id; again and immediately the ORA-00600 re-occurred.
再次立即重新发生ORA-00600。
I rolled the VM back again then ran 我再次将VM推回然后跑了
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. ...然后再次测试并立即获得
ORA-00600
。
So I am very sure that the problem is being caused by the "alter table le_customer drop column ;" 所以我非常肯定这个问题是由“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! 所以,如果有人看到这个或有关于测试/解决方法的任何想法,我将非常感谢你能分享的任何信息 - 谢谢!
My previous conclusion was incorrect ...as I have again seen the exact same problem, this time on 2 completely separate database builds. 我之前的结论是错误的...因为我再次看到了完全相同的问题,这次是在2个完全独立的数据库构建上。 The problem table however remained the same one as before (ie. le_customer) and:
然而问题表保持与以前相同(即le_customer)和:
...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" 对以下2列的一个相当无害的约束,其中明显的case_master_template是存储在“out out row”中的xmltype
...
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. 然后我删除了除此之外的表中的所有约束,索引和外键,并且查询继续可靠地显示ORA-00600。 On removing this constraint last, the ORA-00600 disappeared from both view and table query (regardless of where clause existence).
在最后删除此约束时,ORA-00600从视图和表查询中消失(无论where子句存在)。
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. 因此,虽然我没有内部工作的可见性,但我确实认为我已经确定了罪魁祸首,并且可以相当自信地向其他人提供建议,以便首先检查在ORA-00600“kkdcsaccc2”出现时可能存在的xmltype类型列的约束。 And I will be removing the constraint from the table.
我将从表中删除约束。
I hope this proves useful to someone. 我希望这证明对某人有用。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.