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

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:分享一例运行在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 碎片扫描工具) 使用说明)进一步扫描
orascan


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

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


OBET-Oracle Block Editor Tool使用说明

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题: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
授权说明写操作(modify / corrupt / repair / copy / merge / forcecopy / extend / patch_scn 等需要修改磁盘内容的命令)需要先 set mode edit 进入编辑模式,并在出现确认提示时输入 YYES 才会执行写入。 backup 仅复制块到本地目录,不需授权。未授权时仅允许只读命令。

2. 开发者信息

姓名 XiFenFei
电话 +86-17813235971
邮箱 dba@xifenfei
QQ 107644445
微信 17813235971
网站 https://www.xifenfei.com

反馈授权 / 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 上下文。所有读写命令都依赖当前的 filenameblocksizeblockoffsetcountendian 等参数。

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>

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

参数 取值 说明
filename 文件路径 当前操作的目标文件
file 整数 N 切换到已加载列表中第 N 个文件
blocksize 2048 / 4096 / 8192 / 16384 / 32768 Oracle 块大小
block 整数 当前块号
offset 整数(块内偏移) 块内起始偏移
count 整数 dump/modify 的字节数
mode browse / edit 交互模式(默认 browse)
endian big / little 多字节字段字节序
OBET> set filename /u01/oradata/users01.dbf
OBET> set blocksize 8192
OBET> set block 100
OBET> set endian big

4.4 show

显示当前上下文所有参数,包括 Modebrowse / edit)、FilenameFile#Block#BlocksizeOffsetCountEndian 等。

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 不带参数可打印完整清单):

字段 含义
kcvfhhdr 文件头描述符
kcvfhrfn 相对文件号
kcvfhrdb DBID
kcvfhcrs 创建 SCN
kcvfhcrt 创建时间
kcvfhrls Resetlogs SCN
kcvfhcrs Creation SCN
kcvfhbsc Backup SCN
kcvfhbti Backup table info
kcvfhbth Backup table header
kcvfhbcp Backup Checkpoint
kcvfhbhz Backup status
kcvfhccc Change count
kcvfhckp 完整 Checkpoint
kcvfhcpc Checkpoint count
kcvfhprs / kcvfhprc / kcvfhprfs / kcvfhrfs 恢复相关字段
kcvfhtsn / kcvfhtln / kcvfhtnm 表空间号 / 名长度 / 名
kcvfhrlc / kcvfhrts / kcvfhtrt Resetlogs 计数 / 时间戳 / 总复位次数
kcvfhxcd 扩展 Checkpoint
kcvfhsta Fuzzy 状态
kcvfhofb / kcvfhnfb Offset bytes / Next offset bytes
kcvfhbfh Backup file header block
kcvfhafs Auxiliary recovery
tailchk 块尾校验
仅支持一级结构访问,如 p kcvfh.kcvfhhdr,不支持 p kcvfh.kcvfhhdr.kccfhtyp

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 校验。扫描结果自动保存到日志文件:

  • dbvdbv_yyyymmddhhmmss.log
  • dbv file Ndbv_file_N_yyyymmddhhmmss.log
  • dbv file N block Mdbv_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] 需授权

写入十六进制字节。写入后自动重新计算 tailchkchecksum。需先 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_kcbhtailchkchecksum
  • 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 需授权

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

子命令 语法 说明
copy data copy data <src> to <dest> 跨文件字节范围拷贝
copy block copy block <file,block> to <file,block> 整块拷贝
copy chkscn copy chkscn file N to file M 拷贝数据文件头 Checkpoint SCN 信息
copy resetlogscn copy resetlogscn file N to file M 拷贝 Resetlogs 信息

<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
不可逆操作覆盖原文件块,请先 backup

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 进入编辑模式

开始写入前需输入 YYES 二次确认(忽略大小写)。

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.
注意扩展操作不可逆,请在执行前做好文件备份。若文件实际大小大于预期,Oracle 内部可能已扩展但文件头未更新,请人工核实后处理。

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) 元组写法)、DATAFILECHARACTER 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 记录的 namestatus$。默认 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 构建中可用。

用法 作用
patch_scn spid 列出本机 Oracle LOCAL=YES 进程
patch_scn addr 通过 sqlplus 辅助获取 SCN 在进程内存中的地址
patch_scn [<spid>] [<addr>] <newval> 把目标进程 SCN 改写为 newval

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 blockrepair block 区别?

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

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

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

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:几乎动用了所有手段的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少了一块盘
lost_disk


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

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

通过对恢复出来的所有数据文件使用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 碎片扫描工具)进行碎片扫描,恢复出来数据文件
orascan


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

4. 使用obet最近开发的merge功能对文件进行整合,类似操作
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;

数据库已更改。

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

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

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

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

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

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


主要增加了上述框起来的功能
forcopy file N to 这个是当硬件有损坏,普通拷贝报错的时候,使用该命令最大限度拷贝数据
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里面
obet_patch_scn
完善了各种命令的提示
obet_hint

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

dbv检查aix平台数据文件
obet_dbv

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

Oracle 19c 202607补丁(RUs+OJVM)-19.32

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:Oracle 19c 202607补丁(RUs+OJVM)-19.32

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

Release Database Update   GI Update Windows Bundle Patch
JUL2026 (19.32.0.0.0) 39472050   39467003 39418910
APR2026 (19.31.0.0.0) 39034528   39036936 38818049
JAN2026 (19.30.0.0.0) 38632161   38629535 38597735
OCT2025 (19.29.0.0.0) 38291812   38298204 38111211
JUL2025 (19.28.0.0.0) 37960098   37957391 37962957
APR2025 (19.27.0.0.0) 37642901   37641958 37532350
JAN2025 (19.26.0.0.0) 37260974   37257886 37486199
OCT2024 (19.25.0.0.0) 36912597   36916690 36878821
JUL2024 (19.24.0.0.0) 36582781   36582629 36521936
APR2024 (19.23.0.0.0) 36233263   36233126 36219938
JAN2024 (19.22.0.0.0) 35943157   35940989 35962832
OCT2023 (19.21.0.0.0) 35643107   35642822 35681552
JUL2023 (19.20.0.0.0) 35320081   35319490 35348034
APR2023 (19.19.0.0.0) 35042068   35037840 35046439
JAN2023 (19.18.0.0.0) 34765931   34762026 34750795
Oct2022 (19.17.0.0.0) 34419443   34416665 34468114
JUL2022 (19.16.0.0.0) 34133642   34130714 34110685
APR2022 (19.15.0.0.0) 33806152   33803476 33829175
JAN2022 (19.14.0.0.0) 33515361   33509923 33575656
OCT2021(19.13.0.0.0) 33192793   33182768 33155330
JUL2021 (19.12.0.0.0) 32904851   32895426 32832237
APR2021 (19.11.0.0.0) 32545013   32545008 32409154
JAN2021 (19.10.0.0.0) 32218454   32226239 32062765
OCT2020 (19.9.0.0.0) 31771877   31750108 31719903
JUL2020 (19.8.0.0.0) 31281355   31305339 31247621
APR2020 (19.7.0.0.0) 30869156   30899722 30901317
JAN2020 (19.6.0.0.0) 30557433   30501910 30445947
OCT2019 (19.5.0.0.0) 30125133   30116789 30151705
JUL2019 (19.4.0.0.0) 29834717   29708769 -
APR2019 (19.3.0.0.0) 29517242   29517302 -

 

Release OJVM Update OJVM + DB Update OJVM + GI Update
JUL2026 (19.32.0.0.260721) 39222882 39618649 39618711
APR2026 (19.31.0.0.260421) 38906621 39062931 39062956
JAN2026 (19.30.0.0.260120) 38523609 38658587 38658588
OCT2025 (19.29.0.0.251021) 38194382 38273545 38273558
JUL2025 (19.28.0.0.250715) 37847857 37952354 37952382
APR2025 (19.27.0.0.250415) 37499406 37591483 37591516
JAN2025 (19.26.0.0.250121) 37102264 37262172 37262208
OCT2024 (19.25.0.0.241015) 36878697 36866623 36866740
JUL2024 (19.24.0.0.240716) 36414915 36522340 36522439
APR2024 (19.23.0.0.240416) 36199232 36209492 36209493
JAN2024 (19.22.0.0.240116) 35926646 36031426 36031453
OCT2023 (19.21.0.0.231017) 35648110 35742413 35742441
JUL2023 (19.20.0.0.230718) 35354406 35370174 35370167
APR2023 (19.19.0.0.230418) 35050341 35058163 35058172
JAN2023 (19.18.0.0.230117) 34786990 34773489 34773504
OCT2022 (19.17.0.0.221018) 34411846 34449114 34449117
JUL2022 (19.16.0.0.220719) 34086870 34160831 34160854
APR2022 (19.15.0.0.220419) 33808367 33859194 33859214
JAN2022 (19.14.0.0.220118) 33561310 33567270 33567274
OCT2021 (19.13.0.0.211019) 33192694 33248420 33248471
JUL2021 (19.12.0.0.210720) 32876380 32900021 32900083
APR2021 (19.11.0.0.210420) 32399816 32578972 32578973
JAN2021 (19.10.0.0.210119) 32067171 32126828 32126842
OCT2020 (19.9.0.0.201020) 31668882 31720396 31720429
JUL2020 (19.8.0.0.200714) 31219897 31326362 31326369
APR2020 (19.7.0.0.200414) 30805684 30783543 30783556
JAN2020 (19.6.0.0.200114) 30484981 30463595 30463609
OCT2019 (19.5.0.0.191015) 30128191 30133124 30133178
JUL2019 (19.4.0.0.190716) 29774421 29699079 29699097
APR2019 (19.3.0.0.190416) 29548437 29621253 29621299

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

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

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题: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 故障

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:快速处理 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回滚段异常,对异常回滚段进行处理,然后导出数据完成本次恢复工作

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

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

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

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

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


对应的alert日志错误

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文件
seq0


这里比较明显的redo的sequence变为了0,初步看感觉是被触发了logfile clear操作导致(我查找了故障前后的alert日志确认没有人工clear操作redolog),但是数据库实例恢复刚好需要这个redo,因此数据库无法正常打开,基于这种情况,考虑重建ctl,然后强制打开库

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文件,完成本次恢复任务

记录block 0损坏,数据文件大量坏块,使用不当数据库版本恢复等各种操作之后的故障处理

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:记录block 0损坏,数据文件大量坏块,使用不当数据库版本恢复等各种操作之后的故障处理

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

今天一个恢复行业的朋友让我帮忙看一个oracle故障,说是vmdk文件被加密(加密破坏的很少),然后他从里面恢复出来了oracle的数据库文件,客户那边拿到数据文件然后说有三个文件头(被重命名为.bak)损坏了,无法打开数据库,让我这边给他们分析处理.分析他们说的被破坏文件,确实有损坏(初步看是block 0)
block0


使用oracle自带的dbv进行检测

C:\Users\XFF>dbv file=H:\BaiduNetdisk\D\SYSTEM06.DBF.bak

DBVERIFY: Release 11.2.0.4.0 - Production on 星期五 7月 3 21:06:28 2026

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


DBV-00107: 未知标头格式 (85) (1311029317)

由于block 0损坏,oracle自带的dbv无法检测,使用obet的dbv功能进行检测(obet实现对数据文件坏块检测功能)

===============================================
DBV (Data Block Verification) Report
Started: 2026-07-03 21:04:22
Block Size: 8192 bytes
Target File: ALL files in listfile
===============================================

File #1: H:\BaiduNetdisk\D\SYSTEM06.DBF.bak (12801 blocks) - Started: 2026-07-03 21:04:22
File #1: rfile=19 (0x00000013)  header_block_num=12800 (0x00003200)  filesize_status:OK
file 1, block 0: rdba error (expected 0, got 4083969), bad block
  File #1 completed: 0 all zero, 0 soft corrupted, 0 tailchk error, 0 checksum error, 1 rdba error

File #1: H:\BaiduNetdisk\D\TSP_XXXXS06.DBF.bak (4194303 blocks) - Started: 2026-07-03 21:04:22
File #1: rfile=24 (0x00000018)  header_block_num=4194302 (0x003FFFFE)  filesize_status:OK
file 1, block 0: rdba error (expected 0, got 1367117), bad block
  File #1 completed: 0 all zero, 0 soft corrupted, 0 tailchk error, 0 checksum error, 1 rdba error

File #1: H:\BaiduNetdisk\D\TSP_XXXXS07.DBF.bak (1933313 blocks) - Started: 2026-07-03 21:04:42
File #1: rfile=25 (0x00000019)  header_block_num=1933312 (0x001D8000)  filesize_status:OK
file 1, block 0: rdba error (expected 0, got 2445572), bad block
  File #1 completed: 0 all zero, 0 soft corrupted, 0 tailchk error, 0 checksum error, 1 rdba error


DBV completed at: 2026-07-03 21:04:51
===============================================
DBV Summary:
Total blocks checked: 6140414
Total all zero blocks found: 0
Total all rdba error blocks found: 3
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: 3
Execution time: 29.00 seconds
===============================================

通过检测确认这三个数据文件就是block 0损坏其他的数据块是ok的.检查其他数据文件发现有一个数据文件有近2w个坏块

DBVERIFY: Release 11.2.0.4.0 - Production on 星期五 7月 3 12:55:08 2026

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


DBVERIFY - 开始验证: FILE = H:\BAIDUNETDISK\ORCL\TSP_XXXX.DBF
页 409601 标记为损坏
Corrupt block relative dba: 0x01864001 (file 6, block 409601)
Bad header found during dbv: 
Data in bad block:
 type: 219 format: 1 rdba: 0xdf6e738f
 last change scn: 0xd7ed.50be2d8b seq: 0x44 flg: 0x52
 spare1: 0x39 spare2: 0x92 spare3: 0xb5c5
 consistency value in tail: 0x6e7debc9
 check value in block header: 0x6d54
 block checksum disabled

………………
DBVERIFY - 验证完成

检查的页总数: 4194302
处理的页总数 (数据): 1842107
失败的页总数 (数据): 0
处理的页总数 (索引): 2143604
失败的页总数 (索引): 0
处理的页总数 (其他): 13763
处理的总页数 (段)  : 0
失败的总页数 (段)  : 0
空的页总数: 437
标记为损坏的总页数: 194391
流入的页总数: 2
加密的总页数        : 0
最高块 SCN            : 1869110545 (9.1869110545)

对于这个文件,由于客户有部分rman备份,尝试通过备份找出来这个文件历史文件

RMAN> run
2> {
3> set newname for datafile 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\TSP_XXXX.DBF' 
4>   to 'H:\BaiduNetdisk\orcl\TSP_XXXX.DBF_rman';
5> restore datafile 6;
6> }

正在执行命令: SET NEWNAME

启动 restore 于 03-7月 -26
使用通道 ORA_DISK_1

通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集还原的数据文件
通道 ORA_DISK_1: 将数据文件 00006 还原到 H:\BaiduNetdisk\orcl\TSP_XXXX.DBF_rman
通道 ORA_DISK_1: 正在读取备份片段 H:\BAIDUNETDISK\BACKDB\FULLDB_ORCL_20250704_TC3TM4LJ_1_1.BAK.RESTORED0
通道 ORA_DISK_1: ORA-19870: 还原备份片段 H:\BAIDUNETDISK\BACKDB\FULLDB_ORCL_20250704_TC3TM4LJ_1_1.BAK.RESTORED0 时出错
ORA-19599: 块编号 1065697 已在 backup piece H:\BAIDUNETDISK\BACKDB\FULLDB_ORCL_20250704_TC3TM4LJ_1_1.BAK.RESTORED0 中损 坏

故障转移到上一个备份

通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集还原的数据文件
通道 ORA_DISK_1: 将数据文件 00006 还原到 H:\BaiduNetdisk\orcl\TSP_XXXX.DBF_rman
通道 ORA_DISK_1: 正在读取备份片段 H:\BAIDUNETDISK\BACKDB\FULLDB_ORCL_20250703_T33TJG9L_1_1.BAK
通道 ORA_DISK_1: ORA-19870: 还原备份片段 H:\BAIDUNETDISK\BACKDB\FULLDB_ORCL_20250703_T33TJG9L_1_1.BAK 时出错
ORA-19599: 块编号 95352 已在 backup piece H:\BAIDUNETDISK\BACKDB\FULLDB_ORCL_20250703_T33TJG9L_1_1.BAK 中损坏

故障转移到上一个备份

通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集还原的数据文件
通道 ORA_DISK_1: 将数据文件 00006 还原到 H:\BaiduNetdisk\orcl\TSP_XXXX.DBF_rman
通道 ORA_DISK_1: 正在读取备份片段 H:\BAIDUNETDISK\BACKDB\FULLDB_ORCL_20250702_SQ3TGRTU_1_1.BAK
通道 ORA_DISK_1: 段句柄 = H:\BAIDUNETDISK\BACKDB\FULLDB_ORCL_20250702_SQ3TGRTU_1_1.BAK 标记 = TAG20250702T000518
通道 ORA_DISK_1: 已还原备份片段 1
通道 ORA_DISK_1: 还原完成, 用时: 00:28:56
完成 restore 于 03-7月 -26

RMAN> exit

运气还不错,从备份里面找一份好的该文件的备份,然后通过使用该文件好的block替换最初损坏的block,实现该文件无坏块(由于这个文件比较靠前,而且已经写满,所以只差3天左右数据可能改变很小,因此可以采用这种替代方法最大限度恢复数据).数据文件检测和明显坏块处理完成,接下来开始打开数据库操作.
由于我这边的数据文件路径和原库的不一致,修改ctl中的datafile 路径报ORA-17503错误
rename


对于这些情况,通过修复block 0,然后尝试重命名数据文件成功

SQL> alter database rename file 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\TSP_XXX06.DBF' to 'H:\BaiduNetdisk\orcl\TSP_XXX06.DBF'
  2  ;

数据库已更改。

SQL> alter database rename file 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\TSP_XXX07.DBF' to 'H:\BaiduNetdisk\orcl\TSP_XXX07.DBF'
  2  ;

数据库已更改。

SQL> alter database rename file 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\SYSTEM06.DBF' to 'H:\BaiduNetdisk\orcl\SYSTEM06.DBF'
  2  ;

数据库已更改。

然后尝试打开数据库成功

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

数据库已更改。

尝试expdp导出数据,结果报UDE-22303

C:\Users\XFF>expdp "'/ as sysdba'" full=y dumpfile=expdp_0703_%U.dmp DIRECTORY=expdp_dir logfile=expdp_0703.log 
 parallel=4 compression=all EXCLUDE=STATISTICS,AUDIT

Export: Release 11.2.0.4.0 - Production on 星期五 7月 3 13:10:12 2026

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

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

UDE-22303: 操作产生了 ORACLE 错误 22303
OCI-22303: 未找到类型 "SYS"."KU$_STATUS1020"

正常打开的数据库,没有明显坏块,出现这个错误,理论上不太应该,怀疑是客户的版本问题,查询组件版本
v1


确认该数据库版本可能是11.2.0.1而不是我现在看到的数据文件头为11.2.0.4,查询WRM$_DATABASE_INSTANCE,确认数据库之前版本是11.2.0.1.对于这种情况,直接简单的把compatible从11.2.0.4修改为11.2.0.0肯定不行,因为ctl,dbf,redo里面都写了11.2.0.4的信息
1. ctl报版本不匹配

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

Total System Global Area 3206836224 bytes
Fixed Size                  2180024 bytes
Variable Size             654314568 bytes
Database Buffers         2533359616 bytes
Redo Buffers               16982016 bytes
ORA-00201: ?????? 11.2.0.4.0 ? ORACLE ?? 11.2.0.0.0 ???
ORA-00202: ????: ''H:\BAIDUNETDISK\ORCL\CONTROL01.CTL''

2. 这种情况需要rectl,然后报dbf版本不对

CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS  NOARCHIVELOG
*
第 1 行出现错误:
ORA-01503: CREATE CONTROLFILE ??
ORA-01130: ??????? 11.2.0.4.0 ? ORACLE ?? 11.2.0.0.0 ???
ORA-01110: ???? 1: 'H:\BAIDUNETDISK\ORCL\SYSTEM01.DBF'

这种情况,dbf中的版本信息无法通过重建解决,只能使用obet工具修改,每个文件类似修改(Oracle数据块编辑工具( Oracle Block Editor Tool)-obet)

OBET> set file 25
filename set to: H:\BAIDUNETDISK\ORCL\TSP_XXXX07.DBF (file#25)

OBET> set offset 24
offset set to: 24

OBET> m 0000

Confirm modification:
File: H:\BAIDUNETDISK\ORCL\TSP_XXXX07.DBF
Block: 1
Offset: 24 (file offset: 0x00002018)
Original value: 0004
New value:      0000
Confirm? (Y/YES to proceed): y
Verification successful: Data written correctly.
Modified 2 bytes at offset 0x00002018 successfully.

OBET> sum apply

Confirm applying checksum:
File: H:\BAIDUNETDISK\ORCL\TSP_XXXX07.DBF
Block: 1
Offset in block: 16 (file offset: 0x00002010)
Original value: 0x94C3
New value:      0x94C7
Confirm? (Y/YES to proceed): y
Verification successful: Stored checksum matches calculated value (0x94C7).
Checksum applied successfully.

OBET>

然后重建ctl报redo版本不兼容ORA-00331

CREATE CONTROLFILE REUSE DATABASE "ORCL" NORESETLOGS  NOARCHIVELOG
*
第 1 行出现错误:
ORA-01503: CREATE CONTROLFILE 失败
ORA-00331: 日志版本 0.0.0.0.0 与 ORACLE 版本 11.2.0.0.0 不兼容
ORA-01517: 日志成员: 'H:\BAIDUNETDISK\ORCL\REDO01.LOG'

采用resetlogs方式重建(不读取redo信息),重建ctl成功,然后直接打开数据库

 37  CHARACTER SET AL32UTF8
 38  ;

控制文件已创建。

SQL> alter database open resetlogs;

数据库已更改。

然后expdp导出数据完成本次恢复任务

需要注意:dbv 检测controlfile可能不准

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:需要注意:dbv 检测controlfile可能不准

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

oracle dbv工具是Oracle数据库离线检测坏块的工具主要是用来检测数据文件坏块(物理和逻辑坏块),虽然在一定程度上面可以检测controlfile的坏块,但是不是特别准,在一次恢复案例中数据库启动报controlfile损坏,但是dbv检测是正常的
数据库在mount的过程中报controlfile 损坏ORA-00227
ctl


把控制文件从asm里面拷贝到文件系统,然后通过dbv进行检测,一切正常

[oracle@oracle1 ~]$ dbv blocksize=16384 file=/tmp/control01.ctl 

DBVERIFY: Release 11.2.0.4.0 - Production on Wed Jul 1 14:21:58 2026

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

DBVERIFY - Verification starting : FILE = /tmp/control01.ctl


DBVERIFY - Verification complete

Total Pages Examined         : 1312
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 395
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 917
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 4294967295 (65535.4294967295)

这个故障通过重建ctl,打开数据库成功