标签云
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,674)
- DB2 (22)
- MySQL (73)
- Oracle (1,536)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (22)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (14)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (67)
- Oracle Bug (8)
- Oracle RAC (52)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (562)
- Oracle安装升级 (92)
- 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)
-
最近发表
- GoldenGate 19安装和打patch
- dd破坏asm磁盘头恢复
- 删除asmlib磁盘导致磁盘组故障恢复
- Kylin Linux 安装19c
- 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默认服务配置优先节点
标签归档:ORA-600 4000
再现ORA-600 4000故障处理
有一个10g的库,由于redo损坏导致无法正常recover成功
正常途径无法open成功,尝试强制打开库
Wed Oct 18 11:23:25 2023 alter database open resetlogs Wed Oct 18 11:23:25 2023 RESETLOGS is being done without consistancy checks. This may result in a corrupted database. The database should be recreated. RESETLOGS after incomplete recovery UNTIL CHANGE 236715370 Resetting resetlogs activation ID 4009817354 (0xef00f50a) Wed Oct 18 11:23:26 2023 Setting recovery target incarnation to 3 Wed Oct 18 11:23:26 2023 Assigning activation ID 4271120987 (0xfe94225b) Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: D:\ORADATA\EAIS\REDO01.LOG Successful open of redo thread 1 Wed Oct 18 11:23:26 2023 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Wed Oct 18 11:23:26 2023 SMON: enabling cache recovery Wed Oct 18 11:23:27 2023 Errors in file d:\hys_db\admin\eais\udump\eais_ora_10916.trc: ORA-00600: 内部错误代码, 参数: [4000], [9], [], [], [], [], [], [] Wed Oct 18 11:23:28 2023 Errors in file d:\hys_db\admin\eais\udump\eais_ora_10916.trc: ORA-00704: 引导程序进程失败 ORA-00704: 引导程序进程失败 ORA-00600: 内部错误代码, 参数: [4000], [9], [], [], [], [], [], [] Wed Oct 18 11:23:28 2023 Error 704 happened during db open, shutting down database USER: terminating instance due to error 704 Wed Oct 18 11:23:28 2023 Errors in file d:\hys_db\admin\eais\bdump\eais_pmon_1764.trc: ORA-00704: bootstrap process failure Wed Oct 18 11:23:29 2023 Errors in file d:\hys_db\admin\eais\bdump\eais_reco_9628.trc: ORA-00704: bootstrap process failure Wed Oct 18 11:23:29 2023 Errors in file d:\hys_db\admin\eais\bdump\eais_smon_9884.trc: ORA-00704: bootstrap process failure Wed Oct 18 11:23:29 2023 Errors in file d:\hys_db\admin\eais\bdump\eais_ckpt_10096.trc: ORA-00704: bootstrap process failure Wed Oct 18 11:23:29 2023 Errors in file d:\hys_db\admin\eais\bdump\eais_lgwr_8932.trc: ORA-00704: bootstrap process failure Wed Oct 18 11:23:29 2023 Errors in file d:\hys_db\admin\eais\bdump\eais_dbw0_9892.trc: ORA-00704: bootstrap process failure Wed Oct 18 11:23:29 2023 Errors in file d:\hys_db\admin\eais\bdump\eais_mman_9472.trc: ORA-00704: bootstrap process failure Wed Oct 18 11:23:29 2023 Errors in file d:\hys_db\admin\eais\bdump\eais_psp0_7692.trc: ORA-00704: bootstrap process failure Instance terminated by USER, pid = 10916 ORA-1092 signalled during: alter database open resetlogs...
resetlogs失败,报ora-600 4000错误,查看相关trace文件
*** 2023-10-18 11:23:27.103 ksedmp: internal or fatal error ORA-00600: 内部错误代码, 参数: [4000], [9], [], [], [], [], [], [] Current SQL statement for this session: select ctime, mtime, stime from obj$ where obj# = :1 ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- _ksedst+38 CALLrel _ksedst1+0 0 1 _ksedmp+898 CALLrel _ksedst+0 0 _ksfdmp+14 CALLrel _ksedmp+0 3 603A816A CALLreg 00000000 6AE8258 3 603A8550 CALLrel 603A80D8 6AE8258 4FB1090 FA0 1 8C886B0 __VInfreq__ktudba+1 CALLrel _kgeasi+0 6AE8258 4FB1090 FA0 2 1 0 9 0 26 _ktrgcm+851 CALLrel _ktudba+0 9 8C88B68 0 0 _ktrgtc+526 CALLrel _ktrgcm+0 4FC753C _kdsgrp+937 CALLrel _ktrgtc+0 4FC753C 4FC74E0 1F1FB00 8C88CB4 240 2AED19C 1F1F71C _kdsfbrcb+432 CALLrel _kdsgrp+0 4FC7538 0 4FC7538 _qertbFetchByRowID+ CALLrel _kdsfbrcb+0 4FC7538 4FDF004 0 1 0 0 4344 4FC74E0 22E8078 8C88E14 0 _opifch2+3104 CALL??? 00000000 8DA05838 20135FC 8C890AC 1 _opifch+51 CALLrel _opifch2+0 89 5 8C891F0 _opiodr+1099 CALLreg 00000000 5 2 8C89938 _rpidrus+178 CALLrel _opiodr+0 5 2 8C89938 5 _rpidru+88 CALLrel _rpidrus+0 8C894C4 _rpiswu2+426 CALLreg 00000000 8C8988C _rpidrv+1461 CALLrel _rpiswu2+0 90F3CCB4 0 8C89860 2 8C89880 0 8C89860 0 84DF58 84E018 8C8988C 8 _rpifch+44 CALLrel _rpidrv+0 5 5 8C89938 8 _kqdpts+166 CALLrel _rpifch+0 5 5 5 3 90AE2383 7 C 0 0 0 0 0 0 0 5 2 90AE237C 7 C 0 0 0 0 0 0 0 _kqrlfc+478 CALLrel _kqdpts+0 90AE21F4 _kqlbplc+102 CALLrel _kqrlfc+0 _kqlblfc+240 CALLrel _kqlbplc+0 0 _adbdrv+12911 CALLrel _kqlblfc+0 0 8C8D034 _opiexe+11778 CALLrel _adbdrv+0 _opiosq0+6088 CALLrel _opiexe+0 4 0 8C8D894 _kpooprx+232 CALLrel _opiosq0+0 3 E 8C8D9AC A4 _kpoal8+775 CALLrel _kpooprx+0 8C8F6CC 8C8E248 1D 1 0 A4 _opiodr+1099 CALLreg 00000000 5E 17 8C8F6C8 60FEFF8D CALLreg 00000000 5E 17 8C8F6C8 0 _opitsk+1017 CALL??? 00000000 _opiino+1087 CALLrel _opitsk+0 0 0 _opiodr+1099 CALLreg 00000000 3C 4 8C8FC60 _opidrv+819 CALLrel _opiodr+0 3C 4 8C8FC60 0 _sou2o+45 CALLrel _opidrv+0 3C 4 8C8FC60 _opimai_real+112 CALLrel _sou2o+0 8C8FC54 3C 4 8C8FC60 _opimai+92 CALLrel _opimai_real+0 2 8C8FC8C _OracleThreadStart@ CALLrel _opimai+0 4+708 74A93438 CALLptr 00000000 76F09830 CALLreg 00000000 76F09800 CALLrel 76F0980B --------------------- Binary Stack Dump ---------------------
通过一些技巧处理数据库正常open,导出数据完成本次恢复,参考以前恢复类似case:
重现ORA-600 4000异常
通过bbed解决ORA-00600[4000]案例
记录一次ORA-600 4000数据库故障恢复
ORACLE 8.1.7 数据库ORA-600 4000故障恢复
ORA-00704 ORA-00604 ORA-00942故障恢复
接到客户请求,oracle数据库停机重启维护之后,无法正常启动,请求我们给予协助
数据库启动报ORA-00704 ORA-00604 ORA-00942错误
SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production PL/SQL Release 11.2.0.1.0 - Production CORE 11.2.0.1.0 Production TNS for 32-bit Windows: Version 11.2.0.1.0 - Production NLSRTL Version 11.2.0.1.0 - Production SQL> startup open ORACLE 例程已经启动。 Total System Global Area 1288949760 bytes Fixed Size 1376520 bytes Variable Size 377491192 bytes Database Buffers 897581056 bytes Redo Buffers 12500992 bytes 数据库装载完毕。 ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 1 ORA-00942: table or view does not exist 进程 ID: 2756 会话 ID: 5 序列号: 9
alert日志报错
SMON: enabling cache recovery Errors in file d:\app\administrator\diag\rdbms\xff\xff\trace\xff_ora_2756.trc: ORA-00704: 引导程序进程失败 ORA-00604: 递归 SQL 级别 1 出现错误 ORA-00942: 表或视图不存在 Errors in file d:\app\administrator\diag\rdbms\xff\xff\trace\xff_ora_2756.trc: ORA-00704: 引导程序进程失败 ORA-00604: 递归 SQL 级别 1 出现错误 ORA-00942: 表或视图不存在 Error 704 happened during db open, shutting down database USER (ospid: 2756): terminating the instance due to error 704 Instance terminated by USER, pid = 2756 ORA-1092 signalled during: ALTER DATABASE OPEN... opiodr aborting process unknown ospid (2756) as a result of ORA-1092 Fri Nov 30 12:51:26 2018 ORA-1092 : opitsk aborting process
根据这些年的恢复经验,恢复过相关错误的主要有:
ORA-01092 ORA-00704 ORA-00942
Oracle 11g丢失access$恢复方法
11.1.0.7版本也会出现access$表丢失导致数据库无法启动
总结主要两类:1. 由于某种bug导致access$表丢失的故障,另外一种是由于坏块导致数据库核心基表损坏引起,对于这个库进行分析
dbv 检查坏块
D:\APP\ADMINISTRATOR\ORADATA\ORCL> dbv file=system01.dbf DBVERIFY: Release 10.2.0.3.0 - Production on 星期五 11月 30 15:11:24 2018 Copyright (c) 1982, 2005, Oracle. All rights reserved. DBVERIFY - 开始验证: FILE = system01.dbf DBVERIFY - 验证完成 检查的页总数: 93440 处理的页总数 (数据): 61979 失败的页总数 (数据): 0 处理的页总数 (索引): 13560 失败的页总数 (索引): 0 处理的页总数 (其它): 3067 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 14834 标记为损坏的总页数: 0 流入的页总数: 0 最高块 SCN : 659587683 (0.659587683)
通过dbv检查数据库,确定system没有坏块
10046跟踪数据库启动
SQL> startup mount; ORACLE 例程已经启动。 Total System Global Area 1288949760 bytes Fixed Size 1376520 bytes Variable Size 377491192 bytes Database Buffers 897581056 bytes Redo Buffers 12500992 bytes 数据库装载完毕。 SQL> oradebug setmypid 已处理的语句 SQL> alter session set db_file_multiblocK_read_count=1; 会话已更改。 SQL> ALTER SESSION SET EVENTS '704 trace name errorstack level 3'; 会话已更改。 SQL> oradebug EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12 已处理的语句 SQL> oradebug TRACEFILE_NAME d:\app\administrator\diag\rdbms\xff\xff\trace\xff_ora_1132.trc --trace信息 PARSE ERROR #3:len=208 dep=1 uid=0 oct=9 lid=0 tim=5838844893 err=942 CREATE UNIQUE INDEX I_OBJ1 ON OBJ$(OBJ#,OWNER#,TYPE#) PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE ( INITIAL 64K NEXT 1024K MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 OBJNO 36 EXTENTS (FILE 1 BLOCK 336)) *** 2018-11-30 13:18:07.593 dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=3, mask=0x0) ----- Error Stack Dump ----- ORA-00704: 引导程序进程失败 ORA-00604: 递归 SQL 级别 1 出现错误 ORA-00942: 表或视图不存在
通过这一步基本上可以判断是由于obj$表丢失导致数据库创建I_OBJ1 index不成功,从而使得数据库无法正常启动。通过一些技巧修复出来obj$表,尝试启动数据库
SQL> alter database open; alter database open * 第 1 行出现错误: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [4000], [6], [], [], [], [], [], [], [], [], [], [] 进程 ID: 836 会话 ID: 355 序列号: 6027
alert日志报错
Fri Nov 30 15:33:47 2018 SMON: enabling cache recovery Errors in file d:\app\administrator\diag\rdbms\xff\xff\trace\xff_ora_836.trc (incident=648694): ORA-00600: 内部错误代码, 参数: [4000], [6], [], [], [], [], [], [], [], [], [], [] Incident details in: d:\app\administrator\diag\rdbms\xff\xff\incident\incdir_648694\xff_ora_836_i648694.trc Errors in file d:\app\administrator\diag\rdbms\xff\xff\trace\xff_ora_836.trc: ORA-00704: 引导程序进程失败 ORA-00600: 内部错误代码, 参数: [4000], [6], [], [], [], [], [], [], [], [], [], [] Errors in file d:\app\administrator\diag\rdbms\xff\xff\trace\xff_ora_836.trc: ORA-00704: 引导程序进程失败 ORA-00600: 内部错误代码, 参数: [4000], [6], [], [], [], [], [], [], [], [], [], [] Error 704 happened during db open, shutting down database USER (ospid: 836): terminating the instance due to error 704 Fri Nov 30 15:33:57 2018 Instance terminated by USER, pid = 836 ORA-1092 signalled during: alter database open... opiodr aborting process unknown ospid (836) as a result of ORA-1092
发现数据库启动报ORA-00704和ORA-00600: internal error code, arguments: [4000], [6], [], [], [], [], [], [],错误,根据以往经验,该问题是由于回滚段异常导致
分析trace信息
Dump continued from file: d:\app\administrator\diag\rdbms\xff\xff\trace\xff_ora_2124.trc ORA-00600: 内部错误代码, 参数: [4000], [6], [], [], [], [], [], [], [], [], [], [] ========= Dump for incident 651102 (ORA 600 [4000]) ======== *** 2018-11-30 15:46:32.125 dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0) ----- Current SQL Statement for txff session (sql_id=6apq2rjyxmxpj) ----- select line#, sql_text from bootstrap$ where obj# != :1 ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- _skdstdst()+121 CALLrel _kgdsdst() E6B1614 2 _ksedst1()+93 CALLrel _skdstdst() E6B1614 0 1 436646 435BE2 436646 _ksedst()+49 CALLrel _ksedst1() 0 1 _dbkedDefDump()+367 CALLrel _ksedst() 0 2 _ksedmp()+44 CALLrel _dbkedDefDump() 3 2 _ksfdmp()+56 CALLrel _ksedmp() 3EB _dbgexPhaseII()+164 CALLreg 00000000 C378A28 3EB 0 _dbgexProcessError( CALLrel _dbgexPhaseII() E2B0454 E2B6E50 E6B6078 )+2061 _dbgeExecuteForErro CALLrel _dbgexProcessError( E2B0454 E2B6E50 1 0 E2B0454 r()+43 ) E2B6E50 __VInfreq__dbgePost CALLrel _dbgeExecuteForErro E2B0454 E2B6E50 0 1 0 ErrorKGE()+260 r() _dbkePostKGE_kgsf() CALLrel _dbgePostErrorKGE() C378A28 E2BD274 258 +56 _kgeade()+299 CALLreg 00000000 C378A28 E2BD274 258 _kgeriv_int()+79 CALLrel _kgeade() C378A28 C378B50 E2BD274 258 0 FA0 0 0 0 1 E6B68A8 _kgeriv()+22 CALLrel _kgeriv_int() C378A28 E2BD274 FA0 0 1 E6B68A8 _kgeasi()+107 CALLrel _kgeriv() C378A28 E2BD274 FA0 1 E6B68A8 __VInfreq__ktuGetUs CALLrel _kgeasi() C378A28 E2BD274 FA0 2 1 0 6 0 egDba()+123 _ktrgcm()+5147 CALLrel _ktuGetUsegDba() 6 E6B6E78 0 0 E6B6F48 0 _ktrget2()+596 CALLrel _ktrgcm() F9FCEAC _kdst_fetch()+816 CALLrel _ktrget2() F9FCEAC F9FCE24 303 0 _kdstf11001010000km CALLrel _kdst_fetch() 1 F9FCEA8 E6B71C8 ()+2806 _kdsttgr()+5944 CALLrel _kdstf11001010000km F9FCEA8 0 557B044C F9FCDF8 () 2F0C3A6 E6B7894 _qertbFetch()+767 CALLrel _kdsttgr() F9FCEA8 0 557B044C F9FCDF8 557B0498 2F0C3A6 E6B7894 1 _opifch2()+2729 CALLptr 00000000 E6E7228 0 0 2 26180001 _opifch()+53 CALLrel _opifch2() 89 5 E6B7A04 _opiodr()+1248 CALLreg 00000000 5 2 E6B81FC _rpidrus()+186 CALLrel _opiodr() 5 2 E6B81FC 2 _rpidru()+90 CALLrel _rpidrus() E6B7D58 _rpiswu2()+557 CALLrel _rpidru() E6B813C _rpidrv()+1242 CALLrel _rpiswu2() 6D9A295C 0 6D9A29A8 2 E6B8184 0 6D9A2A28 0 0 544632 5448D6 E6B813C 8 _rpifch()+43 CALLrel _rpidrv() 2 5 E6B81FC 8 _kqlbebs()+1213 CALLrel _rpifch() 2 2 2 F013232 FA0 1 0 E6B8634 0 0 0 0 0 _kqlblfc()+175 CALLrel _kqlbebs() 0 E6BBBD4 _adbdrv()+16992 CALLrel _kqlblfc() 0 E6BBBD4 _opiexe()+13594 CALLrel _adbdrv() 4A 6E6CBC48 6DDEDB6C E6BBD68 6D60697 6E6CBC48 _opiosq0()+6248 CALLrel _opiexe() 4 0 E6BC734 _kpooprx()+277 CALLrel _opiosq0() 3 E E6BC9A0 A4 0 _kpoal8()+632 CALLrel _kpooprx() E6BF0A4 E6BD420 1B 1 0 A4 _opiodr()+1248 CALLreg 00000000 5E 1C E6BF0A0 _ttcpip()+1051 CALLreg 00000000 5E 1C E6BF0A0 0 _opitsk()+1404 CALL??? 00000000 C3832A8 5E E6BF0A0 0 E6BED30 E6BF1CC 53E52E 0 E6BF1F8 _opiino()+980 CALLrel _opitsk() 0 0 _opiodr()+1248 CALLreg 00000000 3C 4 E6BFBF4 _opidrv()+1201 CALLrel _opiodr() 3C 4 E6BFBF4 0 _sou2o()+55 CALLrel _opidrv() 3C 4 E6BFBF4 _opimai_real()+124 CALLrel _sou2o() E6BFC04 3C 4 E6BFBF4 _opimai()+125 CALLrel _opimai_real() 2 E6BFC2C _OracleThreadStart@ CALLrel _opimai() 2 E6BFF6C 7C9BA7F4 E6BFC34 0 4()+830 E6BFD04 7C82484C CALLreg 00000000 E5BFF9C 0 0 E5BFF9C 0 E6BFFC4 00000000 CALL??? 00000000 --------------------- Binary Stack Dump --------------------- Block header dump: 0x0040020b Object id on Block? Y seg/obj: 0x3b csc: 0x00.27508136 itc: 1 flg: O typ: 1 - DATA fsl: 0 fnx: 0x0 ver: 0x01 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0006.015.0005e9e9 0x00c0052c.916f.10 --U- 1 fsc 0x0000.27508263
报错比较明显该block比较异常,通过bbed修改相关block信息,相关处理参考:
重现ORA-600 4000异常
通过bbed解决ORA-00600[4000]案例
记录一次ORA-600 4000数据库故障恢复
ORACLE 8.1.7 数据库ORA-600 4000故障恢复
处理之后数据库正常open
Fri Nov 30 15:57:34 2018 SMON: enabling cache recovery Successfully onlined Undo Tablespace 2. Verifying file header compatibility for 11g tablespace encryption.. Verifying 11g file header compatibility for tablespace encryption completed SMON: enabling tx recovery Database Characterset is ZHS16GBK No Resource Manager plan active replication_dependency_tracking turned off (no async multimaster replication found) Fri Nov 30 15:57:38 2018 Starting background process QMNC Fri Nov 30 15:57:38 2018 QMNC started with pid=23, OS id=1152 Completed: alter database open
ORACLE 8.1.7 数据库ORA-600 4000故障恢复
在数据库的恢复过程中遇到ORA-600 4000错误挺多的,但是在oracle 8i(8.1.7)中遇到此类问题,还是第一次,做个记忆,供参考:
数据库故障起因:因为存储异常,导致当前redo损坏,并_allow_resetlogs_corruption参数尝试打开数据库
Media Recovery Log kcrrga: Warning. Log sequence in archive filename wrapped to fix length as indicated by %S in LOG_ARCHIVE_FORMAT. Old log archive with same name might be overwritten. ORA-279 signalled during: ALTER DATABASE RECOVER database using backup cont... Wed Aug 20 23:01:43 2014 ALTER DATABASE RECOVER CANCEL Media Recovery Cancelled Completed: ALTER DATABASE RECOVER CANCEL Wed Aug 20 23:01:50 2014 alter database open resetlogs RESETLOGS is being done without consistancy checks. This may result in a corrupted database. The database should be recreated. RESETLOGS after incomplete recovery UNTIL CHANGE 262618871 Wed Aug 20 23:01:50 2014 Thread 1 opened at log sequence 1 Current log# 3 seq# 1 mem# 0: F:\REDO01.LOG Successful open of redo thread 1. Wed Aug 20 23:01:50 2014 SMON: enabling cache recovery Wed Aug 20 23:01:50 2014 Errors in file C:\oracle\admin\YCFD\udump\ORA00320.TRC: ORA-00600: ??????????: [4000], [3], [], [], [], [], [], [] SMON: disabling cache recovery Wed Aug 20 23:01:51 2014 ORA-704 signalled during: alter database open resetlogs
数据库遭遇ORA-600 4000错误,数据库无法打开,分析对应trace日志
Dump file C:\oracle\admin\YCFD\udump\ORA00320.TRC Wed Aug 20 23:01:50 2014 ORACLE V8.1.7.0.0 - Production vsnsta=0 vsnsql=e vsnxtr=3 Windows 2000 Version 5.2 Service Pack 2, CPU type 586 Oracle8i Release 8.1.7.0.0 - Production JServer Release 8.1.7.0.0 - Production Windows 2000 Version 5.2 Service Pack 2, CPU type 586 Instance name: ycfd Redo thread mounted by this instance: 1 Oracle process number: 8 Windows thread id: 320, image: ORACLE.EXE *** SESSION ID:(7.1) 2014-08-20 23:01:50.838 *** 2014-08-20 23:01:50.838 ksedmp: internal or fatal error ORA-00600: ??????????: [4000], [3], [], [], [], [], [], [] Current SQL statement for this session: select ctime, mtime, stime from obj$ where obj# = :1 ----- Call Stack Trace -----
这里可以看出来,是因为数据库在启动之时需要执行select ctime, mtime, stime from obj$ where obj# = :1语句,但是由于每种原因出现ORA-600 4000导致数据库无法正常启动,继续分析日志
lock header dump: 0x0040003e Object id on Block? Y seg/obj: 0x12 csc: 0x00.fb5c5c5 itc: 1 flg: - typ: 1 - DATA fsl: 0 fnx: 0x0 ver: 0x01 Itl Xid Uba Flag Lck Scn/Fsc 0x01 xid: 0x0003.012.0002ae94 uba: 0x00801f5b.5389.11 --U- 1 fsc 0x0000.0fb5c5c6 SQL> select checkpoint_change# from v$database; 263570122
此处比较明显,通过xid可以知道三号回滚段中对应一个事务出现问题:
1. 该block为file 1 bock 62,object_id为 18(obj$)上有一个事务
2. 该事务的scn为263,570,886>database scn(263570122)导致该故障发生
3. 当数据库访问到file 1 block 62的时候,发现有一个事务,而该事务的scn大于数据库scn,从而出现ORA-600[4000]
解决该问题有几种方法
1. 修改block 62,人工提交该事务
2. 修改数据库scn,让数据库scn大于itl scn
解决block 62 事务问题后出现如下错误
Wed Aug 20 23:03:55 2014 SMON: enabling cache recovery Wed Aug 20 23:03:55 2014 Dictionary check beginning Dictionary check complete Wed Aug 20 23:03:55 2014 SMON: enabling tx recovery Wed Aug 20 23:03:56 2014 Errors in file C:\oracle\admin\YCFD\bdump\ycfdSMON.TRC: ORA-00600: internal error code, arguments: [4193], [21173], [21181], [], [], [], [], [] Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0 Mem# 0 errs 0: F:\REDO03.LOG SMON: terminating instance due to error 600 Instance terminated by SMON, pid = 2468
数据库出现ORA-600 4193,这个是常见错误,因为redo记录和undo记录不匹配导致,可以直接使用_corrupted_rollback_segments/_offline_rollback_segments屏蔽回滚段跳过
Wed Aug 20 23:08:10 2014 SMON: enabling cache recovery SMON: enabling tx recovery SMON: about to recover undo segment 1 SMON: mark undo segment 1 as needs recovery SMON: about to recover undo segment 2 SMON: mark undo segment 2 as needs recovery SMON: about to recover undo segment 3 SMON: mark undo segment 3 as needs recovery SMON: about to recover undo segment 4 SMON: mark undo segment 4 as needs recovery SMON: about to recover undo segment 5 SMON: mark undo segment 5 as needs recovery SMON: about to recover undo segment 6 SMON: mark undo segment 6 as needs recovery SMON: about to recover undo segment 7 SMON: mark undo segment 7 as needs recovery SMON: about to recover undo segment 1 SMON: mark undo segment 1 as needs recovery SMON: about to recover undo segment 2 SMON: mark undo segment 2 as needs recovery SMON: about to recover undo segment 3 SMON: mark undo segment 3 as needs recovery SMON: about to recover undo segment 4 SMON: mark undo segment 4 as needs recovery SMON: about to recover undo segment 5 SMON: mark undo segment 5 as needs recovery SMON: about to recover undo segment 6 SMON: mark undo segment 6 as needs recovery SMON: about to recover undo segment 7 SMON: mark undo segment 7 as needs recovery Wed Aug 20 23:08:15 2014 Completed: alter database open
其他类似文章:
ORA-600[4194]/[4193]解决
通过bbed解决ORA-600 4000案例
通过bbed解决ORA-00600[4000]案例
记录一次ORA-600 4000数据库故障恢复