简体   繁体   English

Oracle 11g XE“alter table drop column”导致ORA-00600

[英]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)和:

  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 当没有where子句时,查询一直成功
  5. the query consistently failed as soon as as a simple where clause was added ie. 一旦添加了简单的where子句,查询就会一直失败,即。 "where id = 123" “其中id = 123”
  6. failure occurred regardless of the where clause content ie. 无论where子句内容如何,​​都会发生故障。 "where code = 'ABC'" also failed “其中code ='ABC'”也失败了
  7. the "where clause" continued to cause query failure even after all indexes were dropped from the table 即使从表中删除了所有索引,“where子句”仍继续导致查询失败

...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.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM