记一次数据库核心对象(CON$表I_CON2索引)损坏的修复过程

教程发布:风哥 教程分类:ITPUX技术网 更新日期:2022-02-12 浏览学习:46

上一篇帖子已经说明了问题是如何产生的,这一篇主要是把整个解决过程详细记录下来(忽略失败的步骤),以供有同样问题的同学可以借鉴下。
一:分析问题:
最初呈现给我们的错误是这样的,如下图:

[img=440,0]http://itpubpic.img168.net/forum/201402/14/1319226txpi6xpj6ptxppn.jpg[/img]
2014-2-14 13:19 上传
http://www.itpub.net/forum.php?mod=attachment&aid=OTA2NDU1fDc2Yzc3YjQwfDEzOTI0Mzc3NTB8Mjg4OTY1MjF8MTg0NTA4Nw%3D%3D¬humb=yes]下载附件 (13.81 KB)

拿这个ORA-08102去网上搜索,很快就知道了 这是一个索引建和表中的值 不符而导致的问题。
查看这个对象号为52的对象,发现是 SYS.CON$ 表中 I_CON2索引 ,这是 一个 BOOTSTRP$ 对象,而且 OBJ# 为51 ,所以这是一个 核心BOOTSTRP$ 对象,
是不能通过startup migrate 和 event 38003 重建的,所以最终只能通过BBED去修改这个块中有问题的地方。

先通过下面这个SQL,查找表和索引之间到底相差什么
sql>SELECT /*+ FULL(t1) */
owner#, NAME, con#
FROM CON$ t1
MINUS
SELECT /*+ index(t I_CON2) */
owner#, NAME, con#
FROM CON$ t;

OWNER# NAME CON#
0 _NEXT_CONSTRAINT 60009
第一次看到这个SQL时,真心佩服想到这个SQL的人,能利用这样的方法来查询表和索引之间的不一致 ,
通过查询结果 确实可以看到 表和索引存在不一样的,就是CON$表中有 CON#=60009的这一列,而索引的键值中却没有(要知道索引的键值就是保存该索引对应的字段值啊)

我们再去看看alter日志:
因为这个报错会有日志信息显示在alter日志中,所以现在去查看alter日志:
Errors in file /http://www.itpub.net/tree/index_1/]oracle/diag/rdbms/hollycrm/hollycrm/trace/hollycrm_ora_3795.trc:
Fri Feb 14 12:09:24 2014
Trace dumping is performing id=[cdmp_20140214120924]

在去查看这个trace文件,立刻能看到这个错误地方:
oer 8102.2 - obj# 52, rdba: 0x00419ff1(afn 1, blk# 106481)
kdk key 8102.2:
ncol: 1, len: 5
key: (5): 04 c3 07 01 0a
mask: (2048):

该错误也明确,错误对象为52 , 在文件1 ,块106481 中,然后看 key的值,
第一个16进制数 04不知道代表什么意思,后面 4个字节c3 07 01 0a 正好是60009在数据库中存储的16进制表示,
sql>SELECT DUMP(60009,'1016') FROM dual;

Typ=2 Len=4: c3,7,1,a

通过上诉的 分析 ,现在我们基本可以确定,问题是这样的:
在文件1 块106481中有一个索引条目,它应该指向CON$表中 CON#=60009 这一条记录,
这个索引条目 的索引键 应该是 60009 (对应16进制为c3 07 01 0a) ,它的ROWID应该就是CON$表上 CON#=60009 这一条记录的实际ROWID;
但是现在 这个索引条目的索引键不是60009,所以才导致了我们的问题。

二:定位问题
知道了问题所在,那现在就是定位具体错误位置的时候了,根据上面的分析,
我们首先要得到CON$表中 CON#=60009 这一行的实际ROWID:
SELECT rawtohex(r.rowid) rh,
dbms_rowid.rowid_relative_fno(ROWID) fno,
dbms_rowid.rowid_block_number(ROWID) bno,
dbms_rowid.rowid_row_number(ROWID) rno
FROM con$ r
WHERE NAME = '_NEXT_CONSTRAINT' --AND con#=60009;

rh fno bno rno
0000001C00400121000C 1 289 12
我把后面con#='60009'注释掉了,这是因为用CON#=60009直接查不出来,原因应该就是这个查询使用了I_CON2索引,而索引中没有个这个键值的条目,
ROWID的格式为:[font=Consolas,]对象号(6个字符) 文件号(3个字符) 块号(6个字符) 行号(3个字符) ,
[font=Consolas,]通过rawtohex函数可以转换为16进制,现在得到了 这条记录的 文件号,块号,行号的16进制为:00 40 01 21 00 0C,因为索引条目上保存的ROWID也是文件号,块号,行号!

现在我们得到了这个记录的实际ROWID,下一步就是去索引块里去查找了ROWID了。
我们将这个索引块dump出来:
sql>alter system dump datafile 1 block 106481;
system alter
sql>oradebug setmypid
Statement processed.
sql>oradebug tracefile_name
/oracle/diag/rdbms/hollycrm/hollycrm/trace/hollycrm_ora_13537.trc
下面我们来查看这个dump文件:
直接看叶块部分:
Leaf block dump
===============
header address 8361612=0x7f968c
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 1
kdxcosdc 1
kdxconro 375
kdxcofbo 786=0x312
kdxcofeo 2112=0x840
kdxcoavs 2327
kdxlespl 0
kdxlende 4
kdxlenxt 0=0x0
kdxleprv 4300784=0x419ff0
kdxledsz 6
kdxlebksz 7984
row#0[7971] flag: ------, lock: 0, len=13, dataundefined6): 00 42 71 f4 00 01
col 0; len 4; (4): c3 06 59 5f
row#1[7958] flag: ------, lock: 0, len=13, dataundefined6): 00 42 71 f4 00 02
col 0; len 4; (4): c3 06 59 60
row#2[7945] flag: ------, lock: 0, len=13, dataundefined6): 00 42 71 f4 00 03
col 0; len 4; (4): c3 06 59 61
row#3[7932] flag: ------, lock: 0, len=13, dataundefined6): 00 42 71 f4 00 04
col 0; len 4; (4): c3 06 59 62
row#4[7919] flag: ------, lock: 0, len=13, dataundefined6): 00 42 71 f4 00 05
col 0; len 4; (4): c3 06 59 63
row#5[7906] flag: ------, lock: 0, len=13, dataundefined6): 00 42 71 f4 00 06
col 0; len 4; (4): c3 06 59 64
row#6[7894] flag: ------, lock: 0, len=12, dataundefined6): 00 42 71 f4 00 07
col 0; len 3; (3): c3 06 5a

。。。。。。
row#372[2138] flag: ---D--, lock: 2, len=13, dataundefined6): 00 42 71 f2 00 1c
col 0; len 4; (4): c3 06 64 40
row#373[2112] flag: ---D--, lock: 2, len=13, dataundefined6): 00 42 71 f2 00 1d
col 0; len 4; (4): c3 06 64 41
row#374[2125] flag: ------, lock: 0, len=13, dataundefined6): 00 40 01 21 00 0c
col 0; len 4; (4): c3 06 64 42
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 106481 maxblk 10648

这个索引块中一共有375行,我们随便看其中一行
row#374[2125] flag: ------, lock: 0, len=13, dataundefined6): 00 40 01 21 00 0c
col 0; len 4; (4): c3 06 64 42

这里有两个地方比较重要,一个是 dataundefined6): 00 40 01 21 00 0c ,另一个是col 0; len 4; (4): c3 06 64 42
可能在不同的版本中,这里格式不一样,我这里是11gR2的,
dataundefined6): 00 40 01 21 00 0c 这里代表的是ROWID的信息,
col 0; len 4; (4): c3 06 64 42 这里代表的是索引键的值
通过查询,很快就找到了这一行:
row#374[2125] flag: ------, lock: 0, len=13, dataundefined6): 00 40 01 21 00 0c
col 0; len 4; (4): c3 06 64 42

而我们看到这个索引条目上的索引键为 c3 06 64 42 确实不是 我们表上的 c3 07 01 0a,
索引条目算是找到了,现在就要把这个索引条目在这个块上的偏移量找到就OK了,
偏移量offset的计算方式,网上有个帖子是这么说的:
[color=#3f4549]偏移量=N+44+24*itl N是行数据的补偿 44是 kcbh(cache层)长度+ktbbh(事务层)长度 24是一个itl的长度 总共加起来其实就是行数据的offset
不过帖子里也没说是为什么,见http://www.killdb.com/2011/07/30/bootstrap核心对象数据不一致导致ora-08102.html]http://www.killdb.com/2011/07/30/bootstrap核心对象数据不一致导致ora-08102.html
我也按照这个方法计算了,得到 2125+44+24*3=2268
现在地方也找到了,只需要把这里的c3 06 64 42改为c3 07 01 0a 就OK了。

三:解决问题
最后我们通过BBED来修改这个块,
BBED> set dba 1,106481 offset 2268
DBA 0x00419ff1 (4300785 1,106481)
OFFSET 2268

BBED> d /v
File: /oracle/oradata/hollycrm/system01.dbf (1)
Block: 106481 Offsets: 2268 to 2779 Dba:0x00419ff1
-------------------------------------------------------
40012100 0c04c306 64420100 004271f2 l @.!...?.....Bq?
001c04c3 06644001 00004001 21000c04 l ...?d@...@.!...
c3066441 01000042 71f2000d 04c30664 l ?dA...Bq?..?d
3f010000 40012100 0c04c306 64400100 l ?...@.!...?d@..
004271f2 002004c3 06643e01 00004001 l .Bq? .?d>...@.
21000c04 c306643f 01000042 71f2001e l !...?d?...Bq?.
04c30664 3d010000 40012100 0c04c306 l .?d=...@.!...?

......................................
21000c04 c306642f 01000042 71f20020 l !...?d/...Bq?

<16 bytes per line>

可以看到,这里就是我们要找的地方了,然后我们就是要修改红色部分,
BBED>modify /x c307 offset 2274
输出略
BBED>modify /x 0101 offset 2276
输出略
我们再看一下这个地方:
BBED> d /v
File: /oracle/oradata/hollycrm/system01.dbf (1)
Block: 106481 Offsets: 2268 to 2779 Dba:0x00419ff1
-------------------------------------------------------
40012100 0c04c307 010a0100 004271f2 l @.!...?.....Bq?
001c04c3 06644001 00004001 21000c04 l ...?d@...@.!...
c3066441 01000042 71f2000d 04c30664 l ?dA...Bq?..?d
3f010000 40012100 0c04c306 64400100 l ?...@.!...?d@..
004271f2 002004c3 06643e01 00004001 l .Bq? .?d>...@.
21000c04 c306643f 01000042 71f2001e l !...?d?...Bq?.
04c30664 3d010000 40012100 0c04c306 l .?d=...@.!...?

......................................
21000c04 c306642f 01000042 71f20020 l !...?d/...Bq?

<16 bytes per line>

BBED> sum
BBED> sum apply
最后刷新下数据库的缓冲区
SQL>alter system flush buffer_cache;
再次创建索引,约束时,不再报错了。

以下是老白大神(百鳝)的一篇有用的帖子
http://www.docin.com/p-277739036.html]http://www.docin.com/p-277739036.html

(注:此贴是我在ITPUB上发表的,由于注册此网站需要发一篇帖子才能成为正式会员,所以先拿过来了。)

本文标签:
网站声明:本文由风哥整理发布,转载请保留此段声明,本站所有内容将不对其使用后果做任何承诺,请读者谨慎使用!
【上一篇】
【下一篇】