对于Oracle的管理员来说，600是一个熟悉而陌生的数字，熟悉的是很多的用户都会遇到几次，陌生的是绝大数情况下都束手无策。这类错误一般oracle程序异常的内部错误，它表明一个进程遇到了一个低级的、意外的情况。今天我们通过实例剖析，当遇到一个ORA-600的错误，除了重启重装的二重唱法，我们还能做些什么？

一、案例描述

某客户的数据库在一个用户表空间上create table、insert 等操作报ORA-00600: internal error code, arguments: [kdBlkCheckError], [X], [X],[18018]错误，导致对该表空间上任何需要分配存储空间的操作全部失败。

二、相关知识点

ORA-00600 18018错误表示数据文件头部记录文件内空间使用的BitMap Control数据结构出现损坏。BitMap Control数据结构中记录了文件内所有空闲空间（已用空间）的信息。其位于每个数据文件中第三个block开始的连续几个block内，每个block内包含63488个二进制比特位。

BitMap Control中的信息分两种情况：

1、在表空间指定uniform size为固定值的情况下，1个二进制位表示一个extent

2、在未指定uniform size，即autoallocate（默认值）情况下，一个二进制位表示64K的空间（与db block size无关）

ORA-00600: internal error code, arguments: [kdBlkCheckError], [X], [X],[18018]错误一般指记录的free的bitmap位的个数与bitmap中实际为“0”的二进制位的个数不符。

三、错误重现

1、建立一个新表空间添加一个数据文件并dump第三个块

SQL> alter system dump datafile 8 block3;

截取dump如下：

其中的Free: 63488 表示该块中共有63488 个为0二进制位，这里需要注意的是dump文件中全部以16进制表示，因此下面的很多0实际每一位表示4位二进制数字

2、填充数据并再次观察

Free变为63474，bitmap中相应变为FF3F000000000000，将其转化为2进制等于：1111111100111111，其中有11个1，由于这里建立的表空间使用了默认的autoallocate并未指定uniform size，因此表示共有11个64K的空间被分配 

再次填充数据并观察

Free: 63446Bitmap变为FFFFFFFFFF03转换为二进制：111111111111111111111111111111111111111100000011共42个1。 

可以总结为dump文件中bitmap转换为二进制后1的个数加free中的数值等于63488，也就是建立空数据文件后该块中bitmap的总位数。

3、模拟破坏并修复

BitMap Control block的type为30，bbed中并未收录该类型数据块的结构体定义信息，因此使用bbed进行观察会报错：

dd出该块并使用ue进行修改：

使用ue（或其他任何支持进制转换的文本编辑器）搜索“FF FF FF FF FF 03”。其中加粗的 D6 F7 经过小头转换并转换为十进制后等于63446， FF FF FF FF FF 03对应bitmap开头的部分。

将其修改为FF FF FF FF FFF3，对应free的D6 F7不动。将破坏后的块dd回文件中：

dd if=/home/oracle/02.log  of=/home/oracle/oradata/ora1/bt01.dbf seek=2 bs=8192

由于我们修改了块内的数据，因此该块的校验位与块内数据已经不匹配，需要使用bbed重新生成该块的校验位，否则后续操作会直接报坏块错误：

此时所有需要在该文件上分配空间的操作将全部报错：

至此，错误重现完成。修复过程实际上就是前述破坏操作的逆过程：

修改为正确的值：

dd回文件：

dd if=/home/oracle/02.logof=/home/oracle/oradata/ora1/bt01.dbf seek=2 bs=8192

使用bbed生成checksum：

BBED> sum applyCheck value for File 5, Block 3:   current = 0xbe8e, required = 0xbe8e

再次测试建表操作：

SQL> create table bt4  tablespace bt as select * from dba_tables a;Table created

四、后续

在实际生产环境的故障中bitmap control的损坏往往比上述测试复杂很多，涉及到以下几种情况：

1、free比bitmap中0的个数少

这种情况表示文件内的某些数据块已经被分配，但free未正确更新，这种情况较为简单，直接修改free变量的值与bitmap相等即可。

2、free比bitmap中0的个数多

这种情况表示文件内的某些数据块“可能”已经被分配，或某些数据块被回收但bitmap本身未更新，这时我们无法确定具体是哪些数据块已经被分配，因此不能通过简单修改bitmap或free进行修复，如果强行修改free值可能会造成业务数据被覆盖。

在上述案例中，经过我方内部沟通，最终建议客户将该表空间中涉及该文件的对象全部移出并drop该文件。

面对日常的oracle数据库故障恢复，我们修复目的是让客户能够尽快的恢复正常生产，因此在客户数据库能打开并正常访问业务数据的情况下，尽量不考虑使用bbed、隐含参数等特殊恢复手段。

原文发布时间为：2017-12-5

本文作者：谢浩

本文来自云栖社区合作伙伴“”，了解相关信息可以关注“”微信公众号