-
加我微信
加我QQ
标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,670)
- DB2 (22)
- MySQL (73)
- Oracle (1,532)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (21)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (14)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (65)
- Oracle Bug (8)
- Oracle RAC (52)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (560)
- Oracle安装升级 (91)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (78)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁（RUs+OJVM）
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
- ORA-01092 ORA-00604 ORA-01558故障处理
- ORA-65088: database open should be retried
- Oracle 19c异常恢复—ORA-01209/ORA-65088
- ORA-600 16703故障再现
- 数据库启动报ORA-27102 OSD-00026 O/S-Error: (OS 1455)
- .[metro777@cock.li].Elbie勒索病毒加密数据库恢复
- 应用连接错误,初始化mysql数据库恢复
- RAC默认服务配置优先节点
- Oracle 19c RAC 替换私网操作
- 监听报TNS-12541 TNS-12560 TNS-00511错误
- drop tablespace xxx including contents恢复
- Linux 8 修改网卡名称
标签归档：ORA-00607
使用bbed解决ORA-00607/ORA-00600[4194]故障
ORA-00607/ORA-00600[4194]错误
数据库启动因为出现ORA-00607/ORA-00600[4194],导致数据库不能正常open
Fri Nov 4 23:10:37 2011 SMON: enabling cache recovery Fri Nov 4 23:10:37 2011 ARC2: Archival started ARC0: STARTING ARCH PROCESSES COMPLETE ARC0: Becoming the heartbeat ARCH ARC2 started with pid=18, OS id=21535 Fri Nov 4 23:10:38 2011 Errors in file /u01/oracle/admin/XFF/udump/xff_ora_21529.trc: ORA-00600: internal error code, arguments: [4194], [35], [6], [], [], [], [], [] Fri Nov 4 23:10:41 2011 Doing block recovery for file 1 block 18 Block recovery from logseq 2, block 48668 to scn 458453 Fri Nov 4 23:10:41 2011 Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0 Mem# 0 errs 0: /u01/oracle/oradata/XFF/redo01.log Block recovery stopped at EOT rba 2.48670.16 Block recovery completed at rba 2.48670.16, scn 0.458451 Doing block recovery for file 1 block 9 Block recovery from logseq 2, block 48668 to scn 458450 Fri Nov 4 23:10:41 2011 Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0 Mem# 0 errs 0: /u01/oracle/oradata/XFF/redo01.log Block recovery completed at rba 2.48670.16, scn 0.458451 Fri Nov 4 23:10:41 2011 Errors in file /u01/oracle/admin/XFF/udump/xff_ora_21529.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [4194], [35], [6], [], [], [], [], [] Error 604 happened during db open, shutting down database USER: terminating instance due to error 604 Instance terminated by USER, pid = 21529 ORA-1092 signalled during: ALTER DATABASE OPEN...
分析trace文件
*** SESSION ID:(159.3) 2011-11-04 23:10:37.648
tkcrrsarc: (WARN) Failed to find ARCH for message (message:0x1)
tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message:0x1)
*** ktuc_diag_dmp: dump of current change vector
ktudb redo: siz: 252 spc: 7200 flg: 0x0012 seq: 0x0037 rec: 0x06
xid: 0x0000.022.00000028
ktubl redo: slt: 34 rci: 0 opc: 11.1 objn: 15 objd: 15 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00400012.0037.1f
prev ctl max cmt scn: 0x0000.0006c75b prev tx cmt scn: 0x0000.0006c75d
txn start scn: 0xffff.ffffffff logon user: 0 prev brb: 4194318 prev bcl: 0 KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0000.020.00000029 uba: 0x00400013.0037.05
flg: C--- lkc: 0 scn: 0x0000.0006fecb
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x0040006a hdba: 0x00400069
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 1(0x1) flag: 0x2c lock: 0 ckix: 191
ncol: 17 nnew: 12 size: 0
col 1: [ 9] 5f 53 59 53 53 4d 55 31 24
col 2: [ 2] c1 02
col 3: [ 2] c1 03
col 4: [ 2] c1 0a
col 5: [ 4] c3 2e 55 0a
col 6: [ 1] 80
col 7: [ 3] c2 02 59
col 8: [ 3] c2 02 02
col 9: [ 1] 80
col 10: [ 2] c1 03
col 11: [ 2] c1 02
col 16: [ 2] c1 02
*** 2011-11-04 23:10:38.086
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [4194], [35], [6], [], [], [], [], []
Current SQL statement for this session:
update undo$ set name=:2,file#=:3,block#=:4,status$=:5,user#=:6,undosqn=:7,xactsqn=:8,scnbas=:9,
scnwrp=:10,inst#=:11,ts#=:12,spare1=:13 where us#=:1
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst()+27 call ksedst1() 0 ? 1 ?
ksedmp()+557 call ksedst() 0 ? 0 ? 0 ? 0 ? 0 ? 0 ?
ksfdmp()+19 call ksedmp() 3 ? BFFA8C28 ? AC152C0 ?
CBD2DA0 ? 3 ? BFFA9764 ?
kgeriv()+188 call 00000000 CBD2DA0 ? 3 ?
kseipre()+42 call kgeriv() CBD2DA0 ? B6A50020 ? 1062 ?
2 ? BFFA8C68 ? BFFA8C5C ?
ksesic2()+21 call kseipre() 1062 ? 2 ? BFFA8C68 ?
32B36940 ? BFFA8D38 ?
8C4A3A9 ?
kturdb()+1757 call ksesic2() 1062 ? 0 ? 23 ? 0 ? 0 ? 6 ?
0 ?
kco_issue_callback( call 00000000 B6A09FA4 ? B6A0A01E ? 11 ?
)+176 2D306014 ? B6A387C0 ?
kcoapl()+2440 call kco_issue_callback( B6A09FA0 ? 2D306000 ?
) B6A387C0 ?
kcbapl()+322 call kcoapl() B6A09FA0 ? 2D306000 ? 1 ? 0 ?
2000 ? 0 ? B6A387C0 ?
kcrfw_redo_gen()+94 call kcbapl() B6A09FA0 ? 2D3F6A1C ?
10 CBE3AE8 ? 0 ? B6A387C0 ?
kcbchg1_main()+8669 call kcrfw_redo_gen() 3 ? BFFA9358 ? BFFA9370 ?
CBE3AE8 ? 0 ? BFFA9390 ?
kcbchg1()+63 call kcbchg1_main() 0 ? 3 ? BFFA97B0 ? BFFA9798 ?
0 ? 0 ?
ktuchg()+3344 call kcbchg1() 0 ? 3 ? BFFA97B0 ? BFFA9798 ?
0 ? 0 ?
ktbchg2()+493 call ktuchg() 2 ? 2F9EEF8C ? 3 ? B6A0CA98 ?
B6A0CAA0 ? B6A09FA0 ?
B6A387C0 ? B6A0C7A0 ? 0 ? 0 ?
kddchg()+1661 call ktbchg2() 0 ? 2F9EEF8C ? B6A0CA98 ?
B6A0CAA0 ? B6A09FA0 ?
B6A387B8 ? B6A0C7A0 ? 0 ? 0 ?
kduovw()+7960 call kddchg() B6A3877C ? B6A0CA98 ?
B6A0CAA0 ? B6A09FA0 ?
B6A0C7A0 ? 0 ? 0 ? BFFA9C58 ?
kduurp()+2316 call kduovw() B6A3877C ? 0 ? 10 ?
B6A357A4 ? 0 ? B6A3877C ?
kdusru()+4339 call kduurp() B6A3877C ? 958412D ?
CBDC720 ? BFFA9FEC ? B8 ?
B6A40380 ?
kauupd()+366 call kdusru() B6A357A4 ? 2F9EEFF8 ?
B6A3877C ? 0 ?
updrow()+5889 call kauupd() B6A357A0 ? 2F9EEFF8 ?
B6A3877C ? 0 ? 2FA479FC ? E ?
F ? 2F9EF31C ? 12 ?
BFFB0544 ? BFFB04E4 ?
qerupRowProcedure() call updrow() 2F9E5B64 ? 7FFF ? DB4 ? 48 ?
+62 2F9EFBF4 ? BFFB08B4 ?
qerupFetch()+1187 call 00000000 2F9EF4B0 ? 7FFF ?
updaul()+3474 call 00000000 2F9EF4B0 ? 0 ? 2F9EF370 ?
7FFF ?
updThreePhaseExe()+ call updaul() 2F9E5B64 ? BFFB0D2C ? 0 ?
3470
updexe()+813 call updThreePhaseExe() 2F9E5B64 ? 0 ? B6A3877C ?
BFFB0E00 ? 2F9E5B64 ? 1 ?
BFFB0E00 ? 0 ?
opiexe()+17967 call updexe() 2F9E5B64 ? BFFB1074 ?
opiodr()+2347 call 00000000 4 ? 4 ? BFFB25A8 ?
rpidrus()+434 call opiodr() 4 ? 4 ? BFFB25A8 ? 2 ?
skgmstack()+210 call 00000000 BFFB2004 ? 97492FE ?
CBD2E9C ? BFFB1FE8 ?
BFFB24EC ? BFFB2004 ?
rpidru()+98 call skgmstack() BFFB1FE8 ? CBD2B60 ? F618 ?
9749546 ? BFFB2004 ?
rpiswu2()+1061 call 00000000 BFFB24EC ? BFFB25E8 ?
BFFB2500 ? 2 ? BFFB24B0 ?
5953 ?
rpidrv()+1915 call rpiswu2() 32F0A1D4 ? 0 ? BFFB24B0 ? 2 ?
BFFB2528 ? 0 ? BFFB24B0 ? 0 ?
9749800 ? 97498DC ?
BFFB24EC ? 8 ?
rpiexe()+65 call rpidrv() 2 ? 4 ? BFFB25A8 ? 8 ?
ktuscu()+697 call rpiexe() 2 ? 1C ? 2A ? 32FF3404 ? 0 ?
BFFB2710 ?
kqrcmt()+945 call 00000000 32AFA70C ? 3 ?
ktcrcm()+945 call kqrcmt() 31A2B84C ? 1 ? 0 ?
ktuswr()+1855 call ktcrcm() 31A2B84C ? 0 ? 0 ? 0 ? 0 ?
1 ? 0 ? 0 ?
ktusmous_online_und call ktuswr() 1 ? 0 ? 0 ? 0 ? 0 ? 0 ?
oseg()+951
ktusmout_online_ut( call ktusmous_online_und 1 ? A ? 0 ? 3 ?
)+737 oseg()
ktusmiut_init_ut()+ call ktusmout_online_ut( 1 ? 0 ? 0 ?
1084 )
ktuini()+688 call ktusmiut_init_ut() 0 ? BFFB4744 ? CBD2E9C ?
CBD2E9C ? CBD2DA0 ? 7 ?
adbdrv()+5699 call ktuini() 0 ? 0 ? 0 ? 0 ? 64000000 ?
3 ?
opiexe()+18301 call adbdrv() 59D4 ? 0 ? 9EE16E2F ? 494C4 ?
32B33CD0 ? 0 ?
opiosq0()+3918 call opiexe() 4 ? 0 ? BFFB8988 ?
kpooprx()+250 call opiosq0() 3 ? E ? BFFB8B90 ? A4 ?
kpoal8()+867 call kpooprx() BFFBAD68 ? BFFB990C ? 13 ?
1 ? 0 ? A4 ?
opiodr()+2347 call 00000000 5E ? 17 ? BFFBAD64 ?
ttcpip()+4227 call 00000000 5E ? 17 ? BFFBAD64 ? 0 ?
DABCA66 ? 93 ?
opitsk()+1991 call ttcpip() CBDA5A0 ? 5E ? BFFBAD64 ? 0 ?
BFFBA244 ? BFFBAE88 ?
opiino()+1387 call opitsk() 0 ? 0 ?
opiodr()+2347 call 00000000 3C ? 4 ? BFFBB950 ?
opidrv()+915 call opiodr() 3C ? 4 ? BFFBB950 ? 0 ?
sou2o()+113 call opidrv() 3C ? 4 ? BFFBB950 ?
opimai_real()+212 call sou2o() BFFBB934 ? 3C ? 4 ?
BFFBB950 ?
main()+111 call opimai_real() 2 ? BFFBB980 ?
__libc_start_main() call 00000000 2 ? BFFBBA44 ? BFFBBA50 ?
+220 47D9A828 ? 0 ? 1 ?
--------------------- Binary Stack Dump ---------------------
数据库在open的时候,需要去修改undo$对象的状态,从2该为3(offline->online)这个时候需要使用到系统回滚段,但是在使用系统回滚段的时候,使用uba=0×00400012的时候发生异常,导致数据库不能正常open,从而出现了ORA-00600[4194]的错误.而出现这个故障的原因,很可能是由于file 1 block 18块的异常导致.我们需要做的,就是让数据库启动的时候不使用file 1 block 18的block,而让数据库去另外的分配一个undo块.
bbed清除rollback分配块信息
[oracle@xifenfei ~]$ bbed listfile=list mode=edit password=blockedit
BBED: Release 2.0.0.0.0 - Limited Production on Sat Nov 5 01:11:49 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
BBED> set file 1 block 9
FILE# 1
BLOCK# 9
BBED> map
File: /u01/oracle/oradata/XFF/system01.dbf (1)
Block: 9 Dba:0x00400009
------------------------------------------------------------
Unlimited Undo Segment Header
struct kcbh, 20 bytes @0
struct ktech, 72 bytes @20
struct ktemh, 16 bytes @92
struct ktetb[6], 48 bytes @108
struct ktuxc, 104 bytes @4148
struct ktuxe[255], 10200 bytes @4252
ub4 tailchk @8188
BBED> p ktuxc
struct ktuxc, 104 bytes @4148
struct ktuxcscn, 8 bytes @4148
ub4 kscnbas @4148 0x0006c75b
ub2 kscnwrp @4152 0x0000
struct ktuxcuba, 8 bytes @4156
ub4 kubadba @4156 0x00400012
ub2 kubaseq @4160 0x0037
ub1 kubarec @4162 0x1f
sb2 ktuxcflg @4164 1 (KTUXCFSK)
ub2 ktuxcseq @4166 0x0037
sb2 ktuxcnfb @4168 1
ub4 ktuxcinc @4172 0x00000000
sb2 ktuxcchd @4176 34
sb2 ktuxcctl @4178 32
ub2 ktuxcmgc @4180 0x8002
ub4 ktuxcopt @4188 0x7ffffffe
struct ktuxcfbp[0], 12 bytes @4192
struct ktufbuba, 8 bytes @4192
ub4 kubadba @4192 0x00400012
ub2 kubaseq @4196 0x0037
ub1 kubarec @4198 0x05
sb2 ktufbext @4200 1
sb2 ktufbspc @4202 7200
struct ktuxcfbp[1], 12 bytes @4204
struct ktufbuba, 8 bytes @4204
ub4 kubadba @4204 0x00000000
ub2 kubaseq @4208 0x0035
ub1 kubarec @4210 0x2a
sb2 ktufbext @4212 5
sb2 ktufbspc @4214 3446
struct ktuxcfbp[2], 12 bytes @4216
struct ktufbuba, 8 bytes @4216
ub4 kubadba @4216 0x00000000
ub2 kubaseq @4220 0x0035
ub1 kubarec @4222 0x37
sb2 ktufbext @4224 5
sb2 ktufbspc @4226 1336
struct ktuxcfbp[3], 12 bytes @4228
struct ktufbuba, 8 bytes @4228
ub4 kubadba @4228 0x00000000
ub2 kubaseq @4232 0x0000
ub1 kubarec @4234 0x00
sb2 ktufbext @4236 0
sb2 ktufbspc @4238 0
struct ktuxcfbp[4], 12 bytes @4240
struct ktufbuba, 8 bytes @4240
ub4 kubadba @4240 0x00000000
ub2 kubaseq @4244 0x0000
ub1 kubarec @4246 0x00
sb2 ktufbext @4248 0
sb2 ktufbspc @4250 0
BBED> set count 16
COUNT 16
########################################################
使用bbed修改相关参数
########################################################
启动数据库
SQL> startup ORACLE instance started. Total System Global Area 318767104 bytes Fixed Size 1219160 bytes Variable Size 96470440 bytes Database Buffers 213909504 bytes Redo Buffers 7168000 bytes Database mounted. Database opened. SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod PL/SQL Release 10.2.0.1.0 - Production CORE 10.2.0.1.0 Production TNS for Linux: Version 10.2.0.1.0 - Production NLSRTL Version 10.2.0.1.0 - Production
通过bbed模拟ORA-00607/ORA-00600 4194 故障
在数据库恢复的案例中,遇到system rollback异常的故障算是中彩票了.处理起来比较麻烦,有些情况甚至是无法处理.这里通过试验模拟ORA-00607/ORA-00600[4194].类此的错误在一次银联的数据库恢复中也遇到过,不过当时由于功底不深,理解出现部分误差.
通过bbed模拟ORA-00607/ORA-00600[4194]错误
[oracle@xifenfei ~]$ bbed listfile=list mode=edit password=blockedit
BBED: Release 2.0.0.0.0 - Limited Production on Fri Nov 4 22:59:51 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
BBED> info
File# Name Size(blks)
----- ---- ----------
1 /u01/oracle/oradata/XFF/system01.dbf 0
2 /u01/oracle/oradata/XFF/undotbs01.dbf 0
3 /u01/oracle/oradata/XFF/sysaux01.dbf 0
4 /u01/oracle/oradata/XFF/users01.dbf 0
5 /u01/oracle/oradata/XFF/datfttuser.dbf 0
BBED> set block 9
BLOCK# 9
BBED> map
File: /u01/oracle/oradata/XFF/system01.dbf (1)
Block: 9 Dba:0x00400009
------------------------------------------------------------
Unlimited Undo Segment Header
struct kcbh, 20 bytes @0
struct ktech, 72 bytes @20
struct ktemh, 16 bytes @92
struct ktetb[6], 48 bytes @108
struct ktuxc, 104 bytes @4148
struct ktuxe[255], 10200 bytes @4252
ub4 tailchk @8188
BBED> p ktuxc
struct ktuxc, 104 bytes @4148
struct ktuxcscn, 8 bytes @4148
ub4 kscnbas @4148 0x0006c75b
ub2 kscnwrp @4152 0x0000
struct ktuxcuba, 8 bytes @4156
ub4 kubadba @4156 0x00400012
ub2 kubaseq @4160 0x0037
ub1 kubarec @4162 0x1f
sb2 ktuxcflg @4164 1 (KTUXCFSK)
ub2 ktuxcseq @4166 0x0037
sb2 ktuxcnfb @4168 1 <==free undo block num
ub4 ktuxcinc @4172 0x00000000
sb2 ktuxcchd @4176 34
sb2 ktuxcctl @4178 32
ub2 ktuxcmgc @4180 0x8002
ub4 ktuxcopt @4188 0x7ffffffe
struct ktuxcfbp[0], 12 bytes @4192
struct ktufbuba, 8 bytes @4192
ub4 kubadba @4192 0x00400013 <==uba (模拟试验修改为其他uba地址)
ub2 kubaseq @4196 0x0037 <==uba sequence
ub1 kubarec @4198 0x05
sb2 ktufbext @4200 1
sb2 ktufbspc @4202 7200
struct ktuxcfbp[1], 12 bytes @4204
struct ktufbuba, 8 bytes @4204
ub4 kubadba @4204 0x00000000
ub2 kubaseq @4208 0x0035
ub1 kubarec @4210 0x2a
sb2 ktufbext @4212 5
sb2 ktufbspc @4214 3446
struct ktuxcfbp[2], 12 bytes @4216
struct ktufbuba, 8 bytes @4216
ub4 kubadba @4216 0x00000000
ub2 kubaseq @4220 0x0035
ub1 kubarec @4222 0x37
sb2 ktufbext @4224 5
sb2 ktufbspc @4226 1336
struct ktuxcfbp[3], 12 bytes @4228
struct ktufbuba, 8 bytes @4228
ub4 kubadba @4228 0x00000000
ub2 kubaseq @4232 0x0000
ub1 kubarec @4234 0x00
sb2 ktufbext @4236 0
sb2 ktufbspc @4238 0
struct ktuxcfbp[4], 12 bytes @4240
struct ktufbuba, 8 bytes @4240
ub4 kubadba @4240 0x00000000
ub2 kubaseq @4244 0x0000
ub1 kubarec @4246 0x00
sb2 ktufbext @4248 0
sb2 ktufbspc @4250 0
BBED> set dba 0x00400013
DBA 0x00400013 (4194323 1,19)
BBED> p ktubh
struct ktubh, 26 bytes @20
struct ktubhxid, 8 bytes @20
ub2 kxidusn @20 0x0000
ub2 kxidslt @22 0x0020
ub4 kxidsqn @24 0x00000029
ub2 ktubhseq @28 0x0037 <==uba seq
ub1 ktubhcnt @30 0x05
ub1 ktubhirb @31 0x05
ub1 ktubhicl @32 0x00
ub1 ktubhflg @33 0x00
ub2 ktubhidx[0] @34 0x1fe8
ub2 ktubhidx[1] @36 0x1f2c
ub2 ktubhidx[2] @38 0x1e70
ub2 ktubhidx[3] @40 0x1db4
ub2 ktubhidx[4] @42 0x1cf8
ub2 ktubhidx[5] @44 0x1c3c
BBED> set dba 0x00400012
DBA 0x00400012 (4194322 1,18)
BBED> p ktubh
struct ktubh, 86 bytes @20
struct ktubhxid, 8 bytes @20
ub2 kxidusn @20 0x0000
ub2 kxidslt @22 0x0020
ub4 kxidsqn @24 0x00000029
ub2 ktubhseq @28 0x0037
ub1 ktubhcnt @30 0x23
ub1 ktubhirb @31 0x23
ub1 ktubhicl @32 0x00
ub1 ktubhflg @33 0x00
ub2 ktubhidx[0] @34 0x1fe8
…………
ub2 ktubhidx[35] @104 0x00b4
BBED> set block 9
BLOCK# 9
BBED> set count 16
COUNT 16
BBED> m /x 12004000 offset 4192
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
File: /u01/oracle/oradata/XFF/system01.dbf (1)
Block: 9 Offsets: 4192 to 4207 Dba:0x00400009
------------------------------------------------------------------------
12004000 37000500 0100201c 00000000
<32 bytes per line>
BBED> p ktuxc
struct ktuxc, 104 bytes @4148
struct ktuxcscn, 8 bytes @4148
ub4 kscnbas @4148 0x0006c75b
ub2 kscnwrp @4152 0x0000
struct ktuxcuba, 8 bytes @4156
ub4 kubadba @4156 0x00400012
ub2 kubaseq @4160 0x0037
ub1 kubarec @4162 0x1f
sb2 ktuxcflg @4164 1 (KTUXCFSK)
ub2 ktuxcseq @4166 0x0037
sb2 ktuxcnfb @4168 1
ub4 ktuxcinc @4172 0x00000000
sb2 ktuxcchd @4176 34
sb2 ktuxcctl @4178 32
ub2 ktuxcmgc @4180 0x8002
ub4 ktuxcopt @4188 0x7ffffffe
struct ktuxcfbp[0], 12 bytes @4192
struct ktufbuba, 8 bytes @4192
ub4 kubadba @4192 0x00400012 <==uba已经被修改
ub2 kubaseq @4196 0x0037
ub1 kubarec @4198 0x05
sb2 ktufbext @4200 1
sb2 ktufbspc @4202 7200
struct ktuxcfbp[1], 12 bytes @4204
struct ktufbuba, 8 bytes @4204
ub4 kubadba @4204 0x00000000
ub2 kubaseq @4208 0x0035
ub1 kubarec @4210 0x2a
sb2 ktufbext @4212 5
sb2 ktufbspc @4214 3446
struct ktuxcfbp[2], 12 bytes @4216
struct ktufbuba, 8 bytes @4216
ub4 kubadba @4216 0x00000000
ub2 kubaseq @4220 0x0035
ub1 kubarec @4222 0x37
sb2 ktufbext @4224 5
sb2 ktufbspc @4226 1336
struct ktuxcfbp[3], 12 bytes @4228
struct ktufbuba, 8 bytes @4228
ub4 kubadba @4228 0x00000000
ub2 kubaseq @4232 0x0000
ub1 kubarec @4234 0x00
sb2 ktufbext @4236 0
sb2 ktufbspc @4238 0
struct ktuxcfbp[4], 12 bytes @4240
struct ktufbuba, 8 bytes @4240
ub4 kubadba @4240 0x00000000
ub2 kubaseq @4244 0x0000
ub1 kubarec @4246 0x00
sb2 ktufbext @4248 0
sb2 ktufbspc @4250 0
BBED> sum apply
Check value for File 1, Block 9:
current = 0xe686, required = 0xe686
启动数据库
SQL> startup ORACLE instance started. Total System Global Area 318767104 bytes Fixed Size 1219160 bytes Variable Size 96470440 bytes Database Buffers 213909504 bytes Redo Buffers 7168000 bytes Database mounted. ORA-01092: ORACLE instance terminated. Disconnection forced
alert日志
Fri Nov 4 23:10:37 2011 SMON: enabling cache recovery Fri Nov 4 23:10:37 2011 ARC2: Archival started ARC0: STARTING ARCH PROCESSES COMPLETE ARC0: Becoming the heartbeat ARCH ARC2 started with pid=18, OS id=21535 Fri Nov 4 23:10:38 2011 Errors in file /u01/oracle/admin/XFF/udump/xff_ora_21529.trc: ORA-00600: internal error code, arguments: [4194], [35], [6], [], [], [], [], [] Fri Nov 4 23:10:41 2011 Doing block recovery for file 1 block 18 Block recovery from logseq 2, block 48668 to scn 458453 Fri Nov 4 23:10:41 2011 Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0 Mem# 0 errs 0: /u01/oracle/oradata/XFF/redo01.log Block recovery stopped at EOT rba 2.48670.16 Block recovery completed at rba 2.48670.16, scn 0.458451 Doing block recovery for file 1 block 9 Block recovery from logseq 2, block 48668 to scn 458450 Fri Nov 4 23:10:41 2011 Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0 Mem# 0 errs 0: /u01/oracle/oradata/XFF/redo01.log Block recovery completed at rba 2.48670.16, scn 0.458451 Fri Nov 4 23:10:41 2011 Errors in file /u01/oracle/admin/XFF/udump/xff_ora_21529.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [4194], [35], [6], [], [], [], [], [] Error 604 happened during db open, shutting down database USER: terminating instance due to error 604 Instance terminated by USER, pid = 21529 ORA-1092 signalled during: ALTER DATABASE OPEN...
数据库报ORA-00607/ORA-00600[4194]错误
昨天晚上处理一起比较奇特的ORA-00600[4194]错误的数据库恢复案例,客户数据库刚刚上线,因为一时疏忽没有做备份.谁知天有不测风云,就这样的系统也会出问题(数据库文件总共 5g redo log sequence#=9).这个事故告诉我们:作为dba在任何时候都不要有侥幸心理,备份重于一切
数据库报ORA-00607/ORA-00600[4194]错误
Thu Jul 26 13:21:11 2012 SMON: enabling cache recovery Thu Jul 26 13:21:11 2012 Errors in file /orasvr/admin/mispdata/udump/mispdata_ora_2865.trc: ORA-00600: internal error code, arguments: [4194], [31], [2], [], [], [], [], [] Thu Jul 26 13:21:11 2012 Doing block recovery for file 1 block 18 Block recovery from logseq 3994, block 3 to scn 89979535 Thu Jul 26 13:21:11 2012 Recovery of Online Redo Log: Thread 1 Group 1 Seq 3994 Reading mem 0 Mem# 0: /orasvr/mispdata/redo01.log Block recovery stopped at EOT rba 3994.5.16 Block recovery completed at rba 3994.5.16, scn 0.89979533 Doing block recovery for file 1 block 9 Block recovery from logseq 3994, block 3 to scn 89979532 Thu Jul 26 13:21:11 2012 Recovery of Online Redo Log: Thread 1 Group 1 Seq 3994 Reading mem 0 Mem# 0: /orasvr/mispdata/redo01.log Block recovery completed at rba 3994.5.16, scn 0.89979533 Thu Jul 26 13:21:11 2012 Errors in file /orasvr/admin/mispdata/udump/mispdata_ora_2865.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [4194], [31], [2], [], [], [], [], [] Error 604 happened during db open, shutting down database USER: terminating instance due to error 604 Instance terminated by USER, pid = 2865 ORA-1092 signalled during: ALTER DATABASE OPEN...
通过alert日志中,我们可以发现是因为ORA-00600[4194]导致数据库不能被正常open,但是这次不同的是在报ORA-00600之前有ORA-00607的错误出现,根据这个提示,应该是一个基本的数据块有问题导致.而ORA-00600[4194]是因为undo和redo不一致导致.对于本错误放在一起分析,大概的评估是因为内部对象的异常出现ora-607,导致undo和redo不一致出现ORA-00600[4194].
trace文件分析
--dump redo
DUMP OF REDO FROM FILE '/orasvr/mispdata/redo02.log'
Opcodes *.*
DBAs (file#, block#):
(1, 18)
RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
Times: creation thru eternity
FILE HEADER:
Compatibility Vsn = 169870080=0xa200300
Db ID=658120234=0x273a1e2a, Db Name='MISPDATA'
Activation ID=658142762=0x273a762a
Control Seq=16668=0x411c, File size=102400=0x19000
File Number=2, Blksiz=512, File Type=2 LOG
descrip:"Thread 0001, Seq# 0000003992, SCN 0x0000055c5e3c-0x0000055cac62"
thread: 1 nab: 0x5 seq: 0x00000f98 hws: 0x6 eot: 0 dis: 0
resetlogs count: 0x2d42646a scn: 0x0000.00000001 (1)
resetlogs terminal rcv count: 0x0 scn: 0x0000.00000000
prev resetlogs count: 0x0 scn: 0x0000.00000000
prev resetlogs terminal rcv count: 0x0 scn: 0x0000.00000000
Low scn: 0x0000.055c5e3c (89939516) 07/26/2012 11:17:42
Next scn: 0x0000.055cac62 (89959522) 07/26/2012 13:16:19
Enabled scn: 0x0000.00000001 (1) 08/16/2011 11:50:10
Thread closed scn: 0x0000.055cac61 (89959521) 07/26/2012 11:17:42
Disk cksum: 0x3088 Calc cksum: 0x3088
Terminal recovery stop scn: 0x0000.00000000
Terminal recovery 01/01/1988 00:00:00
Most recent redo scn: 0x0000.00000000
Largest LWN: 0 blocks
End-of-redo stream : No
Unprotected mode
Miscellaneous flags: 0x0
Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
--ORA-00600错误提示
*** 2012-07-26 13:21:11.566
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [4194], [31], [2], [], [], [], [], []
Current SQL statement for this session:
update undo$ set name=:2,file#=:3,block#=:4,status$=:5,user#=:6,undosqn=:7,
xactsqn=:8,scnbas=:9,scnwrp=:10,inst#=:11,ts#=:12,spare1=:13 where us#=:1
--ora-607
Error 607 in redo application callback
TYP:0 CLS:16 AFN:1 DBA:0x00400012 OBJ:4294967295 SCN:0x0000.0551610e SEQ: 1 OP:5.1
ktudb redo: siz: 256 spc: 7892 flg: 0x0012 seq: 0x003d rec: 0x02
xid: 0x0000.026.00000035
ktubl redo: slt: 38 rci: 0 opc: 11.1 objn: 15 objd: 15 tsn: 0
Undo type: Regular undo Begin trans Last buffer split: No
Temp Object: No
Tablespace Undo: No
0x00000000 prev ctl uba: 0x00400012.003d.01
prev ctl max cmt scn: 0x0000.0550709b prev tx cmt scn: 0x0000.0550709c
txn start scn: 0xffff.ffffffff logon user: 0 prev brb: 4194318 prev bcl: 0 KDO undo record:
KTB Redo
op: 0x04 ver: 0x01
op: L itl: xid: 0x0000.01e.00000035 uba: 0x00400012.003d.01
flg: C--- lkc: 0 scn: 0x0000.05511296
KDO Op code: URP row dependencies Disabled
xtype: XA flags: 0x00000000 bdba: 0x0040006a hdba: 0x00400069
itli: 1 ispac: 0 maxfr: 4863
tabn: 0 slot: 1(0x1) flag: 0x2c lock: 0 ckix: 0
ncol: 17 nnew: 12 size: 0
col 1: [ 9] 5f 53 59 53 53 4d 55 31 24
col 2: [ 2] c1 02
col 3: [ 2] c1 03
col 4: [ 2] c1 0a
col 5: [ 5] c4 5a 12 5a 14
col 6: [ 1] 80
col 7: [ 4] c3 08 5f 3d
col 8: [ 4] c3 02 38 52
col 9: [ 1] 80
col 10: [ 2] c1 04
col 11: [ 2] c1 02
col 16: [ 2] c1 02
Block after image is corrupt:
buffer tsn: 0 rdba: 0x00400012 (1/18)
scn: 0x0000.0551610e seq: 0x01 flg: 0x04 tail: 0x610e0201
frmt: 0x02 chkval: 0x65f8 type: 0x02=KTU UNDO BLOCK
这里信息比较多:
1.dump redo部分得到file 1 block 18块可能异常
2.ora-600部分可以得出数据库在执行undo$对象update的回滚操作时候报错
3.通过ora-607信息得到update undo$记录对应的数据块是file 1 block 106(dba 0×00400069),在相同数据库版本数据库中查询.也就是说undo$这个回滚段回滚的时候出现错误.
SQL> SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME 2 FROM DBA_EXTENTS A 3 WHERE FILE_ID = &FILE_ID 4 AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1; Enter value for file_id: 1 old 3: WHERE FILE_ID = &FILE_ID new 3: WHERE FILE_ID = 1 Enter value for block_id: 106 old 4: AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1 new 4: AND 106 BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1 OWNER ------------------------------ SEGMENT_NAME -------------------------------------------------------------------------------- SEGMENT_TYPE TABLESPACE_NAME PARTITION_NAME ------------------ ------------------------------ ------------------------------ SYS UNDO$ TABLE SYSTEM
4.发现dba 0×00400012发现坏块是file 1 block 18,查询坏块对象为
SQL> SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME 2 FROM DBA_EXTENTS A 3 WHERE FILE_ID = &FILE_ID 4 AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1; Enter value for file_id: 1 old 3: WHERE FILE_ID = &FILE_ID new 3: WHERE FILE_ID = 1 Enter value for block_id: 18 old 4: AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1 new 4: AND 18 BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1 OWNER ------------------------------ SEGMENT_NAME -------------------------------------------------------------------------------- SEGMENT_TYPE TABLESPACE_NAME PARTITION_NAME ------------------ ------------------------------ ------------------------------ SYS SYSTEM ROLLBACK SYSTEM
通过这里的分析,大概可以确定这次故障的原因:
因为ROLLBACK(file 1 block 18)坏块,redo 恢复undo 出现异常出现ORA-607,使得undo和redo不一致从而出现ORA-00600[4194],导致undo$(file 1 block 106)中的一条update事务不能被正常提交或者回滚,从而使得该数据库不能被正常打开.
针对这个库因为ROLLBACK异常,使用隐含参数无法屏蔽该回滚段,因为这个数据量非常小,我们选择了挖数据文件.如果数据量比较大,可以通过bbed尝试提交undo$(file 1 block 106)数据块中事务,看人品是否能够正常启动.