标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 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-600 kcratr_nab_less_than_odr 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 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,882)
- DB2 (22)
- MySQL (82)
- Oracle (1,707)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (661)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
分类目录归档:数据库
断电引起ORA-600 3005故障处理
异常断电之后,客户连接数据库报ORA-01033: ORACLE initialization or shutdown in progress错误,该错误一般是由于数据库没有正常open成功导致.

尝试人工启动数据库报ORA-600 3005错误

Tue Oct 27 19:02:59 2026 ALTER DATABASE RECOVER database Media Recovery Start started logmerger process Parallel Media Recovery started with 16 slaves Tue Oct 27 19:03:00 2026 Recovery of Online Redo Log: Thread 1 Group 3 Seq 111990 Reading mem 0 Mem# 0: D:\orcl\REDO03.LOG Completed: ALTER DATABASE RECOVER database Tue Oct 27 19:03:22 2026 alter database open Beginning crash recovery of 1 threads parallel recovery started with 15 processes Started redo scan Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_1908.trc (incident=917810): ORA-00600: 内部错误代码, 参数: [3005], [1], [111991], [39659], [0], [0], [], [], [], [], [], [] Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_917810\orcl_ora_1908_i917810.trc Aborting crash recovery due to error 600 Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_1908.trc: ORA-00600: 内部错误代码, 参数: [3005], [1], [111991], [39659], [0], [0], [], [], [], [], [], [] Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_1908.trc: ORA-00600: 内部错误代码, 参数: [3005], [1], [111991], [39659], [0], [0], [], [], [], [], [], [] ORA-600 signalled during: alter database open...
这个错误是一个较为常见的错误,由于redo日志或者thread信息丢失导致.检查数据文件头状态一致而且干净
SQL> set pages 10000 SQL> set numw 16 SQL> SELECT status, 2 checkpoint_change#, 3 to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') checkpoint_time, 4 last_change#, 5 count(*) ROW_NUM 6 FROM v$datafile 7 GROUP BY status, checkpoint_change#, checkpoint_time,last_change# 8 ORDER BY status, checkpoint_change#, checkpoint_time; STATUS CHECKPOINT_CHANGE# CHECKPOINT_TIME LAST_CHANGE# ROW_NUM ------- ------------------ ------------------- ---------------- ---------------- RECOVER 27917313690 2026-10-27 14:51:31 14 SYSTEM 27917313690 2026-10-27 14:51:31 3 SQL> SQL> SQL> set numw 16 SQL> col CHECKPOINT_TIME for a40 SQL> set lines 150 SQL> set pages 1000 SQL> SELECT status, 2 to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') checkpoint_time,FUZZY,checkpoint_change#, 3 count(*) ROW_NUM 4 FROM v$datafile_header 5 GROUP BY status, checkpoint_change#, to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss'),fuzzy 6 ORDER BY status, checkpoint_change#, checkpoint_time; STATUS CHECKPOINT_TIME FUZ CHECKPOINT_CHANGE# ROW_NUM ------- ---------------------------------------- --- ------------------ ---------------- ONLINE 2026-10-27 14:51:31 NO 27917313690 17
基于这种情况,直接可以打开数据库,检测字典一致,基本上可以实现0丢失
SQL> alter database open resetlogs;
数据库已更改。
SQL> @D:/HCHECK
HCheck Version 07MAY18 on 28-10月-2026 12:20:10
----------------------------------------------
Catalog Version 11.2.0.1.0 (1102000100)
db_name: ORCL
Catalog Fixed
Procedure Name Version Vs Release Timestamp
Result
------------------------------ ... ---------- -- ---------- --------------
------
.- LobNotInObj ... 1102000100 <= *All Rel* 10/28 12:20:11 PASS
.- MissingOIDOnObjCol ... 1102000100 <= *All Rel* 10/28 12:20:11 PASS
.- SourceNotInObj ... 1102000100 <= *All Rel* 10/28 12:20:11 PASS
.- IndIndparMismatch ... 1102000100 <= 1102000100 10/28 12:20:12 PASS
.- InvCorrAudit ... 1102000100 <= 1102000100 10/28 12:20:12 PASS
.- OversizedFiles ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- PoorDefaultStorage ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- PoorStorage ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- PartSubPartMismatch ... 1102000100 <= 1102000100 10/28 12:20:12 PASS
.- TabPartCountMismatch ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- OrphanedTabComPart ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- MissingSum$ ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- MissingDir$ ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- DuplicateDataobj ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- ObjSynMissing ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- ObjSeqMissing ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- OrphanedUndo ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- OrphanedIndex ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- OrphanedIndexPartition ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- OrphanedIndexSubPartition ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- OrphanedTable ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- OrphanedTablePartition ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- OrphanedTableSubPartition ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- MissingPartCol ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- OrphanedSeg$ ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- OrphanedIndPartObj# ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- DuplicateBlockUse ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- FetUet ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- Uet0Check ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- ExtentlessSeg ... 1102000100 <= 1102000100 10/28 12:20:12 PASS
.- SeglessUET ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- BadInd$ ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- BadTab$ ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- BadIcolDepCnt ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- ObjIndDobj ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- TrgAfterUpgrade ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- ObjType0 ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- BadOwner ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- StmtAuditOnCommit ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- BadPublicObjects ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- BadSegFreelist ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- BadDepends ... 1102000100 <= *All Rel* 10/28 12:20:12 PASS
.- CheckDual ... 1102000100 <= *All Rel* 10/28 12:20:13 PASS
.- ObjectNames ... 1102000100 <= *All Rel* 10/28 12:20:13 PASS
.- BadCboHiLo ... 1102000100 <= *All Rel* 10/28 12:20:13 PASS
.- ChkIotTs ... 1102000100 <= *All Rel* 10/28 12:20:13 PASS
.- NoSegmentIndex ... 1102000100 <= *All Rel* 10/28 12:20:13 PASS
.- BadNextObject ... 1102000100 <= *All Rel* 10/28 12:20:13 PASS
.- DroppedROTS ... 1102000100 <= *All Rel* 10/28 12:20:13 PASS
.- FilBlkZero ... 1102000100 <= *All Rel* 10/28 12:20:13 PASS
.- DbmsSchemaCopy ... 1102000100 <= *All Rel* 10/28 12:20:13 PASS
.- OrphanedObjError ... 1102000100 > 1102000000 10/28 12:20:13 PASS
.- ObjNotLob ... 1102000100 <= *All Rel* 10/28 12:20:13 PASS
.- MaxControlfSeq ... 1102000100 <= *All Rel* 10/28 12:20:13 PASS
.- SegNotInDeferredStg ... 1102000100 > 1102000000 10/28 12:20:14 PASS
.- SystemNotRfile1 ... 1102000100 > 902000000 10/28 12:20:14 PASS
.- DictOwnNonDefaultSYSTEM ... 1102000100 <= *All Rel* 10/28 12:20:14 PASS
.- OrphanTrigger ... 1102000100 <= *All Rel* 10/28 12:20:14 PASS
.- ObjNotTrigger ... 1102000100 <= *All Rel* 10/28 12:20:14 PASS
---------------------------------------
28-10月-2026 12:20:14 Elapsed: 4 secs
---------------------------------------
Found 0 potential problem(s) and 0 warning(s)
PL/SQL 过程已成功完成。
基于当前情况,客户可以直接使用当前库,实现最小损失,最快速度恢复.
记录一次云存储资源到期之后引起的数据库恢复
客户环境是运行在xx厂商上的云环境的Oracle RAC,由于其中一块asm disk资源到期没有进行续费,云厂商对该盘进行了限速(1MB/s,并且异步写入),导致运行在该rac上的数据库直接crash,客户续费之后磁盘速度恢复正常但是数据库启动报ORA-00353 ORA-00312错误(redo异常),客户找了以前的服务商进行恢复尝试没有成功.对接手后的现场进行检测,发现有20个数据文件被初始化(dbv检测全部是空块,没有写入任何表和索引数据)[直接变成了空文件,一般sqlplus中执行alter database create datafile或者在没有对应的数据文件备份的情况下执行restore datafile会出现这个情况],数据库被强制拉库,但是启动没有成功报ORA-00704 ORA-01555错误.由于客户明天领导会过来检查,所以着急启动系统,我们只能基于现在的现况给客户强制拉起来库,赌运气看看核心业务是否可以跑起来
回溯处理过程,续费欠费资源之后,数据库启动报错(估计是当时限速之后,云存储层面异步写入导致部分写丢失)
Mon Oct 26 11:38:19 2026 alter database open This instance was first to open Beginning crash recovery of 1 threads parallel recovery started with 15 processes Started redo scan Incomplete read from log member '+DATA/xff/onlinelog/group_3.312.1210628353'. Trying next member. Incomplete read from log member '+DATA/xff/onlinelog/group_3.312.1210628353'. Trying next member. Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_ora_19144.trc (incident=682004): ORA-00353: log corruption near block 47146 change 16921129940671 time 10/26/2026 08:57:37 ORA-00312: online log 3 thread 1: '+DATA/xff/onlinelog/group_3.312.1210628353' Incident details in: /oracle/diag/rdbms/xff/xff1/incident/incdir_682004/xff1_ora_19144_i682004.trc Abort recovery for domain 0 Aborting crash recovery due to error 368 Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_ora_19144.trc: ORA-00368: checksum error in redo log block ORA-00353: log corruption near block 47146 change 16921129940671 time 10/26/2026 08:57:37 ORA-00312: online log 3 thread 1: '+DATA/xff/onlinelog/group_3.312.1210628353' Abort recovery for domain 0 Mon Oct 26 11:38:22 2026 Sweep [inc][682004]: completed Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_ora_19144.trc: ORA-00368: checksum error in redo log block ORA-00353: log corruption near block 47146 change 16921129940671 time 10/26/2026 08:57:37 ORA-00312: online log 3 thread 1: '+DATA/xff/onlinelog/group_3.312.1210628353' ORA-368 signalled during: alter database open...
屏蔽一致性,强制resetlogs的时候报ORA-00704 ORA-01555错误
Mon Oct 26 15:47:43 2026 Setting recovery target incarnation to 2 Initializing SCN for created control file Database SCN compatibility initialized to 3 Warning - High Database SCN: Current SCN value is 16917769616373, threshold SCN value is 0 Mon Oct 26 15:47:43 2026 Assigning activation ID 2556751686 (0x9864ef46) LGWR: STARTING ARCH PROCESSES Mon Oct 26 15:47:43 2026 ARC0 started with pid=32, OS id=14392 ARC0: Archival started LGWR: STARTING ARCH PROCESSES COMPLETE ARC0: STARTING ARCH PROCESSES Mon Oct 26 15:47:44 2026 ARC1 started with pid=33, OS id=14446 Mon Oct 26 15:47:44 2026 ARC2 started with pid=34, OS id=14448 Mon Oct 26 15:47:44 2026 ARC3 started with pid=35, OS id=14450 ARC1: Archival started ARC2: Archival started ARC1: Becoming the 'no FAL' ARCH ARC1: Becoming the 'no SRL' ARCH ARC2: Becoming the heartbeat ARCH Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: +DATA/xff/onlinelog/group_1.314.1210628351 Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Mon Oct 26 15:47:44 2026 SMON: enabling cache recovery ORA-01555 caused by SQL statement below (SQL ID: 7bd391hat42zk, SCN: 0x0f62.f9a5fbf8): select /*+ rule */ name,file#,block#,status$,user#,undosqn,xactsqn,scnbas,scnwrp, DECODE(inst#,0,NULL,inst#),ts#,spare1 from undo$ where us#=:1 Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_ora_13439.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 2 ORA-01555: snapshot too old: rollback segment number 0 with name "SYSTEM" too small Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_ora_13439.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00604: error occurred at recursive SQL level 2 ORA-01555: snapshot too old: rollback segment number 0 with name "SYSTEM" too small Error 704 happened during db open, shutting down database USER (ospid: 13439): terminating the instance due to error 704 Instance terminated by USER, pid = 13439 ORA-1092 signalled during: ALTER DATABASE OPEN RESETLOGS... opiodr aborting process unknown ospid (13439) as a result of ORA-1092
从这个时候开始我接手这个故障,数据完全恢复已经不太可能,只能基于现在的情况,给客户尝试拉起来库,看看核心业务是否可以跑起来.
数据库open过程报ORA-01555错误,这个是一个比较常见的问题,以前专门写过类似文章:
在数据库open过程中常遇到ORA-01555汇总
数据库open过程遭遇ORA-1555对应sql语句补充
对于这个客户问题,我也一样尝试修改scn的方式来解决
SQL> set numw 16 col CHECKPOINT_TIME for a40 set lines 150 set pages 1000 SELECT status, to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') checkpoint_time,FUZZY,checkpoint_change#, count(*) ROW_NUM FROM v$datafile_header GROUP BY status, checkpoint_change#, to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss'),fuzzy ORDER BY status, checkpoint_change#, checkpoint_time;SQL> SQL> SQL> SQL> 2 3 4 5 6 STATUS CHECKPOINT_TIME FUZ CHECKPOINT_CHANGE# ROW_NUM ------- ---------------------------------------- --- ------------------ ---------------- ONLINE 2026-10-26 15:47:44 YES 16917769616374 191
使用obet的patch_scn功能来修改数据库scn(obet的patch_scn功能)
OBET> patch_scn 89103 0x06001AE70 0xF62FBA5FBF6 === Oracle SCN Patch === PID: 89103 Address: 0x06001AE70 New Value: 0xF62FBA5FBF6 (16917803170806) Original SCN: 0x0 Are you sure you want to modify Oracle SCN? (yes/no): y SCN modified: 0x0 -> 0xF62FBA5FBF6 Oracle SCN successfully modified. SQL> oradebug DUMPvar SGA kcsgscn_ kcslf kcsgscn_ [06001AE70, 06001AEA0) = FBA5FBF6 00000F62 00000000 00000000 00000000
然后尝试打开数据库依旧报ORA-01555错误,证明我们处理的scn不正确
SQL> recover database using backup controlfile;
ORA-00279: change 16917769616374 generated at 10/26/2026 15:47:44 needed for
thread 1
ORA-00289: suggestion : +ARCH
ORA-00280: change 16917769616374 for thread 1 is in sequence #1
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
+DATA/xff/onlinelog/group_1.314.1210628351
Log applied.
Media recovery complete.
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 2
ORA-01555: snapshot too old: rollback segment number 0 with name "SYSTEM" too small
Process ID: 18169
Session ID: 3681 Serial number: 2825
分析异常block的scn
*** 2026-10-27 01:05:42.156
Start dump data block from file +DATA/xff/system01.dbf minblk 558 maxblk 558
V10 STYLE FILE HEADER:
Compatibility Vsn = 186647552=0xb200400
Db ID=2195614447=0x82de6aef, Db Name='xff'
Activation ID=0=0x0
Control Seq=542=0x21e, File size=446720=0x6d100
File Number=1, Blksiz=8192, File Type=3 DATA
Dump all the blocks in range:
buffer tsn: 0 rdba: 0x0040022e (1/558)
scn: 0x0f63.c1efd2ab seq: 0x01 flg: 0x04 tail: 0xd2ab0201
frmt: 0x02 chkval: 0x75a3 type: 0x02=KTU UNDO BLOCK
Hex dump of block: st=0, typ_found=1
发现该block的scn非常大0x0f63.c1efd2ab,我之前处理的scn明显不合适,继续换上新的scn,再次打开数据库成功
OBET> patch_scn 89103 0x06001AE70 0xF64C1EFD2AB === Oracle SCN Patch === PID: 89103 Address: 0x06001AE70 New Value: 0xF64C1EFD2AB(16925424865963) Original SCN: 0x0 Are you sure you want to modify Oracle SCN? (yes/no): y SCN modified: 0x0 -> 0xF64C1EFD2AB Oracle SCN successfully modified. SQL> oradebug DUMPvar SGA kcsgscn_ kcslf kcsgscn_ [06001AE70, 06001AEA0) = C1EFD2AB 00000F64 00000000 00000000 00000000 SQL> SQL> SQL> SQL> alter database open; Database altered.
后续大量异常undo问题
ORA-00376: file 182 cannot be read at this time ORA-01111: name for data file 182 is unknown - rename to correct file ORA-01110: data file 182: '/oracle/product/11.2.0/db_1/dbs/MISSING00182' ORACLE Instance xff1 (pid = 20) - Error 1578 encountered while recovering transaction (21, 29) on object 99404. Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_smon_29435.trc: ORA-01578: ORACLE data block corrupted (file # 8, block # 1471227) ORA-01110: data file 8: '+DATA/xff/users04.dbf' ORACLE Instance xff1 (pid = 20) - Error 376 encountered while recovering transaction (2, 27) on object 599926. Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_smon_29435.trc: ORA-00376: file 211 cannot be read at this time ORA-01111: name for data file 211 is unknown - rename to correct file ORA-01110: data file 211: '/oracle/product/11.2.0/db_1/dbs/MISSING00211' ORACLE Instance xff1 (pid = 20) - Error 376 encountered while recovering transaction (10, 6) on object 99591. Errors in file /oracle/diag/rdbms/xff/xff1/trace/xff1_smon_29435.trc: ORA-00376: file 182 cannot be read at this time ORA-01111: name for data file 182 is unknown - rename to correct file ORA-01110: data file 182: '/oracle/product/11.2.0/db_1/dbs/MISSING0018
由于这些文件已经被初始化掉了,恢复已经没有意义,直接没有加入到ctl中,现在主要是由于有些事务涉及这些文件,导致smon回滚的时候报这些错误,对于这样的异常,直接对于undo进行重建更换新undo即可.处理好这些问题之后,数据库open运行问题,客户自行安排业务测试和论证
Firebird 损坏数据库数据抢救工具—firebirdext
它是做什么的
firebirdext 是一个针对 Firebird 数据库 .fdb 文件的数据抢救工具。
当数据库文件因为断电、磁盘坏道、误操作、备份中断、病毒查杀等原因损坏,导致数据库无法打开、官方工具 gbak/gfix 也救不回来时,fbrescue 可以绕过数据库引擎,直接以二进制方式解析磁盘文件,把还能找回的数据一页一页”捞”出来——导出成 CSV、SQL 脚本,甚至直接重建一个可用的新数据库。
一句话:引擎打不开的库,它照样能把数据掏出来。
解决什么问题
你可能会遇到这些情况:

工具的信条是宁缺毋滥:损坏到无法确认的行,如实计入”失败”,绝不编造半真半假的数据出来。
核心功能
1. 全景扫描(scan) — 动手之前先看病情
输出每页的类型与归属(哪些表还剩多少数据页、哪些页被毁),立刻知道”还有多少可救”。
firebirdext scan 损坏库.FDB
2. 零配置数据提取 — 不用提供表结构
自动建库、建表、写入数据,产出一个可以正常连接使用的 Firebird 数据库。
firebirdext extract 损坏库.FDB --format db --target 新库.FDB
3. 直接重建新库 — 数据一步到位
自动建库、建表、写入数据,产出一个可以正常连接使用的 Firebird 数据库。
firebirdext extract 损坏库.FDB --format db --target 新库.FDB
4. 对象结构恢复 — 不只救数据,结构也不丢
恢复索引、主键、视图、存储过程、触发器、序列,在数据恢复好的新库上执行一遍,对象全部重建。
5. 单表定向抢救
firebirdext extract 损坏库.FDB --table ORDERS --format db --target 订单.FDB
6. 三种输出格式:csv(Excel 核对)/ sql(INSERT 脚本)/ db(新数据库)。
支持的数据类型
整数、BIGINT、SMALLINT、NUMERIC/DECIMAL(p,s)、FLOAT、DOUBLE、DATE、TIMESTAMP、VARCHAR/CHAR(多字节字符集支持)、BLOB(自动重组内联大对象,实测 4000 字符文本完整还原)
上手:三分钟走完全流程
# 环境:Windows/Linux 均可,Python 3.8+,无需安装任何第三方库 # (只有"直接建新库"功能会调用 Firebird 自带的 isql.exe) # 第 1 步:复制副本(永远不要对原文件操作) copy D:\prod\MYDATA.FDB E:\work\抢救副本.FDB # 第 2 步:诊断,看看能救多少 firebirdext scan E:\work\抢救副本.FDB # 第 3 步:抢救 → 新库 + 对象脚本,一条命令 firebirdext extract E:\work\抢救副本.FDB --format db --target E:\work\恢复库.FDB # 第 4 步:把索引/视图/过程/触发器也建起来 isql -q -b -i E:\work\恢复库_ddl.sql # 第 5 步:连上新库验证数据 isql -q SQL> connect 'E:/work/恢复库.FDB' user 'SYSDBA' password '***'; SQL> select count(*) from 任意表;
适用范围与限制
1).适用 Firebird 3 / 4 / 5(ODS12/13);更老的 2.5 及以前版本需要小幅适配
2).已被物理覆写清零的记录、已被垃圾回收的数据,任何工具都救不回
3).表结构(列类型)依赖文件内的系统表页;如果系统表页也烂光了,可以用 –ddl 手动提供建表语句兜底
4).view、index、trigger等如果字典完善可以恢复
5).外键、CHECK 约束暂无法恢复,后续进行完善

加我微信(17813235971)
加我QQ(107644445)

