标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 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)
- 操作系统 (103)
- 数据库 (1,768)
- DB2 (22)
- MySQL (77)
- Oracle (1,609)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (591)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- ORA-600 kokiasg1故障分析(obj$中核心字典序列全部被恶意删除)
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
标签归档:ORA-600 4194
通过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)数据块中事务,看人品是否能够正常启动.
ORA-600[4194]/[4193]解决
朋友的库启动的时候出现ORA-600[4194]/[4193]错误
Tue Feb 14 09:34:11 2012 Errors in file d:\oracle\product\10.2.0\admin\interlib\bdump\interlib_smon_2784.trc: ORA-01595: error freeing extent (2) of rollback segment (3)) ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [4194], [6], [30], [], [], [], [], [] Tue Feb 14 09:35:34 2012 Errors in file d:\oracle\product\10.2.0\admin\interlib\udump\interlib_ora_2824.trc: ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [4193], [2005], [2008], [], [], [], [], [] ORA-00600: internal error code, arguments: [4193], [2005], [2008], [], [], [], [], [] Tue Feb 14 09:36:30 2012 DEBUG: Replaying xcb 0x1fa24174, pmd 0x1fba06d4 for failed op 8 Doing block recovery for file 2 block 177 No block recovery was needed Tue Feb 14 09:37:30 2012 Errors in file d:\oracle\product\10.2.0\admin\interlib\bdump\interlib_pmon_2732.trc: ORA-00600: internal error code, arguments: [4193], [2005], [2008], [], [], [], [], [] Tue Feb 14 09:37:31 2012 Errors in file d:\oracle\product\10.2.0\admin\interlib\bdump\interlib_pmon_2732.trc: ORA-00600: internal error code, arguments: [4193], [2005], [2008], [], [], [], [], []
从这里可以看到出现了ORA-600[4194]/[4193],第一感觉就是undo出现问题。
4193:表示undo和redo不一致(Arg [a] Undo record seq number,Arg [b] Redo record seq number );
4194:表示也是undo和redo不一致(Arg [a] Maximum Undo record number in Undo block,Arg [b] Undo record number from Redo block)
至于为什么有时候会只出现其中一个,我不太清楚,求答案
直接设置了下面参数,数据库就意外的open成功,这位朋友比较幸运
undo_tablespace=SYSTEM undo_management=MANUAL
既然库已经open,然后新建undo空间,删除出问题的undo,做如下修改,数据库恢复完成
undo_tablespace=新undo undo_management=AUTO
如果出现极端的情况可能需要做如下处理:
1.使用_offline_rollback_segments和_corrupted_rollback_segments屏蔽掉有问题的undo segment
2.继续可能出现ora-600[2662],需要推进scn