【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 邮箱：[email protected]
Leave a Reply