解决ORACLE强制开库遇到ORA-00704 ORA-00604 ORA-01555错误 ORA-00704: 引导程序进程失败 ORA-00604: 递归 SQL 级别 出现错误 ORA-01555: 快照过旧: 回退段号 (名称为 "") 过小

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

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

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

ORA-00704: 引导程序进程失败

ORA-00604: 递归 SQL 级别  出现错误

ORA-01555: 快照过旧: 回退段号  (名称为 "") 过小

适用于

oracle企业版数据库，10.2.0.4及更高版本

症状

alter database open resetlogs,遇到下面的错误：

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…

改变

强行开库

原因

强行开库，说有的数据文件不同步。文件里的有些块的SCN大于当前SCN。

解决

如果没有Ora-1555错误的可用跟踪文件，用下面的方法收集0ra-704和ora-1555错误的trace文件：

SQL>Startup mount ;

SQL>alter session set tracefile_identifier=new1555 ;

SQL>alter database open resetlogs ;

这将会报ORA-1092错误，警告日志里将会报1555错误信息。

到udump或trace目录下：ls –lrt *new1555*

找到回滚段名，警告日志里的错误信息：

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

这边的回滚段号是11，换算成十六进制–> b

到trace文件里的表或索引的块头dump信息的ITL里找哪个事务正在用11号undo段。滚动到上面找到这些块的block header dump

Search the trace file from Table or index block header dump whose transaction layer has an undo segment 11

been used in the ITL.Scroll up to get the Buffer header dump of that block

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

So here we see ITL allocated is 0x01.

Transaction identifier –> <undo no>.<slot>.<wrap> —> 0x000b.00b.00000e7a

Undo段号 —> 0x000b –>十进制就是 11。

This block belong to 0x0040003e –(1/62)

Find the SCN of this block from the BH(Buffer header) for 0x0040003e –(1/62)

So in this case its the one highlighted above in trace scn: 0x0000.046b527a

根据上面的SCN来设置_mimimum_giga_scn 的值

scn: 0x0000.046b527a

Convert 0x0000 –> Decimal –> 0

Convert 046b527a –> Decimal –>74142330

Convert –> 074142330 /1024/1024/1024 =0.069050

Add + 2G to the above value and round it up

_minimum_giga_scn = 3G

在pfile里设置这个参数值，并进行下面的强制开库步骤：

SQL>Startup mount pfile=<> ;

SQL>recover database using backup controlfile until cancel ;

Cancel

SQL>Alter database open resetlogs ;

强制开库已经完成，进行导出，重建数据库并导入数据。