通过obet 恢复system坏块,打开数据库

Posted on 2026 年 08 月 22 日 by 惜分飞

客户由于误操作直接在虚拟化平台点击电源键,强制关闭了正在运行的数据库服务器虚机,导致数据库无法正常启动,检查发现ntfs文件系统损坏

通过obet工具检测数据文件坏块(obet dbv功能完整说明),发现核心的system文件上面有一些坏块

File #1: D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF (225281 blocks) - Started: 2026-08-21 16:40:23
File #1: rfile=1 (0x00000001)  header_block_num=225280 (0x00037000)  filesize_status:OK
file 1, block 212238: tailchk error (expected 0x0106276F, got 0x01065E92), bad block
file 1, block 213507: tailchk error (expected 0x0106276F, got 0x01065E92), bad block
file 1, block 213515: tailchk error (expected 0x01065E92, got 0x0106276F), bad block
file 1, block 213547: tailchk error (expected 0x0106276F, got 0x01065E92), bad block
file 1, block 213555: tailchk error (expected 0x01065E92, got 0x0106276F), bad block
file 1, block 221387: tailchk error (expected 0x0106276F, got 0x01065E92), bad block
file 1, block 221403: tailchk error (expected 0x01065E92, got 0x0106B19C), bad block
file 1, block 221419: tailchk error (expected 0x01065E92, got 0x0106C7E3), bad block
file 1, block 222117: tailchk error (expected 0x01065E92, got 0x0106276F), bad block
file 1, block 222133: tailchk error (expected 0x0106276F, got 0x01065E92), bad block
file 1, block 222141: tailchk error (expected 0x01065E92, got 0x0106276F), bad block
file 1, block 222173: tailchk error (expected 0x0106C7E3, got 0x01065E92), bad block
  File #1 completed: 0 all zero, 0 soft corrupted, 12 tailchk error, 0 checksum error, 0 rdba error

这个12个坏块的数量和dbv检测结果一致


DBVERIFY: Release 19.0.0.0.0 - Production on 星期五 8月 21 17:37:02 2026

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.


DBVERIFY - 开始验证: FILE = D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF
页 212238 流入 - 很可能是介质损坏
Corrupt block relative dba: 0x00433d0e (file 1, block 212238)
Fractured block found during dbv: 
Data in bad block:
 type: 6 format: 2 rdba: 0x00433d0e
 last change scn: 0x0000.0002.d71a6f27 seq: 0x1 flg: 0x06
 spare3: 0x0
 consistency value in tail: 0x925e0601
 check value in block header: 0x93bb
 computed block checksum: 0xfd79

…………

页 222173 流入 - 很可能是介质损坏
Corrupt block relative dba: 0x004363dd (file 1, block 222173)
Fractured block found during dbv: 
Data in bad block:
 type: 6 format: 2 rdba: 0x004363dd
 last change scn: 0x0000.0002.d708e3c7 seq: 0x1 flg: 0x06
 spare3: 0x0
 consistency value in tail: 0x925e0601
 check value in block header: 0xe089
 computed block checksum: 0x7199


DBVERIFY - 验证完成

检查的页总数: 225280
处理的页总数 (数据): 125451
失败的页总数 (数据): 0
处理的页总数 (索引): 29984
失败的页总数 (索引): 0
处理的页总数 (其他): 48214
处理的总页数 (段)  : 1
失败的总页数 (段)  : 0
空的页总数: 21619
标记为损坏的总页数: 12
流入的页总数: 12
加密的总页数        : 0
最高块 SCN            : 12199365950 (2.3609431358)

使用obet的reair block功能进行修复(obet repair block使用说明)

OBET> set file 1
filename set to: D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF (file#1)

OBET> set block 212238
block set to: 212238

OBET> d

File: D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF
Block: 212238                Offsets:     0 to    31
--------------------------------------------------------------------------------
67A1C000 06A20000 0E3D4300 276F1AD7 02000106 BB930000 02000000 D0020000 E46E1AD7

<32 bytes read>

OBET> tailchk
Check tailchk for File D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF, Block 212238:
current = 0x925E0601, required = 0x6F270601

OBET> backup
Backing up file #1, block 212238
Successfully backed up block 212238 from D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF 
   to backup_blk\SYSTEM01.DBF.212238_20260821173825.blk

OBET> set mode edit
mode set to: edit

OBET> repair
Usage: repair [subcommand]
  repair block [file N] [X]  - Repair tailchk/checksum (optional: file N, block X)
  repair blkscn [file N] [X] - Repair block SCN (optional: file N, block X)

OBET> repair block
Warning: Missing value for 'block', using global setting: 212238

Repairing block 212238 in file D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF...

Repair analysis for block 212238:
1. seq_kcbh check: 0x01 -> OK
2. Tailchk check: 0x925E0601 -> needs repair (0x6F270601)
3. Checksum check: 0xBB93 -> OK

Confirm repair operations:
File: D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF
Block: 212238
Operations needed: fix tailchk
Confirm? (Y/YES to proceed): y

Verification after repair:
1. seq_kcbh: 0x01 OK
2. Tailchk: 0x6F270601 OK
3. Checksum: 0xBB93 OK

Block 212238 repair completed successfully.

所有坏块依次进行修复,然后再次使用dbv检测


DBVERIFY: Release 19.0.0.0.0 - Production on 星期五 8月 21 17:42:02 2026

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.


DBVERIFY - 开始验证: FILE = D:\APP\ADMINISTRATOR\ORADATA\NHIS\SYSTEM01.DBF
Block Checking: DBA = 4407811, Block Type = KTB-managed data block
**** actual rows locked by itl 2  = 0 != # in trans. header = 1
**** actual rows locked by itl 3  = 0 != # in trans. header = 1
---- end index block validation
页 213507 失败, 校验代码为 6401
Block Checking: DBA = 4407819, Block Type = KTB-managed data block
**** row 120: key out of order
**** actual rows locked by itl 2  = 0 != # in trans. header = 1
**** actual rows marked deleted = 1 != kdxlende = 0
---- end index block validation
页 213515 失败, 校验代码为 6401

DBVERIFY - 验证完成

检查的页总数: 225280
处理的页总数 (数据): 125451
失败的页总数 (数据): 0
处理的页总数 (索引): 29996
失败的页总数 (索引): 2
处理的页总数 (其他): 48214
处理的总页数 (段)  : 1
失败的总页数 (段)  : 0
空的页总数: 21619
标记为损坏的总页数: 0
流入的页总数: 0
加密的总页数        : 0
最高块 SCN            : 12199365950 (2.3609431358)

有两个block有少量逻辑错误,可以通过数据库级别设置进行跳过,基本上实现了这个12个坏块的自动修复.后续就是数据库的打开过程

SQL> startup mount pfile='d:/pfile.txt'
ORACLE 例程已经启动。

Total System Global Area 1.2885E+10 bytes
Fixed Size                 16120656 bytes
Variable Size            7751073792 bytes
Database Buffers         5100273664 bytes
Redo Buffers               17432576 bytes
数据库装载完毕。
SQL> recover database;
ORA-00283: 恢复会话因错误而取消
ORA-00742: 日志读取在线程 1 序列 19828 块 11511 中检测到写入丢失情况
ORA-00312: 联机日志 2 线程 1: 'D:\APP\ADMINISTRATOR\ORADATA\NHIS\REDO02.LOG'

SQL> RECOVER DATABASE UNTIL TIME '2026-08-21:13:28:56' USING BACKUP CONTROLFILE;
ORA-00279: change 12198905983 generated at 08/21/2026 12:43:18 needed for
thread 1
ORA-00289: suggestion :
D:\APP\ADMINISTRATOR\PRODUCT\19.0.0\DBHOME_1\RDBMS\ARC0000019827_1199133733.0001
ORA-00280: change 12198905983 for thread 1 is in sequence #19827


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
D:\APP\ADMINISTRATOR\ORADATA\NHIS\REDO01.LOG
ORA-00279: change 12199301614 generated at 08/21/2026 13:27:06 needed for
thread 1
ORA-00289: suggestion :
D:\APP\ADMINISTRATOR\PRODUCT\19.0.0\DBHOME_1\RDBMS\ARC0000019828_1199133733.0001
ORA-00280: change 12199301614 for thread 1 is in sequence #19828
ORA-00278: log file 'D:\APP\ADMINISTRATOR\ORADATA\NHIS\REDO01.LOG' no longer
needed for this recovery


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
D:\APP\ADMINISTRATOR\ORADATA\NHIS\REDO02.LOG
ORA-00756: 鎭㈠鎿嶄綔妫€娴嬪埌鏁版嵁鍧楀啓鍏ヤ涪澶?ORA-10567:
Redo is inconsistent with data block (file# 4, block# 31663, file offset is 259383296 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: 鏁版嵁鏂囦欢 4: 'D:\APP\ADMINISTRATOR\ORADATA\NHIS\UNDOTBS01.DBF'
ORA-10560: block type 'KTU UNDO BLOCK'

ORA-01112: media recovery not started

SQL> alter database open resetlogs;

Database altered.

使用expdp导出数据,完成本次恢复任务

分享一例运行在aix上的sap系统数据库恢复过程

Posted on 2026 年 08 月 14 日 by 惜分飞

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：分享一例运行在aix上的sap系统数据库恢复过程

情况描述
客户sap系统运行在aix系统,ibm v7000存储上,数据存放在三个1T的lun组成的vg的多个lv中.异常断电之后,但是给数据库使用的三个lun丢失了2个,从而使得所有vg/lv异常,通过硬件恢复出来异常的2个lun和剩余的1个lun一起,把所有的数据文件恢复出来.但是由于某种原因,出现部分block被覆盖(其中还包括两个文件头损坏).

坏块检测
对于恢复的所有文件,为了快速做一遍坏块检查,直接在恢复的win机器上使用过obet做了一次dbv检查obet实现对数据文件坏块检测功能(使用obet的dbv检查有几个好处:1>可以在win上面检测aix的数据文件;2>可以检测数据文件头损坏的数据文件其他block;3>检测速度比原生dbv快[每个文件内部加了并行检测]),检测结果如下

--其中两个文件头损坏
File #62: E:\sr3_54\sr3.data54 (1280000 blocks) - Started: 2026-07-28 23:57:53
File #62: rfile=0 (0x00000000)  header_block_num=0 (0x00000000)  filesize_status:NO
file 62, block 0: block all zero
file 62, block 1: block all zero

File #84: E:\sr3_76\sr3.data76 (4185601 blocks) - Started: 2026-07-29 00:55:32
File #84: rfile=638937491 (0x26156993)  header_block_num=77152556 (0x0499412C)  filesize_status:NO
file 84, block 1: rdba error (expected 1, got 69760), bad block
file 84, block 2: rdba error (expected 2, got 589836), bad block

--坏块汇总
DBV completed at: 2026-07-29 00:58:10
===============================================
DBV Summary:
Total blocks checked: 196287237
Total all zero blocks found: 337417
Total all rdba error blocks found: 1062468
Total all tailchk error blocks found: 1
Total all soft corrupted blocks found: 0
Total all checksum error blocks found: 0
Total bad blocks found: 1399886
Execution time: 10507.00 seconds
===============================================

这个统计下来好的block在99.3%左右,证明硬件层面的会效果已经非常好.

碎片工具进一步恢复
恢复公司文件系统层面恢复有数据块遗漏的可能,通过碎片工具(OraScan(Oracle 碎片扫描工具) 使用说明)进一步扫描

通过确认62号文件还有少量block可以进一步恢复（也就是说碎片扫描到的62号文件的block多于硬件公司恢复出来的62号文件里面好的block数量）,通过obet的merge功能进行填补

基于上述操作,对于lun里面的数据文件实现了最大效果恢复.

数据库恢复操作
1. 上次恢复文件到aix,offline掉异常文件头数据文件打开数据库

sapprd2:oraprd 8> sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Mon Aug 3 18:41:28 2026

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select status from v$instance;

STATUS
------------------------------------
STARTED

SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-00214: control file '/oracle/PRD/origlogA/cntrl/cntrlPRD.dbf' version
9742943 inconsistent with file '/oracle/PRD/sapdata1/cntrl/cntrlPRD.dbf'
version 9742931

解决ctl不一致问题之后继续mount库恢复

sapprd2:oraprd 11> sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Mon Aug 3 18:42:53 2026

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter database mount;

Database altered.

SQL> alter database datafile 62,84 offline;

Database altered.

SQL> recover database ;
Media recovery complete.
SQL> alter database open;

Database altered.

2.对于两个损坏的数据文件头进行修复
由于现在aix环境的客户比较少,obet没有在aix环境下进行编译,因此直接使用bbed工具进行文件头修复（列举了主要操作过程）

BBED> copy file 83 block 1 to file 84 block 1
 File: /oracle/PRD/sapdata3/sr3_76/sr3.data76 (84)
 Block: 1                Offsets:    0 to   31           Dba:0x15000001
------------------------------------------------------------------------
 0ba20000 14c00001 00000000 00000104 22250000 00000000 0b200000 72bc991d

 <32 bytes per line>

BBED> set offset 368
        OFFSET          368

BBED> d
 File: /oracle/PRD/sapdata3/sr3_76/sr3.data76 (84)
 Block: 1                Offsets:  368 to  399           Dba:0x15000001
------------------------------------------------------------------------
 00000053 00000000 00000000 495dc097 00000000 00000000 00000000 00000000

 <32 bytes per line>

BBED> m /x 00000054
 File: /oracle/PRD/sapdata3/sr3_76/sr3.data76 (84)
 Block: 1                Offsets:  368 to  399           Dba:0x15000001
------------------------------------------------------------------------
 00000054 00000000 00000000 495dc097 00000000 00000000 00000000 00000000

 <32 bytes per line>

BBED> set offset 52
        OFFSET          52

BBED> d
 File: /oracle/PRD/sapdata3/sr3_76/sr3.data76 (84)
 Block: 1                Offsets:   52 to   83           Dba:0x15000001
------------------------------------------------------------------------
 00530003 00000000 00000000 00000000 00000000 00000000 00000000 00000000

 <32 bytes per line>

BBED> m /x 0054
 File: /oracle/PRD/sapdata3/sr3_76/sr3.data76 (84)
 Block: 1                Offsets:   52 to   83           Dba:0x15000001
------------------------------------------------------------------------
 00540003 00000000 00000000 00000000 00000000 00000000 00000000 00000000

 <32 bytes per line>

BBED> set offset 4
        OFFSET          4

BBED> d
 File: /oracle/PRD/sapdata3/sr3_76/sr3.data76 (84)
 Block: 1                Offsets:    4 to   35           Dba:0x15000001
------------------------------------------------------------------------
 14c00001 00000000 00000104 22250000 00000000 0b200000 72bc991d 50524400

 <32 bytes per line>

BBED> m /x 15000001
 File: /oracle/PRD/sapdata3/sr3_76/sr3.data76 (84)
 Block: 1                Offsets:    4 to   35           Dba:0x15000001
------------------------------------------------------------------------
 15000001 00000000 00000104 22250000 00000000 0b200000 72bc991d 50524400

 <32 bytes per line>


BBED> m /x E1B0
Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y
 File: /oracle/PRD/sapdata3/sr3_76/sr3.data76 (84)
 Block: 1                Offsets:  100 to  611           Dba:0x15000001
------------------------------------------------------------------------
 e1b0853f 00040000 4083fcfe 33606b63 02502452 0000ca28 49680fb3 93b9f6b9

 <32 bytes per line>

BBED> set offset +2
        OFFSET          102

BBED> m /x 8542
 File: /oracle/PRD/sapdata3/sr3_76/sr3.data76 (84)
 Block: 1                Offsets:  102 to  613           Dba:0x15000001
------------------------------------------------------------------------
 85420004 00004083 fcfe3360 6b630250 24520000 ca284968 0fb393b9 f6b90005

 <32 bytes per line>


BBED> sum
Check value for File 84, Block 1:
current = 0x2225, required = 0x23e5

BBED> sum apply
Check value for File 84, Block 1:
current = 0x23e5, required = 0x23e5

BBED> verify
DBVERIFY - Verification starting
FILE = /oracle/PRD/sapdata3/sr3_76/sr3.data76
BLOCK = 1


DBVERIFY - Verification complete

Total Blocks Examined         : 1
Total Blocks Processed (Data) : 0
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 0
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0
Message 531 not found;  product=RDBMS; facility=BBED

修改完成之后,还出现过几个错误

SQL> alter database open ;
alter database open
*
ERROR at line 1:
ORA-01122: database file 62 failed verification check
ORA-01110: data file 62: '/oracle/PRD/sapdata2/sr3_54/sr3.data54'
ORA-01200: actual file size of 1279999 is smaller than correct size of 1280000

ORA-01200是由于数据文件比文件头记录信息小一个block,通过补上这个block解决

Read of datafile '/oracle/PRD/sapdata2/sr3_54/sr3.data54' (fno 62) header failed with ORA-01202
Rereading datafile 62 header failed with ORA-01202
Errors in file /oracle/PRD/saptrace/diag/rdbms/prd/PRD/trace/PRD_ora_11272278.trc:
ORA-01122: database file 62 failed verification check
ORA-01110: data file 62: '/oracle/PRD/sapdata2/sr3_54/sr3.data54'
ORA-01202: wrong incarnation of this file - wrong creation time

ORA-01202是由于create time没有修改正确导致,重新修改解决

Rereading datafile 84 header failed with ORA-01203
Errors in file /oracle/PRD/saptrace/diag/rdbms/prd/PRD/trace/PRD_ora_17105252.trc:
ORA-01122: database file 84 failed verification check
ORA-01110: data file 84: '/oracle/PRD/sapdata3/sr3_76/sr3.data76'
ORA-01203: wrong incarnation of this file - wrong creation SCN

ORA-01203是由于create scn没有修改正确导致,重新修改解决

Errors in file /oracle/PRD/saptrace/diag/rdbms/prd/PRD/trace/PRD_ora_17105278.trc:
ORA-01122: database file 62 failed verification check
ORA-01110: data file 62: '/oracle/PRD/sapdata2/sr3_54/sr3.data54'
ORA-01207: file is more recent than control file - old control file
ORA-1122 signalled during: alter database open .

ORA-01207是由于数据文件的ckp信息比控制文件的新,重建ctl解决,解决这些问题之后,顺利打开数据库

SQL> startup mount;
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.

Total System Global Area 3.7548E+10 bytes
Fixed Size                  2254136 bytes
Variable Size            1.9193E+10 bytes
Database Buffers         1.8254E+10 bytes
Redo Buffers               98996224 bytes
Database mounted.
SQL> alter database open;

Database altered.

SQL> select status,count(1) from v$datafile_header group by status;

STATUS    COUNT(1)
------- ----------
ONLINE          84

然后跳过坏块,导出数据,对于无法导出的异常表进行特殊处理,完成本次恢复工作,最终恢复结果总结

几乎动用了所有手段的Oracle故障恢复

Posted on 2026 年 08 月 01 日 by 惜分飞

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：几乎动用了所有手段的Oracle故障恢复

最近处理了一个比较复杂的恢复,使用了十八般武艺基本上完成了恢复,最大限度恢复客户的数据
故障背景
1. 客户两个1.8T盘做raid 1,操作系统是linux（分区swap,/ [lv方式]）运行oracle数据库(跑的是一家医院的his系统),前些年一直这样运行
2. 今年4月份发现空间不足,维护人员发现主机上有一个sdb盘(裸盘,而且没有被使用),直接加入到/分区的lv中
3. 前几天系统突然故障,数据库无法连接,他们排查原因的时候发现备份一体机的备份相关的配置和以前设置不一样了,以为故障和这个相关,然后他们就让备份一体机厂商把备份相关配置还原恢复,结果这个操作导致两个问题:1)备份一体机中所有的关于这个主机上的备份文件全部被删除;2)以前在这个主机上看到的sdb的lun也不见了(后来确认是备份一体机映射出来的,现在被回收回去了)
4. 由于调整一体机相关设置之后,依旧无法解决问题,他们开始怀疑是raid磁盘问题(可能这个时候也发现了raid上面有告警),然后多次尝试对两个盘进行插拔操作,最后导致raid也异常
5. 客户的备份机制:先备份在本地的/分区(也就是说备份文件很可能部分写入到了sdb盘),然后再传输到备份一体机中.

恢复思路
1. 镜像损坏的raid磁盘
2. 通过损坏的磁盘中恢复出来可以恢复的数据文件
3. 通过碎片扫描磁盘,把由于元数据丢失导致部分在镜像磁盘中的数据块恢复出来
4. 通过提取镜像磁盘中的备份,并尽可能的恢复出来需要的业务数据块(基于客户这边的情况,备份是最近写的,大概率是在sdb盘上面占比大,所以直接可以还原的概率很小)
5. 通过工具把3和4中提取出来的block,整合到2中的数据文件中
6. 然后打开数据导出数据(设置跳过坏块)

具体恢复操作
1. 恢复损坏磁盘中的数据文件
接手这个故障之后,让客户想对raid 1中的其中一块磁盘进行镜像,通过工具分析确认是vg少了一块盘

通过镜像文件恢复数据文件(由于lv包含了已经丢失的sdb盘),所以数据肯定不完整,但是理论上今年4月份之前的数据应该相对完整,先通过工具对镜像进行解析,恢复镜像中的数据文件

在拷贝过程中发现部分文件有报错,通过文件系统元数据查看报错数据文件分布元数据信息,确认部分数据段存放在了sdb盘上面

通过对恢复出来的所有数据文件使用obet的dbv功能检测(obet实现对数据文件坏块检测功能),并确认有6个数据文件异常

PS I:\2026年7月31日> Get-Content .\dbv_20260731085210.log | Select-String "filesize_status:NO" -Context 2,0

  File #1: I:\20260731-jn\xxxx\system01.dbf (4167680 blocks) - Started: 2026-07-31 08:52:10
> File #1: rfile=1 (0x00000001)  header_block_num=4175360 (0x003FB600)  filesize_status:NO

  File #2: I:\20260731-jn\xxxx\sysaux01.dbf (2470912 blocks) - Started: 2026-07-31 08:52:44
> File #2: rfile=2 (0x00000002)  header_block_num=2536960 (0x0026B600)  filesize_status:NO

  File #24: I:\20260731-jn\xxxx\XXX406.DBF (2331648 blocks) - Started: 2026-07-31 08:55:58
> File #24: rfile=24 (0x00000018)  header_block_num=2522880 (0x00267F00)  filesize_status:NO

  File #25: I:\20260731-jn\xxxx\XXX407.DBF (2292736 blocks) - Started: 2026-07-31 08:56:17
> File #25: rfile=25 (0x00000019)  header_block_num=2484480 (0x0025E900)  filesize_status:NO

  File #26: I:\20260731-jn\xxxx\XXXX408.DBF (2291712 blocks) - Started: 2026-07-31 08:56:36
> File #26: rfile=26 (0x0000001A)  header_block_num=2483200 (0x0025E400)  filesize_status:NO

  File #27: I:\20260731-jn\xxxx\sysaux02.dbf (832512 blocks) - Started: 2026-07-31 08:56:55
> File #27: rfile=27 (0x0000001B)  header_block_num=920832 (0x000E0D00)  filesize_status:NO

这里主要是file 24,25,26涉及业务数据,对于system 大概率是aud$记录,sysaux可以直接忽略.

2. 对镜像盘进行碎片扫描,尽可能多的找数据块
对于异常文件缺少的数据块,先尝试对进行磁盘进行碎片扫描最大限度恢复可以由于文件系统元数据写入到sdb磁盘导致的丢失数据,使用OraScan(Oracle 碎片扫描工具)进行碎片扫描,恢复出来数据文件

3. 先从操作系统中恢复出来备份文件,然后使用工具在备份中强制提取file为24,25,26数据文件

4. 使用obet最近开发的merge功能对文件进行整合,类似操作

5. 最终恢复之后效果,所有业务数据块总的只有15149个损坏block(无法找出来)

C:\Users\XFF>grep "File #"  C:\Users\XFF\dbv_20260801233813.log
File #24: I:\20260731-jn\xxxx\XXX406.DBF (2522881 blocks) - Started: 2026-08-01 23:38:13
File #24: rfile=24 (0x00000018)  header_block_num=2522880 (0x00267F00)  filesize_status:OK
  File #24 completed: 0 all zero, 0 soft corrupted, 0 tailchk error, 0 checksum error, 4288 rdba error
File #25: I:\20260731-jn\xxxx\XXX407.DBF (2484481 blocks) - Started: 2026-08-01 23:39:14
File #25: rfile=25 (0x00000019)  header_block_num=2484480 (0x0025E900)  filesize_status:OK
  File #25 completed: 0 all zero, 1 soft corrupted, 0 tailchk error, 0 checksum error, 10604 rdba error
File #26: I:\20260731-jn\xxxx\XXX408.DBF (2483201 blocks) - Started: 2026-08-01 23:40:13
File #26: rfile=26 (0x0000001A)  header_block_num=2483200 (0x0025E400)  filesize_status:OK
  File #26 completed: 0 all zero, 0 soft corrupted, 0 tailchk error, 0 checksum error, 256 rdba error

6. 尝试打开数据库过程中遇到还有文件大小不对的问题

SQL> /
CREATE CONTROLFILE REUSE DATABASE "XXX" NORESETLOGS FORCE LOGGING NOARCHIVELOG
*
第 1 行出现错误:
ORA-01503: CREATE CONTROLFILE ??
ORA-01200: 853727 ????????? 920832 ??????
ORA-01110: ???? 27: 'I:\20260731-jn\xxxx\sysaux02.dbf'

使用obet的extend功能进行处理

OBET> extend file 1
File #1: I:\20260731-jn\xxx\sysaux02.dbf
  BlockSize:       8192 bytes
  Header Blocks:   920832 (offset 44)
  Expected Size:   7543463936 bytes ((920832+1)*8192)
  Actual Size:     6993739776 bytes
  Status: File is smaller than header record.
  Extending file by 549724160 bytes with zero-filled padding...
  Confirm? (Y/yes to proceed): Y
  Done. File extended to 7543463936 bytes.

然后打开数据库过程报各种错误处理

SQL> recover database;
ORA-10562: Error occurred while applying redo to data block (file# 24, block# 2086190)
ORA-10564: tablespace TS_HIS4
ORA-01110: ???????? 24: 'I:\20260731-JN\XXXX\XXX406.DBF'
ORA-10561: block type 'TRANSACTION MANAGED INDEX BLOCK', data object# 93878
ORA-00600: ????????????, ????: [6122], [0], [81963], [0], [], [], [], [], [], [], [], []

SQL> recover database until cancel;
ORA-00279: 更改 3573202216 (在  生成) 对于线程 1 是必需的


指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'I:\20260731-JN\XXXX\SYSTEM01.DBF'


ORA-01112: 未启动介质恢复


SQL> alter database open resetlogs ;
alter database open resetlogs
*
第 1 行出现错误:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [2662], [0], [3573202226], [0],
[3573222676], [12583040], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [2662], [0], [3573202225], [0],
[3573222676], [12583040], [], [], [], [], [], []
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [0], [3573202223], [0],
[3573222676], [12583040], [], [], [], [], [], []
进程 ID: 16884
会话 ID: 1 序列号: 3

通过patch_scn(Patch SCN一键解决ORA-600 2662故障)解决这个问题之后,数据库顺利打开

SQL> alter database open ;
alter database open
*
第 1 行出现错误:
ORA-01113: ?? 1 ??????
ORA-01110: ???? 1: 'I:\20260731-JN\XXXX\SYSTEM01.DBF'

SQL> recover database;
完成介质恢复。
SQL> alter database open;

数据库已更改。

然后按照客户需求导出数据,完成本次恢复任务.

Patch_SCN快速修复ORA-01555数据库open故障

Posted on 2026 年 07 月 26 日 by 惜分飞

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：Patch_SCN快速修复ORA-01555数据库open故障

有一个朋友在线把数据文件拷贝走,然后发现异常又拷贝回来,结果再重启库发现数据库无法正常启动,尝试强制拉库

SQL> recover database using backup controlfile until cancel;
ORA-00279: change 1046834263 generated at 07/24/2026 22:04:11 needed for thread
1
ORA-00289: suggestion : /data02/archivelog/reybtstg/1_1755_1147617488.dbf
ORA-00280: change 1046834263 for thread 1 is in sequence #1755


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/u01/app/oracle/oradata/reybtstg/system01.dbf'

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 1
ORA-01555: snapshot too old: rollback segment number 10 with name
"_SYSSMU10_1197734989$" too small
Process ID: 298308
Session ID: 613 Serial number: 3

alert日志报错信息

ARC0: STARTING ARCH PROCESSES COMPLETE
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /data02/reybtstg/oradata/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sat Jul 25 14:15:34 2026
SMON: enabling cache recovery
ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0000.3e656c5d):
select ctime, mtime, stime from obj$ where obj# = :1
Errors in file /u01/app/oracle/diag/rdbms/reybtstg/reybtstg/trace/reybtstg_ora_298308.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 10 with name "_SYSSMU10_1197734989$" too small
Errors in file /u01/app/oracle/diag/rdbms/reybtstg/reybtstg/trace/reybtstg_ora_298308.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 10 with name "_SYSSMU10_1197734989$" too small
Error 704 happened during db open, shutting down database
USER (ospid: 298308): terminating the instance due to error 704
Instance terminated by USER, pid = 298308
ORA-1092 signalled during: alter database open resetlogs...
opiodr aborting process unknown ospid (298308) as a result of ORA-1092
Sat Jul 25 14:15:35 2026
ORA-1092 : opitsk aborting process

这个错误比较好处理只要修改Oracle scn即可,使用Patch_SCN for Linux进行修改

---会话1
[oracle@xff ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on Sat Jul 25 14:21:11 2026

Copyright (c) 1982, 2013, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup nomount pfile='/tmp/pfile';
ORACLE instance started.

Total System Global Area 6.4137E+10 bytes
Fixed Size		    2269072 bytes
Variable Size		 1.5569E+10 bytes
Database Buffers	 4.8318E+10 bytes
Redo Buffers		  246980608 bytes
SQL> @/tmp/rectl

Control file created.

---会话2
[oracle@xff tmp]$ ./Patch_SCN -h
Usage:
  Software License:       ./Patch_SCN -key
  Get Oracle SPID:        ./Patch_SCN -spid
  Get SCN address:        ./Patch_SCN -addr
  Automatic address mode: ./Patch_SCN <spid> <new_value>
  Manual address mode:    ./Patch_SCN <spid> <address> <new_value>
  Where:
    <spid> - Oracle process ID
    <address> - Memory address (hexadecimal)
    <new_value> - SCN value to modify (decimal or hexadecimal)
[oracle@xff tmp]$ ./Patch_SCN -spid

Found 3 Oracle LOCAL=YES processes: 283668  283670  305036  

Process Details:
UID        PID  PPID  C STIME TTY          TIME CMD
oracle   283668 283627  0 Jul18 ?        00:15:10 oracletesta (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle   283670 283627  0 Jul18 ?        00:35:25 oracletesta (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle   305036 304678  0 14:21 ?        00:00:00 oracleorcltg (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
[oracle@xff tmp]$ ./Patch_SCN 305036 1146834263
Successfully obtained address automatically: 0x6001ae70
Original Oracle SCN at Address 0x6001ae70: 0x0
Are you sure you want to modify Oracle SCN? (yes/no): yes
New SCN at Address 0x6001ae70: 0x445b4d57
Oracle SCN successfully modified.

数据库正常打开

----会话1
SQL> recover database;
Media recovery complete.
SQL> alter database open ;

Database altered.

SQL>

完成本次数据库恢复工作.

快速处理 ORA-01210: data file header is media corrupt 故障

Posted on 2026 年 07 月 24 日 by 惜分飞

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：快速处理 ORA-01210: data file header is media corrupt 故障

客户反馈硬件故障之后,数据库无法正常启动，尝试recover操作报ORA-01122错误

SQL> recover database;
ORA-00283: 恢复会话因错误而取消
ORA-01122: 数据库文件 1 验证失败
ORA-01110: 数据文件 1: 'H:\BAIDUNETDISK\ORACLEDATA\ORCL\SYSTEM01.DBF'
ORA-01207: 文件比控制文件更新 - 旧的控制文件

这个错误比较明显，由于数据文件的checkpoint信息比数据文件 file# 1新，通过重建ctl可以进行解决

SQL> @rectl.sql
CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS FORCE LOGGING ARCHIVELOG
*
第 1 行出现错误:
ORA-01503: CREATE CONTROLFILE failed
ORA-01210: data file header is media corrupt
ORA-01110: data file 42: 'H:\BAIDUNETDISK\ORACLEDATA\ORCL\XFF.DBF'

但是这里遭遇到ORA-01210错误

[oracle@iZbp11c0qyuuo1gr7j98upZ ~]$ oerr ora 1210
01210, 00000, "data file header is media corrupt"
// *Cause: The file header block is internally inconsistent. The beginning
//         of the block has a header with a checksum and other data for
//         insuring the consistancy of the block. It is possible that
//         the last disk write did not operate correctly. The most likely
//         problem is that this is not a datafile for any database.
// *Action: Have operating system make correct file available to database.
//         If the trace file dump indicates that only the checksum is wrong,
//         restore from a backup and do media recovery.

这个错误比较明显，官方解释可能是由于文件头的写丢失导致checksum异常,对于这样的故障，可以考虑使用bbed进行修复，但是obet更加方便（Oracle数据块编辑工具( Oracle Block Editor Tool)-obet），直接使用这个工具进行处理

OBET> tailchk
Check tailchk for File H:\BaiduNetdisk\oracledata\orcl\XFF.DBF, Block 1:
current = 0x6E743122, required = 0x010B0000
OBET> d
File: H:\BaiduNetdisk\oracledata\orcl\HD_DATAPMS01.DBF
Block: 1                Offsets:     0 to    31
--------------------------------------------------------------------------------
00002000 0BA20000 0100800A 00000000 00000104 02870000 00000000 0004200B 2F2E315E
<32 bytes read>
OBET> set mode edit
mode set to: edit
OBET> tailchk apply
Confirm applying tailchk:
File: H:\BaiduNetdisk\oracledata\orcl\XFF.DBF
Block: 1
Offset in block: 8188 (file offset: 0x00003FFC)
Original value: 0x6E743122
New value:      0x010B0000
Confirm? (Y/YES to proceed): y
Verification successful: Stored tailchk matches calculated value (0x010B0000).
Tailchk applied successfully.
OBET> sum apply
Confirm applying checksum:
File: H:\BaiduNetdisk\oracledata\orcl\XFF.DBF
Block: 1
Offset in block: 16 (file offset: 0x00002010)
Original value: 0x0287
New value:      0x38ED
Confirm? (Y/YES to proceed): y
Verification successful: Stored checksum matches calculated value (0x38ED).
Checksum applied successfully.

然后直接重建ctl成功，并顺利打开数据库

Thu Jul 23 12:11:39 2026
Successful mount of redo thread 1, with mount id 1767178232
Completed: CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS FORCE LOGGING ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 18688
LOGFILE
  GROUP 1 'H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO01.LOG'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 'H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO02.LOG'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 'H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO03.LOG'  SIZE 50M BLOCKSIZE 512
DATAFILE
  'H:\BAIDUNETDISK\ORACLEDATA\ORCL\SYSTEM01.DBF',
  'H:\BAIDUNETDISK\ORACLEDATA\ORCL\SYSAUX01.DBF',
  'H:\BAIDUNETDISK\ORACLEDATA\ORCL\UNDOTBS01.DBF',
………………
CHARACTER SET ZHS16GBK
Thu Jul 23 12:12:21 2026
ALTER DATABASE RECOVER  database  
Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 20 slaves
Thu Jul 23 12:12:21 2026
Recovery of Online Redo Log: Thread 1 Group 3 Seq 104748 Reading mem 0
  Mem# 0: H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO03.LOG
Recovery of Online Redo Log: Thread 1 Group 1 Seq 104749 Reading mem 0
  Mem# 0: H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO01.LOG
Completed: ALTER DATABASE RECOVER  database  
alter database open upgrade
Beginning crash recovery of 1 threads
 parallel recovery started with 19 processes
Started redo scan
Completed redo scan
 read 8331 KB redo, 0 data blocks need recovery
Started redo application at
 Thread 1: logseq 104749, block 2, scn 788671390
Recovery of Online Redo Log: Thread 1 Group 1 Seq 104749 Reading mem 0
  Mem# 0: H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO01.LOG
Completed redo application of 0.00MB
Completed crash recovery at
 Thread 1: logseq 104749, block 16665, scn 788695898
 0 data blocks read, 0 data blocks written, 8331 redo k-bytes read
Initializing SCN for created control file
Database SCN compatibility initialized to 3
Thu Jul 23 12:12:27 2026
LGWR: STARTING ARCH PROCESSES
Thu Jul 23 12:12:27 2026
ARC0 started with pid=40, OS id=20580 
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thu Jul 23 12:12:28 2026
ARC1 started with pid=41, OS id=12396 
Thu Jul 23 12:12:28 2026
ARC2 started with pid=42, OS id=18888 
Thu Jul 23 12:12:28 2026
ARC3 started with pid=43, OS id=16552 
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
Archived Log entry 1 added for thread 1 sequence 104747 ID 0x5e30f62f dest 1:
Thread 1 advanced to log sequence 104750 (thread open)
Thread 1 opened at log sequence 104750
  Current log# 2 seq# 104750 mem# 0: H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO02.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Thu Jul 23 12:12:29 2026
SMON: enabling cache recovery
Archived Log entry 2 added for thread 1 sequence 104749 ID 0x5e30f62f dest 1:
Archived Log entry 3 added for thread 1 sequence 104748 ID 0x5e30f62f dest 1:
[19300] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:15968843 end:15968859 diff:16 (0 seconds)
Dictionary check beginning
Tablespace 'TEMP' 
#3
 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
         This condition can occur when a backup controlfile has
         been restored.  It may be necessary to add files to these
         tablespaces.  That can be done using the SQL statement:
         ALTER TABLESPACE <tablespace_name> ADD TEMPFILE
         Alternatively, if these temporary tablespaces are no longer
         needed, then they can be dropped.
           Empty temporary tablespace: TEMP
*********************************************************************
Database Characterset is ZHS16GBK
Stopping background process MMNL
Errors in file C:\APP\XFF\diag\rdbms\orcl\orcl\trace\orcl_smon_18084.trc  (incident=7313):
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []
Incident details in: C:\APP\XFF\diag\rdbms\orcl\orcl\incident\incdir_7313\orcl_smon_18084_i7313.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Block recovery from logseq 104750, block 74 to scn 906345854
Recovery of Online Redo Log: Thread 1 Group 2 Seq 104750 Reading mem 0
  Mem# 0: H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO02.LOG
Block recovery completed at rba 104750.75.16, scn 0.906345855
Block recovery from logseq 104750, block 74 to scn 906345854
Recovery of Online Redo Log: Thread 1 Group 2 Seq 104750 Reading mem 0
  Mem# 0: H:\BAIDUNETDISK\ORACLEDATA\ORCL\REDO02.LOG
Block recovery completed at rba 104750.75.16, scn 0.906345855
Errors in file C:\APP\XFF\diag\rdbms\orcl\orcl\trace\orcl_smon_18084.trc:
ORA-01595: 释放区 (2) 回退段 (4) 时出错
ORA-00600: 内部错误代码, 参数: [4194], [], [], [], [], [], [], [], [], [], [], []

这里有一个ORA-600 4194错误,由于undo回滚段异常，对异常回滚段进行处理，然后导出数据完成本次恢复工作