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

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

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

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

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导出数据,完成本次恢复任务

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

标题：obet dbv功能完整说明

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

大量的恢复经验和实战总结,逐步了完善obet(Oracle Block Edit Tool)功能和实现恢复的便利性.对于数据库恢复其中一个重要功能就是检测数据块的损坏情况(这个直接关系到恢复的实际效果),Oracle本身提供的dbv功能有一些不足,obet工具的dbv功能是对oracle本身的dbv功能的深度完善,弥补其本身的几个功能不足点:
1. Oracle dbv 需要安装oracle 软件,对于有些时候为了一个dbv检测需要安装Oracle 软件，成本和动作太大,obet工具直接单个文件即可运行
2. 如果数据文件头损坏,或者文件大小不对,或者block 0损坏,Oracle自带dbv均无法检测
3. Oracle dbv无法实现跨字节序检测(比如需要在win平台上检测aix系统的数据文件的坏块情况[比如硬件恢复场景需要])
4. Oracle dbv有些版本无法实现低版本dbv检测高版本数据库文件
5. Oracle dbv无法一条命令实现多个数据文件检测(需要人工写脚本来实现)

在使用obet的dbv功能之前需要准备listfile文件(内容格式:No Name)
listfile文件操作
1. 在可以mount的库中可以直接通过查询v$datafile(select file#,name from v$datafile),把结果保存到listfile.txt中
2. 通过obet的listfile功能直接获取

OBET> listfile
Usage: listfile <path|remove|edit>
  listfile <path>   - Scan directory and write to listfile.txt
  listfile remove   - Delete listfile.txt
  listfile edit [path] - Edit listfile.txt (notepad on Win, vi on Linux)

listfile 支持*通配符

OBET> listfile e:\oradata\orcl\sys*.dbf
Listed 2 files from 'e:\oradata\orcl' to listfile.txt (starting from #1).

OBET> open listfile.txt
Loaded 2 files from  datafile list 'listfile.txt'.

OBET> info

Loaded files (2 total):
----------------------------------------
Number  Path
----------------------------------------
     1  e:\oradata\orcl\SYSAUX01.DBF
     2  e:\oradata\orcl\SYSTEM01.DBF
----------------------------------------

listfile remove 直接删除掉当前目录下面的listfile.txt文件
listfile edit 直接调用notepad/vi 编辑模式打开当前目录下的listfile.txt文件(也可以指定具体文件名称)
3. 使用open命令加载listfile

OBET> open listfile.txt
Loaded 2 files from  datafile list 'listfile.txt'.

OBET> info

Loaded files (2 total):
----------------------------------------
Number  Path
----------------------------------------
     1  e:\oradata\orcl\SYSAUX01.DBF
     2  e:\oradata\orcl\SYSTEM01.DBF
----------------------------------------

dbv之前确认参数设置
在执行dbv之前需要先确认当前一些配置,和dbv相关的主要是blocksize(默认值为8192),endian(默认值为little),可以通过show命令查看(如果是检测linux/win环境下默认的oracle数据文件,理论上不用这修改这些值)

OBET> show

Current settings:
File: (not set)
Blocksize: 8192 bytes
Block: 1
Offset in block: 0 (file offset: 0x00002000)
Count: 32 bytes
Mode: browse
Endian: little (x86)
Loaded files: 2 (use 'info' to list)

可以根据情况通过set命令修改相关值,具体语法为:set

OBET> set
Usage: set <param> <value>
  set filename <path>    - Set target file path (required)
  set file <num>         - Set filename using loaded file number (from open list)
  set blocksize <size>  - Set block size (2048,4096,[8192],16384,32768)
  set block <num>        - Set block number (starts from 0, default: 1)
  set offset <offset>   - Set offset within block (< blocksize, default: 0)
  set count <bytes>      - Set number of bytes to read (default: 32)
  set mode edit/browse   - Enable edit/browse mode
  set endian big/little  - Set byte order (default: little, big for AIX files)

dbv 检测数据文件
具体语法为:dbv [file N [block M [blocks X]]]
dbv 检测open listfile中的所有数据文件的所有block
dbv file N 检测listfile中编号为N的数据文件的所有block
dbv file N block M 检测listfile中编号为N的数据文件的block M开始到文件结束
dbv file N block M block X 检测listfile中编号为N的数据文件的block M开始,检测X个block

OBET> dbv

===============================================
DBV (Data Block Verification)
Block Size: 8192 bytes
Endian:     little-endian (x86)
Target File: ALL files in listfile
===============================================

Verifying file #1: e:\oradata\orcl\SYSAUX01.DBF (139521 blocks) - Started: 2026-08-16 17:37:25
File #1: rfile=2 (0x00000002)  header_block_num=139520 (0x00022100)  filesize_status:OK
  Progress: 100000 / 139521 blocks checked...
  File #1 completed: no bad blocks found
Verifying file #2: e:\oradata\orcl\SYSTEM01.DBF (126721 blocks) - Started: 2026-08-16 17:37:26
File #2: rfile=1 (0x00000001)  header_block_num=126720 (0x0001EF00)  filesize_status:OK
  Progress: 100000 / 126721 blocks checked...
  File #2 completed: no bad blocks found

DBV completed at: 2026-08-16 17:37:26

===============================================
DBV Summary:
Total blocks checked: 266242
Total all zero blocks found: 0
Total all rdba error blocks found: 0
Total all tailchk error blocks found: 0
Total all soft corrupted blocks found: 0
Total all checksum error blocks found: 0
Total bad blocks found: 0
Execution time: 1.00 seconds
Throughput: 2080.02 MB/s
===============================================

Detailed report saved to: dbv_20260816173725.log
Files processed: 2

OBET> dbv file 1

===============================================
DBV (Data Block Verification)
Block Size: 8192 bytes
Endian:     little-endian (x86)
Target File: #1 (only)
===============================================

Verifying file #1: e:\oradata\orcl\SYSAUX01.DBF (139521 blocks) - Started: 2026-08-16 17:37:31
File #1: rfile=2 (0x00000002)  header_block_num=139520 (0x00022100)  filesize_status:OK
  Progress: 100000 / 139521 blocks checked...
  File #1 completed: no bad blocks found

DBV completed at: 2026-08-16 17:37:32

===============================================
DBV Summary:
Total blocks checked: 139521
Total all zero blocks found: 0
Total all rdba error blocks found: 0
Total all tailchk error blocks found: 0
Total all soft corrupted blocks found: 0
Total all checksum error blocks found: 0
Total bad blocks found: 0
Execution time: 1.00 seconds
Throughput: 1090.01 MB/s
===============================================

Detailed report saved to: dbv_file_1_20260816173731.log
Files processed: 1

OBET> dbv file 1 block 128

===============================================
DBV (Data Block Verification)
Block Size: 8192 bytes
Endian:     little-endian (x86)
Target File: #1, block 128 to end
===============================================

Verifying file #1: e:\oradata\orcl\SYSAUX01.DBF (block 128 to 139520, 139393 blocks) - Started: 2026-08-16 17:37:42
File #1: rfile=2 (0x00000002)  header_block_num=139520 (0x00022100)  filesize_status:OK
  Progress: 100128 / 139521 blocks checked...
  File #1 completed: no bad blocks found

DBV completed at: 2026-08-16 17:37:43

===============================================
DBV Summary:
Total blocks checked: 139393
Total all zero blocks found: 0
Total all rdba error blocks found: 0
Total all tailchk error blocks found: 0
Total all soft corrupted blocks found: 0
Total all checksum error blocks found: 0
Total bad blocks found: 0
Execution time: 1.00 seconds
Throughput: 1090.01 MB/s
===============================================

Detailed report saved to: dbv_file_1_block_128_20260816173742.log
Files processed: 1

OBET> dbv file 1 block 128 blocks 10

===============================================
DBV (Data Block Verification)
Block Size: 8192 bytes
Endian:     little-endian (x86)
Target File: #1, block 128 - 137 (10 blocks)
===============================================

Verifying file #1: e:\oradata\orcl\SYSAUX01.DBF (block 128 to 137, 10 blocks) - Started: 2026-08-16 17:37:47
File #1: rfile=2 (0x00000002)  header_block_num=139520 (0x00022100)  filesize_status:OK
  File #1 completed: no bad blocks found

DBV completed at: 2026-08-16 17:37:47

===============================================
DBV Summary:
Total blocks checked: 10
Total all zero blocks found: 0
Total all rdba error blocks found: 0
Total all tailchk error blocks found: 0
Total all soft corrupted blocks found: 0
Total all checksum error blocks found: 0
Total bad blocks found: 0
Execution time: 0.00 seconds
Throughput: 0.00 MB/s
===============================================

Detailed report saved to: dbv_file_1_block_128_20260816173747.log
Files processed: 1

检测的具体明细可以看obet所在的当前目录中的dbv*.log文件,里面有坏块类型:
rdba error:表示block#和该块所在位置不匹配
tailchk/checksum error:表示该block不满足Oracle的校验规则
soft corrupted:表示该block在Oracle数据库标记为坏块
zero block:表示该block中全部为0,一般是由于底层损坏,或者硬件恢复过程使用空块替代引起
filesize_status:NO表示文件实际大小和文件头记录大小不匹配
下载obet obet使用说明

联系：手机/微信(+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 碎片扫描工具) 使用说明)进一步扫描

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

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

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

标题：OBET-Oracle Block Editor Tool使用说明

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

1. 概述

OBET 以 REPL 交互模式工作：启动后进入 OBET> 提示符，逐条执行命令。文件以 文件号 + 块号 的方式定位，可同时维护一份文件列表（来自 listfile.txt），方便在不同数据文件之间交叉读写。

功能概览

• 十六进制查看 / 编辑数据块（自动维护 tailchk 和 checksum）
• 打印 Oracle 内部结构（kcbh / kcvfh* / tailchk）
• 跨数据文件拷贝块 / 字节范围 / 文件头 SCN 信息
• 整文件强制拷贝（forcecopy，绕过坏块）
• 扩展数据文件（extend file N，按文件头记录大小补齐零块）
• 坏块修复：corrupt / repair block / repair blkscn / merge
• dbv 数据块物理一致性扫描（可指定文件/起始块/块数）
• 导出 / 解析数据库元数据：get_dhr / parse_ctl / dump_undo
• 解析 RDBA 编码（rdba / getrdba）
• 构造 Oracle 数据块（build block N,M）
• Linux 下 Patch Oracle 进程 SCN（patch_scn）

2. 开发者信息

反馈授权 / Bug / 功能建议可通过上述任一渠道联系。

3. 启动与会话

3.1 help

显示完整命令清单（与本手册对应的内嵌帮助）。

OBET> help

  [File / Block Setup]
  open          - Load file list (format:  )
  info                    - Show loaded file list
  set       - Configure: filename|file |blocksize|block|offset|count|mode|endian
  show                    - Display current settings
  listfile <path|remove|edit>  - Scan dir (path), remove, or edit listfile.txt (notepad/vi)

  [View Data]
  d/dump [file N] [block X] [offset Y] [count Z] - Display block data (default: current file/block)
  p/print <kcvfh[.field]|tailchk>  - Print Oracle structure (use 'p' alone for full list)

  [Verify / Calculate]
  sum [apply] [file N] [block X]       - Verify (or apply) block checksum
  tailchk [apply] [file N] [block X]   - Verify (or apply) block tailchk
  dbv [file N [block M [blocks X]]]    - Verify data blocks for corruption

  [Modify Data]
  m/modify  [file N] [block X] [offset Y]  - Modify bytes (with auto-checksum/tailchk)
  corrupt [file N] [block X]          - Mark block as corrupted
  backup [file N] [block X]           - Backup block to backup_blk/
  undo                                - Undo last modification

  [Repair]
  repair block [file N] [block X]         - Fix seq_kcbh / tailchk / checksum
  repair blkscn [file N] [block X]        - Fix block SCN lower than block CSC
  copy data  to               - Copy byte range between files
    / format: file[,block][,offset[,count]]
    Example: copy data 1,1,16,32 to 2,5,16
  copy block <file,block> to <file,block>  - Copy entire block between files
  copy chkscn file N to file M            - Copy datafile header checkpoint SCN info
  copy resetlogscn file N to file M       - Copy datafile header resetlogs info
  forcecopy file N to               - Force copy file ignoring bad blocks (damaged disks)
  extend file N                          - Check and extend datafile to match header record
  merge file N from M                    - Repair N's bad blocks using M's blocks at same RDBA
  build block N,M [to file X]           - Build block (N=file#, M=block#); write build_N_M.blk; 'to file X' patch after validation

  [Database Info / Diagnostics]
  get_dhr                - Extract DB info from file headers to dhr_*.txt
  parse_ctl        - Parse Oracle control file (DB name / datafiles / tablespaces)
  rdba              - Parse RDBA value to File# and Block# (e.g., rdba 0xFEDCBA12)
  getrdba <rfile#> <block#> - Calculate RDBA from rfile# and block# (e.g., getrdba 1 500)
  dump_undo [file N] [block M] - Dump UNDO$ segment: name + status$ (default: file 1 block 224)

  [Session]
  license              - Show / manage license
  version              - Show version and developer info
  spool |off    - Start/stop logging to file
  help                 - Show this help message
  quit/exit            - Exit OBET

3.2 version

显示 OBET 版本、构建时间、开发者信息。

OBET> version
=============================================
Welcome to Oracle Block Editor Tool (OBET)
=============================================
***** !!! For Oracle Internal Use only !!! *****

[Software Function Description]
- View and edit data block in hexadecimal format
- Print Oracle internal structures (kcbh / kcvfh* / tailchk)
- Modify data block bytes (with auto tailchk/checksum)
- Copy block / data between different datafiles
- Copy / repair datafile header SCN info (copy chkscn/resetlogscn)
- Force copy entire file ignoring bad blocks (forcecopy)
- Extend datafile to expected size from file header (extend)
- Mark data block as corrupted block
- Verify data blocks for corruption (dbv)
- Repair corrupted block / Repair block SCN
- Calculate and verify tailchk / checksum
- Backup data block to backup_blk/ directory
- Repair bad blocks using healthy donor file (merge)
- Extract undo$ segment contents (dump_undo)
- Extract database info from file headers (get_dhr)
- Parse Oracle control file (parse_ctl)
- Parse RDBA value to Oracle File# and Block#
- Patch Oracle process SCN in memory (patch_scn, Linux only)
- Scan directory to listfile.txt (listfile)

[Developer Information]
- Name: XiFenFei
- Phone: +86-17813235971
- Email: dba@xifenfei
- Q Q: 107644445
- WeChat: 17813235971
- Website: https://www.xifenfei.com

[Version Details]
- Software Version: 2026.08
- Build Date: 2026.08.12 17:49:27

3.3 quit / exit

退出 OBET。

4. 文件 / 块设置

这一组命令负责把磁盘上的数据文件加载到 OBET 上下文。所有读写命令都依赖当前的 filename、blocksize、block、offset、count、endian 等参数。

4.1 open <listfile>

从指定文件加载文件列表。文件每行格式：<num> <path>，num 是 OBET 内部文件号，供后续 set file N / file N 使用。

OBET> open listfile.txt

OBET> open test_listfile.txt
Loaded 1 files from datafile list 'test_listfile.txt'.

4.2 info

显示当前已加载的文件列表（编号 / 路径）。

OBET> info
----------------------------------------
No   Path
----------------------------------------
1    E:/CC/obet/dbf/SYSTEM01.DBF
----------------------------------------

4.3 set <param> <value>

设置上下文参数。可用参数：

OBET> set filename /u01/oradata/users01.dbf
OBET> set blocksize 8192
OBET> set block 100
OBET> set endian big

4.4 show

显示当前上下文所有参数，包括 Mode（browse / edit）、Filename、File#、Block#、Blocksize、Offset、Count、Endian 等。

OBET> show
Current settings:
File: (not set)
Blocksize: 8192 bytes
Block: 1
Offset in block: 0 (file offset: 0x00002000)
Count: 32 bytes
Mode: browse
Endian: little (x86)
Loaded files: 1 (use 'info' to list)

4.5 listfile <path | remove | edit>

扫描目录生成 listfile.txt、清空或编辑。

OBET> listfile /u01/oradata
OBET> listfile edit
OBET> listfile remove

• listfile <path>：递归扫描目录，支持通配符 *，结果追加写入当前目录的 listfile.txt
• listfile remove：删除当前目录的 listfile.txt
• listfile edit [path]：调用系统编辑器（Windows 记事本 / Linux vi）打开 listfile.txt，可指定路径

通配符示例：

OBET> listfile E:/oradata           # 扫描整个目录
OBET> listfile E:/dbf/system*.dbf  # 仅扫描名称以 system 开头且 .dbf 结尾的数据文件

已存在 listfile.txt 时，新扫描结果以递增编号追加写入。

5. 查看数据

5.1 dump / d [file N] [block X] [offset Y] [count Z]

以十六进制 + ASCII 形式显示块数据。默认使用当前文件 / 块 / 偏移，也可直接通过参数指定。

OBET> d
OBET> dump file 1 block 100
OBET> dump offset 16 count 64
OBET> dump file 2 block 5 offset 0 count 128

OBET> dump file 1 block 128 offset 32 count 48
File: e:/cc/obet/dbf/system01.dbf (#1 in listfile)
Block: 128                Offsets:    32 to    79
--------------------------------------------------------------------------------
00100020 00000000 01000200 00000000 04001200 43000000 B02C8000 2F001000 01200000
00100040 22120200 00015800 FFFFC200 2A046803

5.2 print / p <kcvfh[.field] | tailchk>

解析并打印 Oracle 内部结构。仅支持一级字段。

OBET> p kcvfh
OBET> p kcvfh.kcvfhhdr
OBET> p kcvfh.kcvfhckp
OBET> p tailchk
ub4 tailchk                                      @8188    0x00000B01

支持的全部结构字段（p 不带参数可打印完整清单）：

6. 校验 / 计算

6.1 sum [apply] [file N] [block X]

校验或修复 checksum（块头 kcbh 中的 kcbh.flags/kcbh.checksum 字段）。

OBET> sum
OBET> sum apply
OBET> sum file 2
OBET> sum apply file 2 block 100

OBET> sum
Check value for File e:\cc\obet\dbf\system01.dbf, Block 2:
  current = 0xB71C, required = 0xB71C

6.2 tailchk [apply] [file N] [block X]

校验或修复 tailchk（块末 4 字节与起始 SCN 比对）。

OBET> tailchk
OBET> tailchk apply
OBET> tailchk apply file 1 block 224

OBET> tailchk apply file 1 block 224
Confirm applying tailchk:
File: e:\cc\obet\dbf\system01.dbf
Block: 224
Offset in block: 8188 (file offset: 0x00071FFC)
Original value: 0x00E03F03
New value:      0x00E03F03
Confirm? (Y/YES to proceed): Y
tailchk applied successfully.

6.3 dbv [file N [block M [blocks X]]]

对全部已加载文件或指定文件做物理一致性扫描（类似 Oracle dbv 工具）。字节序由 set endian 控制。可检测五类问题：全零块、软损坏（seq_kcbh=0xFF）、tailchk 错误、checksum 错误、rdba 错误。

• dbv：扫描全部已加载文件（从块 0 到文件末尾）
• dbv file N：仅扫描文件 N（从块 0 到文件末尾）
• dbv file N block M：扫描文件 N 从块 M 到文件末尾
• dbv file N block M blocks X：扫描文件 N 从块 M 起共 X 块；若 M+X 超出文件总块数，则扫描到文件末尾

块号从 0 开始。自动识别 bigfile / smallfile 数据文件，bigfile 时跳过文件头（block 0）的 rdba 校验。扫描结果自动保存到日志文件：

• dbv → dbv_yyyymmddhhmmss.log
• dbv file N → dbv_file_N_yyyymmddhhmmss.log
• dbv file N block M → dbv_file_N_block_M_yyyymmddhhmmss.log

OBET> dbv
OBET> dbv file 1
OBET> dbv file 1 block 100
OBET> dbv file 1 block 100 blocks 500

OBET> dbv file 1 block 100 blocks 500
===============================================
DBV (Data Block Verification)
Block Size: 8192 bytes
Endian:     little-endian (x86)
Target:     file #1 (e:\cc\obet\dbf\system01.dbf)
Range:      block 100 to block 599 (500 blocks)
===============================================
Verifying file #1: e:\cc\obet\dbf\system01.dbf ...
DBV completed at: 2026-08-12 15:04:25
===============================================
DBV Summary:
Total blocks checked: 500
Total all zero blocks found: 0
Total all tailchk error blocks found: 0
Total all checksum error blocks found: 0
Total bad blocks found: 0
Execution time: 0.20 seconds
Throughput: 19.53 MB/s
===============================================
Detailed report saved to: dbv_file_1_block_100_20260812150425.log

7. 修改数据

7.1 modify / m <hex> [file N] [block X] [offset Y] 需授权

写入十六进制字节。写入后自动重新计算 tailchk 与 checksum。需先 set mode edit，执行时输入 Y 确认。

OBET> set mode edit
OBET> m 41424344
OBET> modify 41424344 file 1 block 100 offset 32

OBET> set mode edit
OBET> modify 41424344 file 1 block 128 offset 32
Confirm modification:
File: e:\cc\obet\dbf\system01.dbf
Block: 128
Offset: 32 (file offset: 0x00040020)
Original value: 01000200
New value:      41424344
Confirm? (Y/YES to proceed): Y
Data written successfully.

7.2 corrupt [file N] [block X] 需授权

将指定块标记为 Oracle 意义上的损坏块（破坏 tailchk）。需先 set mode edit，执行时输入 Y 确认。

OBET> corrupt file 1 block 128
Confirm marking block 128 as corrupted:
Block 128 current tailchk: 0x00200000
Successfully marked block 128 as corrupted.

7.3 backup [file N] [block X]

把指定块完整备份到当前目录的 backup_blk/ 子目录。备份文件名格式：backup_<filename>.<file#>_<block#>_<timestamp>.blk

OBET> backup file 1 block 128
Backing up file #1, block 128
e:\cc\obet\dbf\system01.dbf
Successfully backed up block 128 to backup_blk\system01.dbf.1_128_20260812150500.blk

7.4 undo 需授权

回滚最近一次 modify / repair / copy / corrupt 等写操作。OBET 在每次写操作前保留原块内容，回滚基于这份快照。

OBET> undo
Undid 1 operation(s). Block data restored from backup.

8. 修复

8.1 repair block / blkscn [file N] [block X] 需授权

• repair block：修复 seq_kcbh、tailchk、checksum
• repair blkscn：把块的 scn 抬到不低于 csc（解决 ORA-600 [kdddgb] 之类 block SCN < block CSC 类报错）

均需先 set mode edit，执行时输入 Y 确认。

OBET> set mode edit
OBET> repair block
OBET> repair block file 2 block 100
OBET> repair blkscn file 1 block 224

OBET> repair block file 1 block 128
Repairing block 1, 128...
Current block SCN information:
  blkscn: 0x000000000278D9A3 (41663267)
  blkcsc: 0x0000000002790128 (41670952)
blkscn < blkcsc, SCN repair required.
New SCN values to write:
  base:  0x02790128 (41670952)
  wrap:  0x0000
  seq:   0x00
Confirm SCN repair operations: Operation cancelled.

8.2 copy 需授权

多种拷贝语义，全部写盘需授权。

<src> / <dest> 格式：file[,block][,offset[,count]]。缺省 block 沿用当前块，缺省 offset = 0，缺省 count = blocksize。

OBET> copy data 1,1,16,32 to 2,5,16
OBET> copy block 1,100 to 2,100
OBET> copy chkscn file 1 to file 2
OBET> copy resetlogscn file 1 to file 2

OBET> copy block 1,128 to 1,129
Copying block 1,128 to 1,129...
  src: file#=1 block#=128 (rdba=0x00400080)
  dest: file#=1 block#=129 (rdba=0x00400081)
Block copied successfully.

8.3 merge file N from M 需授权

用 M 文件中 RDBA 一致的健康块替换 N 文件中的坏块。执行前 OBET 会要求输入 YES 二次确认。

OBET> merge file 2 from 3

OBET> merge file 2 from 3
Merging bad blocks from file 2 using healthy blocks from file 3...
File 2: scanning for bad blocks...
  Block 100: bad, searching donor...
  Block 100: rdba=0x00400064 matched, scanning file 3 for donor block...
  Block 100: donor found at file 3 block 100
  Replacing bad block 100 in file 2 with healthy block from file 3...
Merge completed. Total blocks repaired: 1

8.4 forcecopy file N to <path> 需授权

整文件级别强制拷贝，忽略坏块（按 blocksize 步长逐块读取；坏块读到 0 字节时填充全 0×00 写入目标）。用于磁盘扇区部分损坏但仍能部分读取的应急场景。

OBET> forcecopy file 2 to D:\rescue\users01.dbf

OBET> forcecopy file 2 to D:\rescue\users01.dbf
forcecopy: source file 2, dest D:\rescue\users01.dbf
Reading source file...
  4096 bytes read OK (block 0)
  4096 bytes read OK (block 1)
  ... (progress every 1000 blocks)
  4182831104 bytes copied (510600 blocks)
forcecopy completed. 0 bad blocks filled with zeros.

8.5 extend file N 需授权

比较 Oracle 数据文件实际大小与文件头记录的预期大小，在不一致时将文件扩展至正确大小（尾部构造 Oracle block 填充）。

判定规则：读取 block 1 内部偏移 44 处的块计数字段，计算出预期大小：

预期大小 = (块计数 + 1) × blocksize

三种结果：

• 相等——文件大小与预期一致，无需操作；
• 预期 > 实际（文件偏小）——从当前块号起，逐块用构造的 Oracle 空块填充至预期大小（不足一块的尾部按字节填零）；
• 预期 < 实际（文件偏大）——输出提示，要求人工介入，不自动截断。

前提条件：

• 需先 set blocksize 设置正确的 Oracle 块大小（4096 / 8192 / 16384 / 32768）
• 需先 set endian big|little 设置正确的字节序
• 需先 set mode edit 进入编辑模式

开始写入前需输入 Y 或 YES 二次确认（忽略大小写）。

OBET> set blocksize 8192
OBET> set mode edit
OBET> extend file 1
File #1: E:\dbf\system.dbf
  BlockSize:       8192 bytes
  Header Blocks:   510600 (offset 44)
  Expected Size:   4182835200 bytes ((510600+1)*8192)
  Actual Size:     4182831104 bytes
  Status: File is smaller than header record.
  Extending file by 4096 bytes (Build Oracle block padding)...
  Confirm? (Y/yes to proceed): Y
  Done. File extended to 4182835200 bytes.

8.6 build block N,M [to file X] 需授权

构造 Oracle 数据块（N=file# 1-1024，M=block#）并按需 patch 到 listfile 中的目标文件。

用法：

• build block N,M——仅在 OBET 当前工作目录生成 build_N_M.blk（始终生成，无论是否带 to file X）。
• build block N,M to file X——生成 blk 之后，校验通过后将构造好的块覆盖到 listfile X 的 block M。

OBET> set endian big
OBET> build block 1,500
Created: build_1_500.blk (file#=1, block#=500, rdba=0x004001F4, tailchk=0x01000000, checksum=0x0113)

OBET> set mode edit
OBET> build block 1,500 to file 1
Created: build_1_500.blk (file#=1, block#=500, rdba=0x004001F4, tailchk=0x01000000, checksum=0x0113)
Confirm patch: File 1 Block 500 (E:\dbf\system.aix-11202)? [Y/YES]: Y
Patched: File 1 Block 500 (E:\dbf\system.aix-11202)

9. 数据库诊断

9.1 get_dhr

读取当前加载的每个数据文件的 block 1（数据文件头），解析数据库元数据并生成 数据文件头报告（Get Datafile Header Report）。报告同时输出到屏幕，并写入 dhr_<YYYYMMDD_HHMMSS>.txt。

OBET> get_dhr
===============================================
get_dhr Get Datafile Header Report
Started: 2026-08-12 15:10:00
Block Size: 8192 bytes
Endian:     little-endian (x86)
===============================================
No  Path                                         DBName/DBID    Version  Ts#/TsName     File#/Rfile#  Size(DB/OS)  Create_Info           CheckPoint_Info        Fuzzy  Thread#/Seq#  Rlogs_SCN
--  ----                                         -------------  -------- -------------  -------------  -------------  -------------  --------------------  -------------------  -----  -------------  ----------
1   e:/cc/obet/dbf/system01.dbf                  ORCL/1248591446  0A200100  0/SYSTEM         1/1           590MB/OK      2005-08-30 13:50:22   2011-04-18 14:56:29  OK     1/351          534907

9.2 parse_ctl <path>

解析 Oracle 控制文件（control01.ctl / control02.ctl 等），输出 DB 名称、字符集、所有数据文件（type=04）、临时文件（type=07）、日志文件（type=03）、表空间清单。日志文件 SIZE 列由三级回退得到：

1. 操作系统上读取到的 redo 文件大小减去 512 字节（Oracle redo 文件尾部的 512 字节 footer）；
2. 若 OS 文件无法访问（文件丢失 / 不可读），从控制文件第 21 / 22 块中 redo 记录（72 字节 / 条）的块数 × 512 字节取得；
3. 上述两者都不可用时显示 0（对应记录仍会显示，便于人工干预）。

PATH 列宽按当前解析结果中最长路径动态收紧；SIZE 数值右对齐。

OBET> parse_ctl E:\ORADATA\ORCL\CONTROL01.CTL

OBET> parse_ctl E:\ORADATA\ORCL\CONTROL01.CTL
Oracle Control File Parser
==============================================
File: E:\ORADATA\ORCL\CONTROL01.CTL
Size: 9781248 bytes (597 x 16KB blocks)
==============================================
        PARSE RESULTS
==============================================
--- Database Info ---
  DB_NAME    : ORCL
  CHARSET_ID : 852 (ZHS16GBK)
--- Data Files (type=04) - 9 found ---
---------------------------------------------
  FILE#  PATH
  -----  ----
  4     E:\ORADATA\ORCL\USERS01.DBF
  3     E:\ORADATA\ORCL\UNDOTBS01.DBF
  2     E:\ORADATA\ORCL\SYSAUX01.DBF
  1     E:\ORADATA\ORCL\SYSTEM01.DBF
--- Log Files (type=03) - 3 found ---
---------------------------------------
  GROUP  PATH                                  SIZE
  -----  ----                                  ----
  1      E:\ORADATA\ORCL\REDO01.LOG         524288000
  2      E:\ORADATA\ORCL\REDO02.LOG         524288000
  3      E:\ORADATA\ORCL\REDO03.LOG         524288000
--- Tablespaces - 8 found ---

9.2.1 自动生成的重建控制文件脚本

完成屏幕输出后，OBET 会在当前工作目录生成 rectl_<DB_NAME>_<YYYYMMDDHHMMSS>.sql，可作为 CREATE CONTROLFILE 重建命令的参考模板。

文件包含 CREATE CONTROLFILE 头、LOGFILE（同 group 多成员合并为 GROUP N (m1, m2) 元组写法）、DATAFILE、CHARACTER SET 与结尾分号 ;。

无法自动获取 SIZE 的 redo 文件仍写入记录，并在文件尾部追加英文提示，便于人工干预。

生成成功时屏幕输出形如：

Control file rebuild SQL generated: rectl_ORCL_20260727151150.sql

9.3 rdba <hex>

把 RDBA 值拆解为 Oracle File# 和 Block#（高 10 位 = File#，低 22 位 = Block#）。

OBET> rdba 0x00400000
rdba 0x00400000 (4194304)
File#: 1
Block#: 0

9.4 getrdba <rfile#> <block#>

根据 rfile# 和 block# 计算 RDBA 值（rdba 的逆运算）。

OBET> getrdba 1 1
getrdba:
  rfile#: 1
  block#: 1
  RDBA:   0x00400001 (4194305)

9.5 dump_undo [file N] [block M]

从 undo$ 段读取每条 UNDO 记录的 name 和 status$。默认 file 1 block 224（Oracle 某些版本 undo$ segment header 位置）。

OBET> dump_undo
OBET> dump_undo file 1 block 224

OBET> dump_undo file 1 block 224
==================================================
  DUMP UNDO$ - File#=1 (E:/CC/obet/dbf/SYSTEM01.DBF), Block=224
==================================================
Segment header kcbh.rdba=0x004000E0 => Oracle file#=1, block#=224 (listfile idx=1)
Reading undo$ segment header from file #1, block 224...
Segment header first 16 bytes (kcbh): 10 A2 00 00 E0 00 40 00 1A 02 00 00 00 00 01 04 
Found extent 0: rdba_block=225, size=7 blocks (covers blocks 225-231)
Data blocks to scan (7 total): 225 226 227 228 229 230 231 
US#=0    NAME=SYSTEM                          STATUS$=3  TS#=0   (system rollback segment)
US#=1    NAME=_SYSSMU1_3450900144$            STATUS$=2  TS#=2
US#=2    NAME=_SYSSMU2_2386332601$            STATUS$=2  TS#=2
...
Summary: scanned 7 blocks, extracted 21 rows from undo$.

9.6 patch_scn Linux 需授权

直接修改 Oracle 进程内存中的 SCN 字段。仅在 Linux 构建中可用。

10. 会话 / 杂项

10.1 license

显示当前许可证状态、硬件ID、到期时间。

OBET> license
========================================
         OBET License Information
========================================
Your Hardware ID: F443C4B31A04E56FDC6D9310C1648AC700946AC5269DF2F6DBE8507FDC704812
License Status: AUTHORIZED
Expiry Time:    2030-01-01 23:00:00

10.2 spool <file> | off

把后续输出同时写入指定文件；spool off 停止。

OBET> spool dbv_session.log
OBET> dbv
OBET> spool off

11. 常见问题

Q1：Oracle 正在使用时能不能直接读取数据文件？

可以。Windows 下 OBET 以 FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE 共享模式打开文件，Oracle 进程独占持有时 OBET 仍能读取。

Q2：如何切换数据文件？

先 open listfile.txt 加载列表，再用 set file N（或任意命令中的 file N 子句）切换。

Q3：写命令报 “license invalid / expired / hwid mismatch”？

授权与当前主机 HWID 绑定、存在有效期。用 license 命令查看当前授权状态，联系维护者重新签发 license.dat。

Q4：forcecopy 与普通拷贝区别？

普通跨文件操作要求源块能正常读取；forcecopy 跳过 IO 失败的位置并填 0，专为磁盘部分损坏的应急场景设计，目标文件保持原始 blocksize 和块数。

Q5：p kcvfh.kcvfhhdr.kccfhtyp 为什么报错？

print 仅支持一级字段访问（如 p kcvfh.kcvfhhdr），不支持二级（如 p kcvfh.kcvfhhdr.kccfhtyp）。

Q6：build block 和 repair block 区别？

build block N,M 是从无到有构造一个 Oracle 空块（填 0×00 + 初始化 kcbh/rdba），写入目标文件时需人工确认覆盖；适合块数据完全丢失的场景。

repair block 是读取目标块后原地修复 seq_kcbh、tailchk、checksum 三项，不改变块内容本身；适合块内容完好但校验值损坏的场景。

联系：手机/微信(+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少了一块盘

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 碎片扫描工具)进行碎片扫描,恢复出来数据文件

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;

数据库已更改。

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

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

标题：Oracle Block Edit Tool (obet) 功能增强–2026.07

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

数据块编辑工具Oracle bbed升级版obet(Oracle Block Edit Tool)， 基于ai编程的强大，根据近期恢复的需求情况，我对一些功能进行了升级，整体功能

这个是当硬件有损坏，普通拷贝报错的时候，使用该命令最大限度拷贝数据
extend file N这个是解决ORA-01200故障(一般是由于异常断电，或者文件系统恢复之后），数据文件实际大小小于文件头记录大小
parse_ctl这个是直接解析control，并且生成创建控制文件语句，主要为了解决在oracle数据库无法mount的情况下，重建控制文件容易遗漏数据文件导致oracle后续open之后缺失部分数据文件而引起的各种故障风险
dump_undo这个主要是在数据库open的过程中遭遇到undo回滚段异常，需要屏蔽回滚段时候，需要知道回滚段名称，这个命令可以直接获取
通过set endian big/little命令来实现全面支持大小字节序

linux平台还增加了patch_scn功能
这个功能是以前直接的patch_scn小工具Patch_SCN for Linux 功能完善中的，现在整合到了obet里面

完善了各种命令的提示

---

最近几天的实战操作
修改文件头scn

---

dbv检查aix平台数据文件

---

将来根据需求和客户实战情况，会进一步完善功能和修复bug

• 使用deepseek进行Oracle恢复,引起重大故障
• OraFHR快速open被勒索加密破坏的Oracle数据库
• Oracle故障第一现场被恢复混乱的数据库恢复
• .wman扩展名勒索mysql数据库恢复
• .[xueyuanjie@onionmail.org].AIR勒索加密数据库恢复
• 在生产环境错误执行dd命令破坏asm磁盘故障恢复
• 记录一次win删除数据文件完美恢复案例
• dd破坏包含50多个pdb的asm 磁盘组恢复
• 记录一次国产数据库被rm -rf /*删除的救援过程
• Oracle数据库被勒索加密一键open工具–OraFHR
• exp dmp导入报IMP-00098: INTERNAL ERROR: impgst2故障处理
• aix环境写入大文件设置combehin提高效率

]]>

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

标题：Oracle 19c 202607补丁（RUs+OJVM）-19.32

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

参考：Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases KA958

联系：手机/微信(+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> 

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

联系：手机/微信(+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回滚段异常，对异常回滚段进行处理，然后导出数据完成本次恢复工作

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

标题：ORA-00314: log 3 of thread 1, expected sequence# N doesn’t match 0

作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有朋友咨询一个Oracle数据库由于断电无法启动的问题,最初错误是一个非常常见的ORA-01113 ORA-01110错误

Tue Jul 21 15:38:12 2026
ALTER DATABASE OPEN
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_4632.trc:
ORA-01113: 文件 2 需要介质恢复
ORA-01110: 数据文件 2: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSAUX01.DBF'
ORA-1113 signalled during: ALTER DATABASE OPEN...
Tue Jul 21 15:38:12 2026
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_m000_4948.trc:
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO01.LOG'
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_m000_4948.trc:
ORA-00314: log 2 of thread 1, expected sequence# 6890 doesn't match 0
ORA-00312: online log 2 thread 1: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG'
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_m000_4948.trc:
ORA-00314: log 3 of thread 1, expected sequence# 6891 doesn't match 0
ORA-00312: online log 3 thread 1: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO03.LOG'

把数据文件拿到本地之后,尝试执行recover database操作

SQL> recover database;
ORA-00283: 恢复会话因错误而取消
ORA-00314: 日志 3 (用于线程 1) 要求的 sequence# 6891 与 0 不匹配
ORA-00312: 联机日志 3 线程 1: 'H:\BAIDUNETDISK\ORCL\REDO03.LOG'

ORA-00314 ORA-00312这个错误比较常见,但是直接提示要求的 sequence# 6891 与 0 不匹配（后面不匹配的是0）的情况不常见.使用winhex打开redo文件

SQL> @rectl

CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS  NOARCHIVELOG
*
ERROR at line 1:
ORA-01503: CREATE CONTROLFILE failed
ORA-01229: data file 1 is inconsistent with logs
ORA-01110: data file 1: 'H:\BAIDUNETDISK\ORCL\SYSTEM01.DBF'

由于redo异常导致noresetlogs方式重建ctl报ORA-01229错误.对于这样的情况使用resetlogs方式重建成功,然后强制打开库

SQL> recover database using backup controlfile;
ORA-00279: change 178744591 generated at 07/18/2026 18:55:48 needed for thread
1
ORA-00289: suggestion :
C:\APP\XFF\PRODUCT\11.2.0.1\DBHOME_1\RDBMS\ARC0000006891_1176155303.0001
ORA-00280: change 178744591 for thread 1 is in sequence #6891


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
H:\BAIDUNETDISK\ORCL\REDO03.LOG
ORA-00339: 归档日志未包含任何重做
ORA-00334: 归档日志: 'H:\BAIDUNETDISK\ORCL\REDO03.LOG'


SQL> recover database using backup controlfile;
ORA-00279: change 178744591 generated at 07/18/2026 18:55:48 needed for thread
1
ORA-00289: suggestion :
C:\APP\XFF\PRODUCT\11.2.0.1\DBHOME_1\RDBMS\ARC0000006891_1176155303.0001
ORA-00280: change 178744591 for thread 1 is in sequence #6891


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
H:\BAIDUNETDISK\ORCL\REDO02.LOG
ORA-00339: 归档日志未包含任何重做
ORA-00334: 归档日志: 'H:\BAIDUNETDISK\ORCL\REDO02.LOG'


SQL> E:\APP\ADMINISTRATOR\ORADATA\ORCL\REDO02.LOG
SP2-0734: unknown command beginning "E:\APP\ADM..." - rest of line ignored.
SQL> recover database using backup controlfile;
ORA-00279: change 178744591 generated at 07/18/2026 18:55:48 needed for thread
1
ORA-00289: suggestion :
C:\APP\XFF\PRODUCT\11.2.0.1\DBHOME_1\RDBMS\ARC0000006891_1176155303.0001
ORA-00280: change 178744591 for thread 1 is in sequence #6891


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
H:\BAIDUNETDISK\ORCL\REDO01.LOG
ORA-00310: 归档日志包含序列 6892; 要求序列 6891
ORA-00334: 归档日志: 'H:\BAIDUNETDISK\ORCL\REDO01.LOG'

SQL> recover database using backup controlfile until cancel;
ORA-00279: change 178744591 generated at 07/18/2026 18:55:48 needed for thread
1
ORA-00289: suggestion :
C:\APP\XFF\PRODUCT\11.2.0.1\DBHOME_1\RDBMS\ARC0000006891_1176155303.0001
ORA-00280: change 178744591 for thread 1 is in sequence #6891


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel
ORA-10879: error signaled in parallel recovery slave
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'H:\BAIDUNETDISK\ORCL\SYSTEM01.DBF'


SQL> alter database open resetlogs;

Database altered.

然后使用expdp导出数据,提供dmp文件,完成本次恢复任务