Email: service@parnassusdata.com 7 x 24 online support!
解决ORACLE强制开库遇到ORA-00704 ORA-00604 ORA-01555错误
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com
适用于
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 ;
强制开库已经完成,进行导出,重建数据库并导入数据。