17,089
社区成员
发帖
与我相关
我的任务
分享oracle ORA-00600: 内部错误代码, 参数: [kdsgrp1], [], [], [], [], []
CREATE TABLE "ITEMS" (
"ID" VARCHAR2(36) NOT NULL,
"PARENT_ID" VARCHAR2(36) NULL,
"CATEGORY_ID" VARCHAR2(36) NOT NULL,
PRIMARY KEY ("ID")
);
ALTER TABLE "ITEMS" ADD CONSTRAINT "fk_ITEMS_ITEMS_1" FOREIGN KEY ("PARENT_ID") REFERENCES "ITEMS" ("ID") ON DELETE CASCADE;
上述是我的表结构；
当我创建bitmap的索引时：CREATE BITMAP INDEX "ITEMS_PARENT_ID" ON "ITEMS" ("PARENT_ID" );
在后续执行delete from items 做全表删除的时候，偶尔会出现ORA-00600: 内部错误代码, 参数: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []的问题，
在我改变索引类型，改成Btree后问题消失，删除此索引，问题也消失。
但是bitmap对我很有用因为parent_id这一列数据重复量超过95%，所以才采用了bitmap。
所以我想问题，为什么bitmap会导致ora-00600的问题，原因可能是出现在哪里，求大神帮解答，给个思路也行
"ID" VARCHAR2(36) NOT NULL,
"PARENT_ID" VARCHAR2(36) NULL,
"CATEGORY_ID" VARCHAR2(36) NOT NULL,
PRIMARY KEY ("ID")
);
ALTER TABLE "ITEMS" ADD CONSTRAINT "fk_ITEMS_ITEMS_1" FOREIGN KEY ("PARENT_ID") REFERENCES "ITEMS" ("ID") ON DELETE CASCADE;
上述是我的表结构；
当我创建bitmap的索引时：CREATE BITMAP INDEX "ITEMS_PARENT_ID" ON "ITEMS" ("PARENT_ID" );
在后续执行delete from items 做全表删除的时候，偶尔会出现ORA-00600: 内部错误代码, 参数: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []的问题，
在我改变索引类型，改成Btree后问题消失，删除此索引，问题也消失。
但是bitmap对我很有用因为parent_id这一列数据重复量超过95%，所以才采用了bitmap。
所以我想问题，为什么bitmap会导致ora-00600的问题，原因可能是出现在哪里，求大神帮解答，给个思路也行
...全文
请发表友善的回复…
发表回复
青涩的我 2017-11-10
- 打赏
- 举报
@2楼 多谢码友
minsic78 2017-11-09
- 打赏
- 举报
如果就这两列在所有查询里都会用到，那么可以创建这两列上的组合索引，并且可能需要多创建一条放在这个组合索引里的非前导字段的单字段索引。
不要组合索引，只要单字段上的B树索引也不是不可以，他们其实可以被转换为位图参与位图计算，但效率会差点，而且可能需要在SQL中添加提示来达到想要的执行计划。
另外，其实数据总量不是问题，别说千万，上亿或者更多也都没有关系，但是，想用索引得到较好性能的前提是：经过where条件过滤之后获取的数据量比较小，一旦条件过滤之后数据量比较大，或者更悲剧的是不好控制（可能是几条，也可能是几百万条），那么索引真的对付不过来了，无论是B树索引，还是位图索引。
青涩的我 2017-11-09
- 打赏
- 举报
@2楼 想说版本了， csdn不让回复了！！！
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production 这个版本应该是没问题。
然后这表个我没列出全部 实际还有一列 也是个外键 也是个bitmap。-- 没想到这也会有关？
CREATE TABLE "ITEMS" (
"ID" VARCHAR2(36) NOT NULL,
"PARENT_ID" VARCHAR2(36) NULL,
"CATEGORY_ID" VARCHAR2(36) NOT NULL,
PRIMARY KEY ("ID")
);
CREATE BITMAP INDEX "ITEMS_PARENT_ID" ON "ITEMS" ("PARENT_ID" );
CREATE BITMAP INDEX "ITEMS_CATEGORY_ID" ON "ITEMS" ("CATEGORY_ID" );
category_id也是个外键。这两列在查询都都会用到，而且重复率都很高的，有and的 也有各自的查询。
出现错误的时候我看了trace，里面只用到ITEMS_PARENT_ID这个索引。
而且目前bitmap性能也非常好，数据量基本控制在千万内吧。
分区看了很多 范围分区不适合，列表分区可能能用，但是存在一个问题，这PARENT_ID这列，总数据400万，做distinct后剩余5万，这范围分区也没法把5万个不同的值都列出来的，而且都是id，每次更新数据都会变动，所以范围分区也没法用，哈希分区的话parent_id也没意义，主键也没必要做哈希分区。分区是没法用了！！！！！
就bitmap最TMD合适，还是出这个问题！！！
要是没好的办法就只能用btree了。
minsic78 2017-11-09
- 打赏
- 举报
ORA 600 7445等几个错误，通常与BUG相关，有一部分有补丁，更多的有个workround就算不错了，看到这些错误你可能还是要绕着走，这世界没有什么不可妥协的东西 
minsic78 2017-11-09
- 打赏
- 举报
楼主你可以先看下你的数据库版本是不是符合BUG文档里描述的，如果不符合，也许不是这个BUG，当然也不排除Oracle自说自话，说是修复了，实际上还有漏的。
现在看来，文档的workround里说的index应该是B树索引，因为如果是你这种情况，bitmap索引所在的字段是唯一一个建有索引的字段的话，那这个workround永远不可能生效。
前面那么多，除了并发DML一定不适合建位图索引外，唯一非要用位图索引以带来更好性能的就是：有大量即席查询——这也意味着表上有很多字段上都需要创建位图索引，如果你在一个字段，尤其是个唯一值很少的字段上创建该表上唯一一条位图索引，这种设计根本就无济于事，这种时候你可能要考虑的是分区，而不是索引了。
青涩的我 2017-11-09
- 打赏
- 举报
@2楼
我觉得上面说的这么多关于bitmap，我实际情况应该都是符合的
青涩的我 2017-11-09
- 打赏
- 举报
谢谢2楼的回答
首先这个表并没有并发的DML操作，表中数据，对于insert操频率也非常少，只是一次业务通常会新增十几万的数据，后续不会修改，delete操作也是非常少的，查询会需要并发的，所以我才采用了bitmap，而且基本也没出现问题，只是很偶尔的在测试那里会出见一次，也没有什么重现的方法。
在测试那里发生问题，就随便新增几条数据，然后删除就报错了。换个session也是不行的，只能改索引，或者吧表删除重新在创建就又好了
另外看了上面一些解释，
首先是按照上面例子操作也没有发生00600的问题，因为在我的实际情况中发生问题的几率也非常小
然后下面的workaround.1的意思是在外键列上新增索引，这个索引时默认的Btree类型的吗？还是bitmap也可以。而且我实际的表就是在外键列创建的bitmap
上面的列子是在c2也就是普通列上创建的索引，00600和外键列也有关系吗？
看了上面的一些解释，是不是可以理解成bitmap就是可能会导致00600 而且也没有解决办法呢？
青涩的我 2017-11-09
- 打赏
- 举报
谢谢2楼的回答
首先这个表并没有并发的DML操作，表中数据，对于insert操频率也非常少，只是一次业务通常会新增十几万的数据，后续不会修改，delete操作也是非常少的，查询会需要并发的，所以我才采用了bitmap，而且基本也没出现问题，只是很偶尔的在测试那里会出见一次，也没有什么重现的方法。
在测试那里发生问题，就随便新增几条数据，然后删除就报错了。换个session也是不行的，只能改索引，或者吧表删除重新在创建就又好了
另外看了上面一些解释，
首先是按照上面例子操作也没有发生00600的问题，因为在我的实际情况中发生问题的几率也非常小
然后下面的workaround.1的意思是在外键列上新增索引，这个索引时默认的Btree类型的吗？还是bitmap也可以。而且我实际的表就是在外键列创建的bitmap
上面的列子是在c2也就是普通列上创建的索引，00600和外键列也有关系吗？
看了上面的一些解释，是不是可以理解成bitmap就是可能会导致00600 而且也没有解决办法呢？
minsic78 2017-11-09
- 打赏
- 举报
位图索引的有些东西，网上可能是以讹传讹了……
1、实际上位图索引最应该考虑的是：你在这张表上会不会有并发DML操作？如果有，那么位图索引就绝不应该是你的选择，通常也就只有一天甚至多天或者更长时间Load一次数据的仓库才满足这样的要求；
我们暂且假设第一个条件满足，再来看看其他的：
2、很多地方会说到，在唯一值比较少的的字段上适合创建位图索引，实际上倒是小看了位图索引，在大部分情况下，同样字段（组合）上的位图索引的性能比B树索引要好，因为它的体积更小，从而扫描同样数据所消耗的IO量更少；
3、位图索引一般都不会创建组合索引，而是单字段索引，它们非常适用于即席查询，就是那种where条件组合非常多变，and、or各种操作符很多的SQL，因为B树索引想要发挥优势，你可能需要在各种可能的条件组合上都创建索引；
4、另外还有些小细节：a、位图索引只能在分区表上只能创建成local分区索引，这在某些场景下可能会导致一些性能损失；b、位图索引不支持唯一索引，也意味着主键索引不能是位图索引；c、位图索引与B树索引不一样，它还保存null值，这有时候可以被利用来做一些优化，比如count大表；d、位图索引对星型转换的支持更好，更高效。
前面罗哩叭嗦说了那么说，想说的是，楼主的这个表上这个字段，不一定适合创建位图索引，请再仔细斟酌。
至于ORA-600 [kdsgrp1]，我在MOS上搜到了一个BUG，楼主可以一看：
