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

小心,有一个ORA-600的错误正在靠近。

对于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 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

四、后续

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

1、free比bitmap中0的个数少 这种情况表示文件内的某些数据块已经被分配,但free未正确更新,这种情况较为简单,直接修改free变量的值与bitmap相等即可。 2、free比bitmap中0的个数多 这种情况表示文件内的某些数据块“可能”已经被分配,或某些数据块被回收但bitmap本身未更新,这时我们无法确定具体是哪些数据块已经被分配,因此不能通过简单修改bitmap或free进行修复,如果强行修改free值可能会造成业务数据被覆盖。

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

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

作者介绍

谢浩 云和恩墨技术专家

具有多年oracle数据库企业级运维经验,擅长结合业务、硬件系统制定各种项目方案。曾服务的客户涉及金融保险、电信运营商、政府等行业。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-12-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏chenssy

【死磕Sharding-jdbc】---分布式ID

传统数据库软件开发中,主键自动生成技术是基本需求。而各大数据库对于该需求也提供了相应的支持,比如MySQL的自增键。 对于MySQL而言,分库分表之后,不同表生...

19320
来自专栏有趣的django

python面试

1. 先做自我介绍 2. 做Python几年了?为什么选择Python? 3. 学历?大学什么专业? 4. 除了Python以外对其他语言有没有了解? 5. 你...

43140
来自专栏Android群英传

实现 APK 保护时常见的坑和解决方案

11330
来自专栏芋道源码1024

数据库分库分表中间件 Sharding-JDBC 源码分析 —— 分布式主键

本文主要基于 Sharding-JDBC 1.5.0 正式版 1. 概述 2.KeyGenerator 2.1 DefaultKeyGenerator 2.2...

508140
来自专栏Wordpress专用主机|主题模板|必备插件

WORDPRESS视频教程:使用ELEMENTOR制作企业展示网站

第一次录wordpress视频教程,可能讲的很烂。希望各位朋友见谅,轻喷~博主会不断进步的。

67210
来自专栏大数据和云计算技术

Codegen技术学习

Codegen在spark中的应用 除了前面查询优化中讲到逻辑优化器之外,Spark在1.5版本中引入了比较大的一个动作就是DataFrame执行后端的优化,引...

68150
来自专栏FreeBuf

一个脑洞“颇大”的恶搞链接

事件起因 这其实是一件很偶然的事情,前几天在某大佬群里看大佬装逼。突然一个平日不怎么冒泡的群友发了一条链接。本着“这群里都是好人 ”的想法我就天真的点了进去.....

42090
来自专栏我是攻城师

Redis 3.0.0正式版发布,全新的分布式高可用数据库

38870
来自专栏Python数据科学

Python定期爬取GitHub上每日流行项目

介绍一个在GitHub上看到的通用的python爬虫,难度不大,是一个蛮好玩的点,顺便总结一下python爬虫的一些需要注意的点。

27820

使用Apache Flink进行流处理

如果在你的脑海里,“Apache Flink”和“流处理”没有很强的联系,那么你可能最近没有看新闻。Apache Flink已经席卷全球大数据领域。现在正是这样...

55320

扫码关注云+社区

领取腾讯云代金券