【Oracle数据恢复】ORA-00704 bootstrap process failure错误解析

【Oracle恢复】ORA-00704 bootstrap process failure错误解析，本质上这个发生在open database 过程中的错误 其主要原因是在处理自举 bootstrap信息时发现了数据存在的问题，有多重情况均可能导致该错误发生。

 

 

 

当数据库被强制FORCE REESTLOGS 打开时可能遇到如下的错误信息：

 

 

ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 11 with name "_SYSSMU11$" too small
Tue Jan 17 04:46:17 2012
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 5496
ORA-1092 signalled during: ALTER DATABASE OPEN RESETLOGS...

[oracle@mlab2 ~]$ oerr ora 704
00704, 00000, "bootstrap process failure"
// *Cause:  Failure in processing bootstrap data - see accompanying error.
// *Action: Contact your customer support representative.

 

 

如果对于ORA-1555没有TRACE产生的话，可以以如下方法生成TRACE:

startup mount;

alter system set events '1555 trace name errorstack level 3';

alter database open resetlogs;

 

 

到user dump目录下找到对应的TRACE文件和ALERT.LOG， 假设alert.log中出现了这样的信息：

ORA-01555: snapshot too old: rollback segment number 11 with name “_SYSSMU11$” too small

则说明此场景中引起 ORA-1555的 USN undo segment number是11， 11的16进制是 b

 

之后我们阅读之前生成的TRACE，主要的工作是 寻找 表或索引的数据块的 DUMP并发现其中ITL 带有undo segment number 为11的记录，如下面的例子：

 

BH (0xacff8e48) file#: 1 rdba: 0x0040003e (1/62) class: 1 ba: 0xacf66000
set: 3 blksize: 8192 bsi: 0 set-flg: 2 pwbcnt: 0
dbwrid: 0 obj: 18 objn: 18 tsn: 0 afn: 1
hash: [d0e04c98,d0e04c98] lru: [acff8fd8,acff8db8]
ckptq: [NULL] fileq: [NULL] objq: [cc9a3d00,cc9a3d00]
use: [ce699910,ce699910] wait: [NULL]
st: CR md: EXCL tch: 0
cr: [scn: 0x0.4124e1e],[xid: 0x6.0.c28d],[uba: 0x820075.ea1.23],[cls: 0x0.46b5261],[sfl: 0x1]
flags:
Using State Objects
----------------------------------------
SO: 0xce6998d0, type: 24, owner: 0xd04439e8, flag: INIT/-/-/0x00
(buffer) (CR) PR: 0xd02fa378 FLG: 0x500000
class bit: (nil)
kcbbfbp: [BH: 0xacff8e48, LINK: 0xce699910]
where: kdswh02: kdsgrp, why: 0
buffer tsn: 0 rdba: 0x0040003e (1/62)
scn: 0x0000.046b527a seq: 0x00 flg: 0x00 tail: 0x527a0600
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00000000ACF66000 to 0x00000000ACF68000
0ACF67FF0 FFFF02C1 01FF8001 02C10280 527A0600 [..............zR]
...
Block header dump: 0x0040003e
Object id on Block? Y
seg/obj: 0x12 csc: 0x00.46b519e itc: 1 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01
Itl Xid Uba Flag Lck Scn/Fsc
0x01 0x000b.00b.00000e7a 0x00802042.00db.1a C--- 0 scn 0x0000.04624228

 

这里可以看到第一条 ITL 0x01 ， 其中<undo no>.<slot>.<wrap>  对应为 0x000b.00b.00000e7a ，则USN 为 0x000b 即 十进制的11

而这个数据块属于0x0040003e –(1/62)， 其FILE_ID=1 BLOCK_ID=62的数据块

这个块 实际是实例中已经读到buffer cache中的buffer ，找到buffer header BH中的SCN 信息 即为0x0000.046b527a

之后可以通过_mimimum_giga_scn 等方法调整SCN，或者通过修改ITL来绕过上述问题成功打开数据库。

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com