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

发表于 2026 年 7 月 3 日 由 惜分飞

今天一个恢复行业的朋友让我帮忙看一个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可能不准

发表于 2026 年 7 月 3 日 由 惜分飞

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,打开数据库成功

发表在 Oracle备份恢复 | 标签为 , , | 留下评论

达梦数据库redo异常强制拉库

发表于 2026 年 6 月 28 日 由 惜分飞

通过模拟事务不提交,并删除掉redo来模仿达梦数据库故障的恢复过程
模拟达梦事务并不提交直接abort掉库

[dmdba@xifenfei ~]$ disql SYSDBA/Oracle123@localhost:5236

Server[localhost:5236]:mode is normal, state is open
login used time : 5.575(ms)
disql V8
SQL> 
SQL> create table t1 as select * from dba_objects;
executed successfully
used time: 85.929(ms). Execute id is 601.
SQL> select count(1) from t1;

LINEID     COUNT(1)            
---------- --------------------
1          1067

used time: 2.106(ms). Execute id is 602.
SQL> delete from t1;
affect rows 1067

used time: 3.726(ms). Execute id is 603.
SQL> shutdown abort;
executed successfully
used time: 1.324(ms). Execute id is 0.

删除掉redo文件

[dmdba@xifenfei ~]$ cd /dmdb/data/DAMENG/
[dmdba@xifenfei DAMENG]$ rm -rf DAMENG0
DAMENG01.log  DAMENG02.log  
[dmdba@xifenfei DAMENG]$ rm -rf DAMENG0*.log

尝试启动达梦数据库

[dmdba@xifenfei bin]$ ./dmserver  /dmdb/data/DAMENG/dm.ini 
file dm.key not found, use default license!
version info: develop
csek2_vm_t = 9456
nsql_vm_t = 336
prjt2_vm_t = 176
ltid_vm_t = 272
nins2_vm_t = 1144
nset2_vm_t = 272
ndlck_vm_t = 192
ndel2_vm_t = 760
slct2_vm_t = 352
nli2_vm_t = 200
aagr2_vm_t = 312
pscn_vm_t = 416
dist_vm_t = 1000
DM Database Server 64 V8 03134284458-20251113-301923-20178 startup...
Normal of FAST
Normal of DEFAULT
Normal of RECYCLE
Normal of KEEP
Normal of ROLL
Database mode = 0, oguid = 0
/dmdb/data/DAMENG/DAMENG01.log not exist, can not startup

重命名现在的库文件,然后参考当时的创建库的init.log 进行重新初始化一个新库

[dmdba@xifenfei data]$ cat DAMENG_BAK/dminit_DAMENG_20260315093214.log 
start init database: V8, 2026-03-15 09:32:14
init params:
        db path: /dmdb/data/DAMENG
        db name: DAMENG
        auto overwrite: 0
        page size: 8192
        extent size: 16
        char_fix_storage: 0
        sql_log_forbid: 0
        secur_flag: 2
        enable mac: 0
        page checksum policy: 1
        time zone: +08:00
        string case sensitive: 1
        charset: 0
        page check mode: 3
        page check algorithm id: 0
        priv flag: 0
        env label: 0
        rlog enc flag: 0
        use new hash: 1
        blank pad mode: 0
        sec priv mode: 0
        huge with delta: 1
        rlog gen for huge: 1
        pseg_mgr_flag: 0
        auto_adj_para: 0

[dmdba@xifenfei data]$ dminit PATH=/dmdb/data/DAMENG  PAGE_SIZE=8 EXTENT_SIZE=16 
> LOG_SIZE=256 PORT_NUM=5236 CASE_SENSITIVE=Y CHARSET=0 DB_NAME=DAMENG INSTANCE_NAME=DMSERVER
> SYSDBA_PWD=Oracle123 SYSAUDITOR_PWD=Oracle123 RLOG_POSTFIX_NAME=log
initdb V8
db version: 0x7000d
file dm.key not found, use default license!
License will expire on 2026-11-13
Normal of FAST
Normal of DEFAULT
Normal of RECYCLE
Normal of KEEP
Normal of ROLL

 log file path: /dmdb/data/DAMENG/DAMENG/DAMENG01.log


 log file path: /dmdb/data/DAMENG/DAMENG/DAMENG02.log

write to dir [/dmdb/data/DAMENG/DAMENG].
create dm database success. 2026-06-27 23:40:17

正常启动这个新库并干净关闭

[dmdba@xifenfei bin]$ disql SYSDBA/Oracle123@localhost:5236

Server[localhost:5236]:mode is normal, state is open
login used time : 5.523(ms)
disql V8
SQL> shutdown normal
2   ;
executed successfully
used time: 1.417(ms). Execute id is 0.
SQL>

直接拷贝redo文件替换尝试启动

[dmdba@xifenfei bin]$ ./dmserver  /dmdb/data/DAMENG/dm.ini 
file dm.key not found, use default license!
version info: develop
csek2_vm_t = 9456
nsql_vm_t = 336
prjt2_vm_t = 176
ltid_vm_t = 272
nins2_vm_t = 1144
nset2_vm_t = 272
ndlck_vm_t = 192
ndel2_vm_t = 760
slct2_vm_t = 352
nli2_vm_t = 200
aagr2_vm_t = 312
pscn_vm_t = 416
dist_vm_t = 1000
DM Database Server 64 V8 03134284458-20251113-301923-20178 startup...
Normal of FAST
Normal of DEFAULT
Normal of RECYCLE
Normal of KEEP
Normal of ROLL
Database mode = 0, oguid = 0
License will expire on 2026-11-13
rfil grp log file error in (db_magic, permanent_magic), 
        log file /dmdb/data/DAMENG/DAMENG01.log is (475644558, 854749702), 
        dbfile is(92637567, 1763199417).
Floating point exception
[dmdba@xifenfei bin]$

提示db_magic和permanent_magic不匹配,使用dmmdf修改新库redo文件

[dmdba@xifenfei DAMENG]$ dmmdf type=1 FILE=SYSTEM.DBF
dmmdf V8
**********************************************************
1 db_magic=92637567
2 next_trxid=38064
3 pemnt_magic=1763199417
4 enable_page_check=3
**********************************************************
Please input which parameter you want to change(1-4), q to quit: Q

然后在使用dmmdf type=2 修改redo文件的db_magic和pemnt_magic修改之后,设置PSEG_RECV = 0，RLOG_CHECK_SPACE = 2尝试启动库

[dmdba@xifenfei bin]$ ./dmserver  /dmdb/data/DAMENG/dm.ini
file dm.key not found, use default license!
version info: develop
csek2_vm_t = 9456
nsql_vm_t = 336
prjt2_vm_t = 176
ltid_vm_t = 272
nins2_vm_t = 1144
nset2_vm_t = 272
ndlck_vm_t = 192
ndel2_vm_t = 760
slct2_vm_t = 352
nli2_vm_t = 200
aagr2_vm_t = 312
pscn_vm_t = 416
dist_vm_t = 1000
DM Database Server 64 V8 03134284458-20251113-301923-20178 startup...
Normal of FAST
Normal of DEFAULT
Normal of RECYCLE
Normal of KEEP
Normal of ROLL
Database mode = 0, oguid = 0
License will expire on 2026-11-13
file lsn: 49136
ndct db load finished, code:100
ndct fill fast pool finished
pseg_set_gtv_trxid_low next_trxid in mem:[40065]
pseg recv finished
nsvr_startup end.
uthr_pipe_create, create pipe[read:10, write:11]
uthr_pipe_create, create pipe[read:12, write:13]
uthr_pipe_create, create pipe[read:14, write:15]
uthr_pipe_create, create pipe[read:16, write:17]
uthr_pipe_create, create pipe[read:18, write:19]
uthr_pipe_create, create pipe[read:20, write:21]
uthr_pipe_create, create pipe[read:22, write:23]
uthr_pipe_create, create pipe[read:24, write:25]
uthr_pipe_create, create pipe[read:26, write:27]
uthr_pipe_create, create pipe[read:28, write:29]
uthr_pipe_create, create pipe[read:30, write:31]
uthr_pipe_create, create pipe[read:32, write:33]
uthr_pipe_create, create pipe[read:34, write:35]
uthr_pipe_create, create pipe[read:36, write:37]
uthr_pipe_create, create pipe[read:38, write:39]
uthr_pipe_create, create pipe[read:40, write:41]
aud sys init success.
aud rt sys init success.
systables desc init success.
ndct_db_load_info finished, code:100.
nsvr_process_before_open begin.
nsvr_process_before_open success.
SYSTEM IS READY.

查询拉起来库中的数据

[dmdba@xifenfei DAMENG]$ disql SYSDBA/Oracle123@localhost:5236

Server[localhost:5236]:mode is normal, state is open
login used time : 6.192(ms)
disql V8
SQL> select count(1) from t1;

LINEID     COUNT(1)            
---------- --------------------
1          1067

used time: 8.976(ms). Execute id is 601.
SQL>
发表在 达梦恢复 | 标签为 , | 留下评论