标签云
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,767)
- DB2 (22)
- MySQL (77)
- Oracle (1,608)
- 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备份恢复 (590)
- 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-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报错
- [MY-013183] [InnoDB] Assertion failure故障处理
标签归档:ORA-600 4194
undo异常总结和恢复思路
UNDO异常报错千奇百怪,针对本人遇到的比较常见的undo异常报错进行汇总,仅供参考,数据库恢复过程是千奇百怪的,不能照搬硬套.
ORA-00704/ORA-00376
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 2
ORA-00376: file 3 cannot be read at this time
ORA-01110: data file 3: ‘/u01/oracle/oradata/ora11g/undotbs01.dbf’
Error 704 happened during db open, shutting down database
USER (ospid: 17864): terminating the instance due to error 704
Instance terminated by USER, pid = 17864
ORA-1092 signalled during: alter database open…
opiodr aborting process unknown ospid (17864) as a result of ORA-1092
ORA-00600[4097]
Fri Aug 31 23:14:10 2012
Errors in file /u01/oradata/orcl/bdump/orcl_smon_15589.trc:
ORA-00600: internal error code, arguments: [4097], [], [], [], [], [], [], []
Fri Aug 31 23:14:12 2012
Non-fatal internal error happenned while SMON was doing logging scn->time mapping.
SMON encountered 1 out of maximum 100 non-fatal internal errors.
ORA-01595/ORA-00600[4194]
Fri Aug 31 23:14:14 2012
Errors in file /u01/oradata/orcl/bdump/orcl_smon_15589.trc:
ORA-01595: error freeing extent (2) of rollback segment (4))
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4194], [48], [34], [], [], [], [], []
0RA-00600[4193]
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[kcfrbd_3]
Wed Dec 05 10:26:35 2012
SMON: enabling tx recovery
Wed Dec 05 10:26:35 2012
Database Characterset is ZHS16GBK
Wed Dec 05 10:26:35 2012
Errors in file d:\oracle\product\10.2.0\admin\orcl\bdump\orcl_smon_548.trc:
ORA-00600: internal error code, arguments: [kcfrbd_3], [2], [2279045], [1], [2277120], [2277120], [], []
SMON: terminating instance due to error 474
ORA-00600[4137]
Fri Jul 6 18:00:40 2012
SMON: ignoring slave err,downgrading to serial rollback
Fri Jul 6 18:00:41 2012
Errors in file /usr/local/oracle/admin/techdb/bdump/techdb_smon_16636.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
ORACLE Instance techdb (pid = 8) – Error 600 encountered while recovering transaction (3, 17).
ORA-01595/ORA-01594
Sat May 12 21:54:17 2012
Errors in file /oracle/app/admin/prmdb/bdump/prmdb2_smon_483522.trc:
ORA-01595: error freeing extent (2) of rollback segment (19))
ORA-01594: attempt to wrap into rollback segment (19) extent (2) which is being freed
ORA-00704/ORA-01555
Fri May 4 21:04:21 2012
select ctime, mtime, stime from obj$ where obj# = :1
Fri May 4 21:04:21 2012
Errors in file /oracle/admin/standdb/udump/perfdb_ora_1286288.trc:
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 40 with name “_SYSSMU40$” too small
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 1286288
ORA-1092 signalled during: alter database open resetlogs…
ORA-00607/ORA-00600[4194]
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…
ORA-00704/ORA-00600[4000]
Thu Feb 28 19:29:13 2013
Errors in file /u1/PROD/prodora/db/tech_st/10.2.0/admin/PROD_oracle/udump/prod_ora_20989.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00600: internal error code, arguments: [4000], [50], [], [], [], [], [], []
Thu Feb 28 19:29:13 2013
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 20989
ORA-1092 signalled during: ALTER DATABASE OPEN RESETLOGS…
undo异常恢复处理思路
除了极少数undo坏块,undo文件丢失外,大部分undo异常是因为redo未被正常进行前滚,从而导致undo回滚异常数据库无法open,解决此类问题,需要结合一般需要结合redo异常处理技巧在其中,一般undo异常处理思路
1.切换undo_management= MANUAL尝试启动数据库,如果不成功进入2
2.设置10513 等event尝试启动数据库,如果不成功进入3
3.使用_offline_rollback_segments/_corrupted_rollback_segments屏蔽回滚段
4.如果依然不能open数据库,考虑使用bbed工具提交事务,修改回滚段状态等操作
5.如果依然还不能open数据库,考虑使用dul
如果您按照上述步骤还不能解决,请联系我们,将为您提供专业数据库技术支持
Phone:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
姊妹篇
ORACLE REDO各种异常恢复
ORACLE丢失各种文件导致数据库不能OPEN恢复
发表在 Oracle备份恢复
标签为 ORA-00376, ORA-00704, ORA-01595, ORA-600 4000, ORA-600 4097, ORA-600 4193, ORA-600 4194, ORA-6004137, oracle异常恢复, ORACLE恢复, undo异常
评论关闭
ORA-607/ORA-600[4194]不一定是重大灾难
以前解决过ORA-607/ORA-600[4194]和模拟过ORA-607/ORA-600[4194]错误,所以固定思维任务ORA-607/ORA-600[4194]可能就是重大灾难,通过这个案例来说明ORA-607/ORA-600[4194]可能也就是一个常规的不能再常规的错误:有一网友数据库因意外关闭电源导致启动过程出现ORA-00607/ORA-00600[4194]/ORA-00600[4097]的错误,使得数据库启动失败.
SMON: enabling tx recovery Fri Aug 31 23:14:08 2012 Database Characterset is ZHS16GBK replication_dependency_tracking turned off (no async multimaster replication found) Starting background process QMNC QMNC started with pid=19, OS id=15619 Fri Aug 31 23:14:10 2012 Errors in file /u01/oradata/orcl/bdump/orcl_smon_15589.trc: ORA-00600: internal error code, arguments: [4097], [], [], [], [], [], [], [] Fri Aug 31 23:14:12 2012 Non-fatal internal error happenned while SMON was doing logging scn->time mapping. SMON encountered 1 out of maximum 100 non-fatal internal errors. Fri Aug 31 23:14:12 2012 Completed: alter database open Fri Aug 31 23:14:14 2012 Errors in file /u01/oradata/orcl/bdump/orcl_smon_15589.trc: ORA-01595: error freeing extent (2) of rollback segment (4)) ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [4194], [48], [34], [], [], [], [], [] Fri Aug 31 23:29:41 2012 Errors in file /u01/oradata/orcl/bdump/orcl_smon_15589.trc: ORA-00607: Internal error occurred while making a change to a data block ORA-00600: internal error code, arguments: [4194], [17], [10], [], [], [], [], [] Fri Aug 31 23:29:43 2012 Errors in file /u01/oradata/orcl/bdump/orcl_smon_15589.trc: ORA-00600: internal error code, arguments: [4194], [48], [34], [], [], [], [], [] Fri Aug 31 23:29:44 2012 Errors in file /u01/oradata/orcl/bdump/orcl_pmon_15577.trc: ORA-00474: SMON process terminated with error Fri Aug 31 23:29:44 2012 PMON: terminating instance due to error 474 Instance terminated by PMON, pid = 15577
通过alert日志可以定位到SMON_SCN_TIME表或者其回滚操作可能异常,结合alert和trace分析,发现这次错误的操作主要sql语句为:
ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [4194], [48], [34], [], [], [], [], [] Current SQL statement for this session: UPDATE SYS.COL_USAGE$ SET EQUALITY_PREDS = EQUALITY_PREDS + DECODE(BITAND(:FLAG, 1), 0, 0, 1), EQUIJOIN_PREDS = EQUIJOIN_PREDS + DECODE(BITAND(:FLAG, 2), 0, 0, 1), NONEQUIJOIN_PREDS = NONEQUIJOIN_PREDS + DECODE(BITAND(:FLAG, 4), 0, 0, 1), RANGE_PREDS = RANGE_PREDS + DECODE(BITAND(:FLAG, 8), 0, 0, 1), LIKE_PREDS = LIKE_PREDS + DECODE(BITAND(:FLAG, 16), 0, 0, 1), NULL_PREDS = NULL_PREDS + DECODE(BITAND(:FLAG, 32), 0, 0, 1), TIMESTAMP = :TIME WHERE OBJ# = :OBJN AND INTCOL# = :COLN ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [4194], [17], [10], [], [], [], [], [] Current SQL statement for this session: UPDATE SYS.MON_MODS$ SET INSERTS = INSERTS + :INS, UPDATES = UPDATES + :UPD, DELETES = DELETES + :DEL, FLAGS = (DECODE(BITAND(FLAGS, :FLAG), :FLAG, FLAGS, FLAGS + :FLAG)), DROP_SEGMENTS = DROP_SEGMENTS + :DROPSEG, TIMESTAMP = :TIME WHERE OBJ# = :OBJN ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [4097], [], [], [], [], [], [], [] Current SQL statement for this session: INSERT INTO SMON_SCN_TIME (THREAD, TIME_MP, TIME_DP, SCN, SCN_WRP, SCN_BAS, NUM_MAPPINGS, TIM_SCN_MAP) VALUES (0, :1, :2, :3, :4, :5, :6, :7)
这里主要涉及到对oracle的三张表的操作
COL_USAGE$:主要是在收集统计信息的时候作为是否需要收集列直方图信息参考
MON_MODS$:Oracle主要利用该表来记录那些表的数据发生改变,方便收集统计信息
SMON_SCN_TIME:记录SCN和TIME的对应关系
通过这里的分析可以确定这三张表中的数据对于数据库来说不是致命的基表信息,在数据库运行过程中可以清理掉这些信息,最多就是因为数据库性能的下降或者SCN和TIME互转功能不完善.
解决思路
完整的undo异常处理顺序
1.从alert中可以看出来数据库是在open之后由于SMON回滚到上述几条sql异常导致数据库down,所以可以尝试使用system回滚段启动数据库,看看是否可以屏蔽相关问题
2.如果方法1不可行,那使用event屏蔽smon对回滚段的相关操作,使得数据库正常启动
3.如果由于存在特殊事务,event无法屏蔽,尝试使用隐含参数处理该问题
4.如果隐含参数尚无法解决给问题考虑使用bbed
5.如果bbed不能解决,那只能选择dul或者其类似工具处理
这个案例中我们明确的看到是因为上面的三条sql回滚异常出现问题导致,对于这样的问题,经过测试使用方法1和2都能够顺利解决问题(open库之后需要重建undo,删除有问题undo表空间,修改参数[可能包括event],切换undo表空间).因为遇到几次ORA-607/ORA-600[4194]是因为system rollback损坏导致,所以这次开始也认为是一次比较复杂的恢复,最后证明这次是一种非常常规的恢复.对于ORACLE的数据库恢复有经验可能会比较快的定位问题,但是如果按照固定的思路去想可能会让自己走进死胡同.
使用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