数据恢复 - ORA-600 18018错误的重现和修复

对于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如下:

数据恢复 - ORA-600 18018错误的重现和修复

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

2、填充数据并再次观察

数据恢复 - ORA-600 18018错误的重现和修复

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

再次填充数据并观察

数据恢复 - ORA-600 18018错误的重现和修复

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

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

3、模拟破坏并修复

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

数据恢复 - ORA-600 18018错误的重现和修复

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

数据恢复 - ORA-600 18018错误的重现和修复

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

数据恢复 - ORA-600 18018错误的重现和修复

将其修改为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重新生成该块的校验位,否则后续操作会直接报坏块错误:

数据恢复 - ORA-600 18018错误的重现和修复

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

数据恢复 - ORA-600 18018错误的重现和修复

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

数据恢复 - ORA-600 18018错误的重现和修复

修改为正确的值:

数据恢复 - ORA-600 18018错误的重现和修复

dd回文件:

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

使用bbed生成checksum:

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

再次测试建表操作:

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

四、后续数据恢复 - ORA-600 18018错误的重现和修复

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

1、free比bitmap中0的个数少

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

2、free比bitmap中0的个数多

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

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

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


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

本文作者:谢浩

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

上一篇:C#编程:winForm中MenuStrip中的添加子菜单事件


下一篇:C#编程:如何理解委托