标签云
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,758)
- DB2 (22)
- MySQL (76)
- Oracle (1,600)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (165)
- 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 监听 (28)
- Oracle备份恢复 (588)
- Oracle安装升级 (96)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (84)
- 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 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故障处理
- Oracle 19c 202504补丁(RUs+OJVM)-19.27
- Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
- pdu完美支持金仓数据库恢复(KingbaseES)
- 虚拟机故障引起ORA-00310 ORA-00334故障处理
- pg创建gbk字符集库
- PostgreSQL运行日志管理
- ora-600 kdsgrp1 错误描述
- GAM、SGAM 或 PFS 页上存在页错误处理
- ORA-600 krhpfh_03-1208
分类目录归档:Oracle
因为高版本引起ORA-00600[17059]
alert日志出现ORA-00600[17059]
Wed Aug 01 03:19:29 2012 Errors in file /oracle/diag/rdbms/sgerp5/sgerp5/trace/sgerp5_ora_5177388.trc (incident=682625): ORA-00600: 内部错误代码, 参数: [17059], [0x700000A18EE85E0], [0x70000085506A820], [0x700000A51F56E40], [], [], [], [] Incident details in: /oracle/diag/rdbms/sgerp5/sgerp5/incident/incdir_682625/sgerp5_ora_5177388_i682625.trc
查看trace文件
Dump continued from file: /oracle/diag/rdbms/sgerp5/sgerp5/trace/sgerp5_ora_5177388.trc ORA-00600: 内部错误代码, 参数: [17059], [0x700000A3ED7B240], [0x7000007C19384F8], [0x70000078BC51048], [], [], [], [] ========= Dump for incident 682624 (ORA 600 [17059]) ======== *** 2012-07-31 22:38:06.130 ----- Current SQL Statement for this session (sql_id=03vurqhdanbv6) ----- begin insert into "000".tbExhRes(DeptCode,ERCode,ERName,CategoryCode,GoodsCategoryCode,TermMoney,IsAllowOwned,CategoryItemCode,GoodsCategoryItemCode) values('1521','20070115210130','连云港通灌路购物广场地堆130','200701','0201',1200,1,'0000','0000'); insert into "000".tbExhRes(DeptCode,ERCode,ERName,CategoryCode,GoodsCategoryCode,TermMoney,IsAllowOwned,CategoryItemCode,GoodsCategoryItemCode) values('1521','20070115210131','连云港通灌路购物广场地堆131','200701','0201',1200,1,'0000','0000'); …………近5万条类此sql end; ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- skdstdst()+002c bl 105e27f1c ksedst1()+0064 bl 101fadb74 ksedst()+0028 bl ksedst1() 000000000 ? 000000000 ? dbkedDefDump()+07fc bl 101faf398 ksedmp()+0048 bl 101fadb70 ksfdmp()+0058 bl ksedmp() 000000000 ? dbgexPhaseII()+0130 bl _ptrgl() dbgexProcessError() bl dbgexPhaseII() 110383690 ? 000000000 ? +09bc 600000006 ? dbgeExecuteForError bl dbgexProcessError() 110383690 ? 110388B10 ? ()+0040 1729C5E38 ? 000004028 ? dbgePostErrorKGE()+ bl dbgeExecuteForError FFFFFFFFFFF02C0 ? 110000328 ? 03c0 () FFFFFFFFFFF0350 ? 484222407FFFFFF8 ? 100154D20 ? dbkePostKGE_kgsf()+ bl dbgePostErrorKGE() 000000258 ? 110000328 ? 003c 25810594518 ? kgeade()+0300 bl _ptrgl() kgeriv_int()+0068 bl kgeade() 1070DA620 ? 1070DADB8 ? 1070D9E48 ? 1070DB208 ? 1070DA784 ? 1070DA788 ? 1070DA77C ? 1070DA794 ? kgeriv()+0020 bl kgeriv_int() 7000007C19384F8 ? 000000000 ? 000000001 ? FFFFFFFFFFF11E0 ? 700000A62228320 ? 7000007C19384F8 ? kgesiv()+007c bl kgeriv() 10102D590 ? 700000A3ED7B350 ? 700000A62228320 ? 000000005 ? 000000000 ? kgesic3()+0040 bl kgesiv() 7000007C19384F8 ? 000000000 ? 000000001 ? FFFFFFFFFFF11E0 ? 700000A62228320 ? kgltba()+0134 bl kgesic3() 110000328 ? 110594518 ? 42A3000042A3 ? 000000002 ? 700000A3ED7B240 ? 000000002 ? 7000007C19384F8 ? 000000002 ? kglrdtin()+01d4 bl kgltba() FFFFFFFFFFF1470 ? 000000000 ? FFFFFFFFFFF1318 ? 000000000 ? 000000001 ? 12BFB90F8 ? kglrtl()+0020 bl kglrdtin() 000000001 ? 000000000 ? 000000001 ? 169F90F18 ? 169F8E7F0 ? 12BFB90F8 ? FFFFFFFFFFF1470 ? pdy3M06_Add_Sql_Str bl kglrtl() FFFFFFFFFFF14F0 ? ing()+00c4 7FFF000000007FFF ? 10262A2A8 ? 11032DD20 ? 26FDBFA00 ? pdy8M92_Fill_SQD()+ bl pdy3M06_Add_Sql_Str 102683768 ? 000000000 ? 006c ing() 10267265C ? pdy8M74_Fill_Descri bl 101faf1a4 ptor()+0124 pdy8F07_Materialize bl pdy8M74_Fill_Descri 164B00E58 ? 165BD0380 ? _Descriptors()+038c ptor() 7000008C99BA368 ? pdy1F82_Write_MCode bl pdy8F07_Materialize FFFFFFFFFFF3968 ? 000000000 ? ()+0084 _Descriptors() pdy1F01_Driver()+01 bl pdy1F82_Write_MCode FFFFFFFFFFF18D0 ? 10726667C ? 58 () 7000008EA0F18D8 ? pdw0F82_Run_Code_Ge bl pdy1F01_Driver() 1028771D4 ? 000000000 ? n()+0088 pdw0F01_Code_Gen()+ bl pdw0F82_Run_Code_Ge FFFFFFFFFFF1A50 ? 12BFC3E48 ? 0250 n() phpcog()+0010 bl pdw0F01_Code_Gen() FFFFFFFFFFF3968 ? 70000078BC51048 ? 000000004 ? phpcmp()+13a0 bl phpcog() 11037D140 ? 700000000003640 ? pcicog()+0234 bl phpcmp() FFFFFFFFFFF3968 ? 70000078BC51048 ? 000000000 ? 000000000 ? 400000110000BEC ? FFFFFFFFFFF33F0 ? 000000000 ? 000000000 ? kkxcog()+01cc bl pcicog() FFFFFFFFFFF3968 ? 70000078BC51048 ? opitca()+0a50 bl kkxcog() 10009697C ? kksFullTypeCheck()+ bl opitca() 11082EDB8 ? 7000008C99BA740 ? 001c rpiswu2()+03c0 bl _ptrgl() kksLoadChild()+31e4 bl rpiswu2() 700000A717262C8 ? 7000008EA0F1970 ? 7000008C99BAA78 ? 107267650 ? 000000000 ? 55D16B348 ? FFFFFFFFFFF72B8 ? 000000000 ? kxsGetRuntimeLock() bl kksLoadChild() 110000328 ? 70000078BC51048 ? +083c 700000A57852278 ? kksfbc()+2230 bl kxsGetRuntimeLock() 110000328 ? 11082EDB8 ? FFFFFFFFFFF72B8 ? 12C00000000 ? 100006300000000 ? kkspsc0()+106c bl kksfbc() 11082EDB8 ? 3FFFF8150 ? 1085D16C170 ? 149510630 ? 000AE3AD5 ? 000000000 ? 000000000 ? 000000000 ? kksParseCursor()+00 bl kkspsc0() 1105B2748 ? 149510630 ? cc 000AE3AD5 ? 31032DD20 ? 600000000 ? A4000000000000 ? 000000000 ? opiosq0()+0b18 bl 103ecdd38 kpooprx()+019c bl 101fadff0 kpoal8()+04c0 bl kpooprx() FFFFFFFFFFFB454 ? 149510630 ? AE3AD400AE3AD4 ? 100000001 ? 000000000 ? A40000000000A4 ? opiodr()+0b48 bl 103ec82b0 ttcpip()+114c bl _ptrgl() opitsk()+169c bl 103eca2bc opiino()+09a0 bl opitsk() 1100981E8 ? 000000000 ? opiodr()+0b48 bl 103ec82b0 opidrv()+0440 bl opiodr() 3C2F736765 ? 41032DD20 ? FFFFFFFFFFFF8C0 ? 05F353137 ? sou2o()+0090 bl opidrv() 3C05C052EC ? 4A0071E60 ? FFFFFFFFFFFF8C0 ? opimai_real()+01b0 bl 101fad8cc main()+0090 bl opimai_real() 000000000 ? 000000000 ? __start()+0070 bl main() 000000000 ? 000000000 ? --------------------- Binary Stack Dump ---------------------
ORA-00600[17059]错误大部分都是因为高版本导致,对于本库的分析:因为该库的shared pool老化比较频繁,到我介入的时候,发现相关该类此sql已经不能找到,不能非常肯定的找出来原因,猜测可能原因是:这个库(版本为11.1.0.6 FOR AIX)因为开发基本上没有绑定参数,设置cursor_sharing=force,这里5万多条的insert会自动转换为参数形式,因为每个insert参数对应的值长度区别较大,使得BIND_MISMATCH不匹配导致高版本现象严重,从而出现了该Bug 9689310.
解决该问题
1.不要通过程序拼接sql出来,使用绑定参数形式
2.升级到相应新版本解决该问题
3.一次减少执行的sql数量,定时刷新shared pool[临时办法]
补充说明相关bug
Bug 5177766 OERI[17059] with SESSION_CACHED_CURSORS
Bug 8946311 Increase max children before reporting ORA-600 [17059]
BUG 9094984 ORA-600 [17059] WITH VERY HIGH CHILD CURSOR COUNTS BEING GENERATED
Bug 8922013 OERI [17059] / excess child cursors for SQL referencing REMOTE objects
Bug 9689310 Excessive child cursors / high VERSION_COUNT / OERI:17059 due to bind mismatch
BUG 8981059 HIGH VERSION COUNT:BIND_MISMATCH,USER_BIND_PEEK_MISMATCH,OPTIMIZER_MODE_MISMATCH
通过bbed修改回滚段状态解决ORA-00704故障
undo文件丢失
SQL> startup ORACLE instance started. Total System Global Area 313860096 bytes Fixed Size 1344652 bytes Variable Size 218106740 bytes Database Buffers 88080384 bytes Redo Buffers 6328320 bytes Database mounted. ORA-01157: cannot identify/lock data file 3 - see DBWR trace file ORA-01110: data file 3: '/u01/oracle/oradata/ora11g/undotbs01.dbf' [root@xifenfei ~]# ls -l /u01/oracle/oradata/ora11g/undotbs01.dbf ls: /u01/oracle/oradata/ora11g/undotbs01.dbf: No such file or directory
尝试offline 数据文件
SQL> alter database datafile 3 offline; Database altered. SQL> alter database open; alter database open * ERROR at line 1: ORA-01092: ORACLE instance terminated. Disconnection forced 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' Process ID: 16365 Session ID: 125 Serial number: 5
通过这里的错误提示可以看到因为datafile 3丢失并且offline,而在数据库启动的时候需要去使用该数据文件中的回滚段去回滚事务,但是因为该数据文件被offline,使得回滚不能进行从而出现该错误.这里出现ORA-00704和ORA-00604的错误,根据感觉不能轻易的使用屏蔽回滚段的方法实现,但是还是做一尝试.使用其他方法找到回滚段.
屏蔽回滚段后重启库
SQL> startup mount pfile='/tmp/pfile' force ORACLE instance started. Total System Global Area 313860096 bytes Fixed Size 1344652 bytes Variable Size 218106740 bytes Database Buffers 88080384 bytes Redo Buffers 6328320 bytes Database mounted. SQL> alter database open; alter database open * ERROR at line 1: ORA-01092: ORACLE instance terminated. Disconnection forced 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' Process ID: 16696 Session ID: 125 Serial number: 5
增加了合适的回滚段屏蔽,但是数据库还不能正常启动,而且依然报ORA-00704,决定对数据库启动过程做一个10046跟踪,来判断在哪一步出了问题
对数据库open过程做10046
SQL> conn / as sysdba Connected to an idle instance. SQL> startup pfile='/tmp/pfile' mount; ORACLE instance started. Total System Global Area 313860096 bytes Fixed Size 1344652 bytes Variable Size 218106740 bytes Database Buffers 88080384 bytes Redo Buffers 6328320 bytes Database mounted. SQL> oradebug setmypid Statement processed. SQL> oradebug EVENT 10046 TRACE NAME CONTEXT FOREVER, LEVEL 12 Statement processed. SQL> oradebug TRACEFILE_NAME /u01/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_16869.trc SQL> alter database open; alter database open * ERROR at line 1: ORA-01092: ORACLE instance terminated. Disconnection forced 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' Process ID: 16869 Session ID: 125 Serial number: 5 --trace中发现 PARSE ERROR #3063083528:len=60 dep=1 uid=0 oct=3 lid=0 tim=1342472283605146 err=604 SELECT NULL FROM PROPS$ WHERE NAME='BOOTSTRAP_UPGRADE_ERROR' 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' 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'
通过这里可以看出来很可能是在SELECT PROPS$表的时候,需要使用到回滚段,这里有两种可能需要使用回滚段(1.有数据未提交[提交事务],2.数据块scn过大[提交事务/推进scn]).对于这个问题,我尝试着修改回滚段状态来解决这个问题
修改回滚段状态
[oracle@xifenfei ~]$ bbed listfile=listfile password=blockedit mode=edit BBED: Release 2.0.0.0.0 - Limited Production on Tue Jul 17 09:10:01 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. ************* !!! For Oracle Internal Use only !!! *************** BBED> set file 1 block 225 FILE# 1 BLOCK# 225 BBED> map File: /u01/oracle/oradata/ora11g/system01.dbf (1) Block: 225 Dba:0x004000e1 ------------------------------------------------------------ KTB Data Block (Table/Cluster) struct kcbh, 20 bytes @0 struct ktbbh, 48 bytes @20 struct kdbh, 14 bytes @68 struct kdbt[1], 4 bytes @82 sb2 kdbr[21] @86 ub1 freespace[5357] @128 ub1 rowdata[2703] @5485 ub4 tailchk @8188 BBED> p *kdbr[1] rowdata[1393] ------------- ub1 rowdata[1393] @6878 0x2c BBED> x /rncnnnnn rowdata[1393] @6878 ------------- flag@6878: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@6879: 0x00 cols@6880: 17 col 0[2] @6881: 1 col 1[20] @6884: _SYSSMU1_3138885392$ col 2[2] @6905: 1 col 3[2] @6908: 3 col 4[3] @6911: 128 col 5[4] @6915: 822624 col 6[1] @6920: 0 col 7[3] @6922: 498 col 8[2] @6926: 94 col 9[1] @6929: 0 col 10[2] @6931: 3 col 11[2] @6934: 2 col 12[0] @6937: *NULL* col 13[0] @6938: *NULL* col 14[0] @6939: *NULL* col 15[0] @6940: *NULL* col 16[2] @6941: 2 BBED> m /x 02 offset 6933 File: /u01/oracle/oradata/ora11g/system01.dbf (1) Block: 225 Offsets: 6933 to 7444 Dba:0x004000e1 ------------------------------------------------------------------------ 0202c103 ffffffff 02c1032c 001102c1 03145f53 5953534d 55325f34 32323832 33383232 322402c1 0202c104 03c2022d 04c3531b 16018003 c2075303 c2031401 8002c102 02c103ff ffffff02 c1032c00 1102c104 145f5359 53534d55 335f3232 31303734 32363432 2402c102 02c10403 c2023d04 c3531b17 018003c2 074903c2 02290180 02c10202 c103ffff ffff02c1 032c0011 02c10514 5f535953 534d5534 5f313435 35333138 30303624 02c10202 c10403c2 024d04c3 4f4f5101 8003c205 4502c164 018002c1 0402c103 ffffffff 02c1032c 001102c1 06145f53 5953534d 55355f33 37383736 32323331 362402c1 0202c104 03c2025d 04c3531b 1c018003 c2071603 c2021701 8002c102 02c103ff ffffff02 c1032c00 1102c107 145f5359 53534d55 365f3234 36303234 38303639 2402c102 02c10403 c2030904 c3531b1d 018003c2 075a03c2 02130180 02c10202 c103ffff ffff02c1 032c0011 02c10814 5f535953 534d5537 5f313932 34383833 30333724 02c10202 c10403c2 031904c3 531b2201 8003c207 5a03c202 1d018002 c10202c1 03ffffff ff02c103 2c001102 c109135f 53595353 4d55385f 32373630 33383233 372402c1 0202c104 03c20329 04c34f2e 34018003 c2071703 c2024a01 8002c102 02c103ff ffffff02 c1032c00 1102c10a 145f5359 53534d55 395f3335 39333435 30363135 2402c102 02c10403 <32 bytes per line> …………类似方法修改其他值 BBED> sum apply Check value for File 1, Block 225: current = 0x4d51, required = 0x4d51
启动数据库并解决异常undo
SQL> conn / as sysdba Connected to an idle instance. SQL> startup pfile='/tmp/pfile' ORACLE instance started. Total System Global Area 313860096 bytes Fixed Size 1344652 bytes Variable Size 218106740 bytes Database Buffers 88080384 bytes Redo Buffers 6328320 bytes Database mounted. Database opened. SQL> drop tablespace undotbs1; drop tablespace undotbs1 * ERROR at line 1: ORA-01561: failed to remove all objects in the tablespace specified SQL> drop tablespace undotbs1 including contents; drop tablespace undotbs1 * ERROR at line 1: ORA-01561: failed to remove all objects in the tablespace specified SQL> select type# from seg$ where file#=3; TYPE# ---------- 10 10 10 10 10 10 10 10 10 10 10 rows selected. SQL> update seg$ set type#=3 where file#=3; 10 rows updated. SQL> commit; Commit complete. SQL> drop tablespace undotbs1 including contents; Tablespace dropped. SQL> create undo tablespace undotbs1 datafile '/u01/oracle/oradata/ora11g/undotbs01.dbf' size 10m; Tablespace created.
记录8.0.5数据库恢复过程
某银行需要恢复2004年磁带备份数据库 8.0.5,当时因为开发商使用begin backup命令进行热备,然后压缩到磁带上.在硬盘紧张,rman不成熟的时代,使用这样的方法备份本身没有大问题,可是因为没有备份归档日志,给现在的恢复带来了很多的问题.
尝试不完全恢复启动库
SVRMGR> startup pfile='init.ora' mount ORACLE instance started. Total System Global Area 141826208 bytes Fixed Size 47264 bytes Variable Size 124829696 bytes Database Buffers 16777216 bytes Redo Buffers 172032 bytes Database mounted. SVRMGR> recover database using backup controlfile until cancel; ORA-00279: change 613561556 generated at 08/21/04 22:42:48 needed for thread 1 ORA-00289: suggestion : /oracle/product/8.0.5/dbs/arch1_55329.dbf ORA-00280: change 613561556 for thread 1 is in sequence #55329 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} cancel Media recovery cancelled. SVRMGR> alter database open resetlogs; alter database open resetlogs * ORA-00600: internal error code, arguments: [4146], [31400], [31370], [], [], [], [], []
这个错误是因为回滚段corruption导致,客户已经没有了一致性要求,所以解决办法是通过一些手段找出回滚段并屏蔽
屏蔽回滚段重启库
SVRMGR> shutdown abort ORACLE instance shut down. SVRMGR> startup pfile='init.ora' mount ORACLE instance started. Total System Global Area 141826208 bytes Fixed Size 47264 bytes Variable Size 124829696 bytes Database Buffers 16777216 bytes Redo Buffers 172032 bytes Database mounted. SVRMGR> alter database open; alter database open * ORA-00600: internal error code, arguments: [3668], [1], [2], [55992], [55992], [4], [], []
根据ORA-00600[3668]错误的提示,因为重建控制文件,有一个数据文件因为在磁带恢复丢失,所以控制文件在上次重建的时候没有包含进去,根据经验在8.0中可以通过resetlogs解决
resetlogs重新打开数据库
SVRMGR> alter database open resetlogs; alter database open resetlogs * ORA-01139: RESETLOGS option only valid after an incomplete database recovery SVRMGR> recover datatabase using backup controlfile until cancel; ORA-00274: illegal recovery option DATATABASE SVRMGR> recover database using backup controlfile until cancel; ORA-00279: change 613561558 generated at 07/30/12 09:14:49 needed for thread 1 ORA-00289: suggestion : /oracle/product/8.0.5/dbs/arch1_1.dbf ORA-00280: change 613561558 for thread 1 is in sequence #1 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} cancel Media recovery cancelled. SVRMGR> alter database open resetlogs; alter database open resetlogs * ORA-00604: error occurred at recursive SQL level 1 ORA-01555: snapshot too old: rollback segment number with name "" too small
根据经验可能是屏蔽了undo或者undo损坏,然后有事务可能需要读undo,无法读到对应记录,可能出现此错误,因为无trace文件,尝试推进scn解决.当然这个问题可以通过open时做10046然后深入分析也许可以找到原因.
open数据库成功
根据上面的分析,重启库,推进scn,resetlogs库解决问题
SVRMGR> shutdown immediate ORA-01109: database not open Database dismounted. ORACLE instance shut down. SVRMGR> startup pfile='init.ora' mount; ORACLE instance started. Total System Global Area 141826208 bytes Fixed Size 47264 bytes Variable Size 124829696 bytes Database Buffers 16777216 bytes Redo Buffers 172032 bytes Database mounted. SVRMGR> alter database open ; alter database open * ORA-00600: internal error code, arguments: [3668], [1], [2], [55994], [55994], [4], [], [] SVRMGR> recover database using backup controlfile until cancel; ORA-00279: change 613561560 generated at 07/30/12 09:17:11 needed for thread 1 ORA-00289: suggestion : /oracle/product/8.0.5/dbs/arch1_1.dbf ORA-00280: change 613561560 for thread 1 is in sequence #1 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} cancel Media recovery cancelled. SVRMGR> alter database open resetlogs; Statement processed.
这次恢复比较幸运,在备份到磁带过程中被覆盖的一个同名的数据文件,因为是index,通过查询dba_extents,然后删除并重建相关index,s数据库算恢复完全.有些时候,对数据库多一份备份,可能成为最后的救命稻草,哪怕是一份不是十分完整的备份.再次重复:对dba而言,数据库备份重于一切