Oracle数据库文件变成32k故障恢复--惜分飞

最近一个客户数据库重启系统之后,数据文件大小变为了32kb,我接手的不是第一现场(客户那边尝试了rman还原操作),查看alert日志,数据库最初报错

Wed Jun 18 13:09:23 2025

alter database open

Block change tracking file is current.

Read of datafile 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.DBF' (fno 14) header failed with ORA-01210

Hex dump of (file 14, block 1) in trace file d:\app\administrator\diag\rdbms\ORCL\ORCL\trace\ORCL_ora_11208.trc

Corrupt block relative dba: 0x03800001 (file 14, block 1)

Completely zero block found during datafile header read

Rereading datafile 14 header failed with ORA-01210

Hex dump of (file 14, block 1) in trace file d:\app\administrator\diag\rdbms\ORCL\ORCL\trace\ORCL_ora_11208.trc

Corrupt block relative dba: 0x03800001 (file 14, block 1)

Completely zero block found during datafile header read

Errors in file d:\app\administrator\diag\rdbms\ORCL\ORCL\trace\ORCL_ora_11208.trc:

ORA-01122: 数据库文件 14 验证失败

ORA-01110: 数据文件 14: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.DBF'

ORA-01210: 数据文件标头发生介质损坏

ORA-1122 signalled during: alter database open...

Wed Jun 18 13:09:23 2025

Checker run found 1 new persistent data failures

客户那边不知道做了什么操作之后报错（初步估计是把14号文件重命名了）

Thu Jun 19 16:04:19 2025

alter database open

Thu Jun 19 16:04:21 2025

Errors in file d:\app\administrator\diag\rdbms\ORCL\ORCL\trace\ORCL_dbw0_13000.trc:

ORA-01157: ????/?????? 14 - ??? DBWR ????

ORA-01110: ???? 14: 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.DBF'

ORA-27041: ??????

OSD-04002: 无法打开文件

O/S-Error: (OS 2) 系统找不到指定的文件。

Errors in file d:\app\administrator\diag\rdbms\ORCL\ORCL\trace\ORCL_ora_12328.trc:

ORA-03113: 通信通道的文件结尾

ORA-3113 signalled during: alter database open...

根据客户反馈14号文件变成了32kb,就是被重命名的.bak文件

32k

这其中有一个bak0618是通过rman还原出来的（备份中无有效的14号文件备份，还原出来的为该文件初始化创建大小）

Thu Jul 07 16:57:05 2022

alter tablespace wasion add datafile 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.dbf' size 10g autoextend on

Completed: alter tablespace wasion add datafile 'D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.dbf' size 10g autoextend on

2025-06-26_101717_568

基于当前情况,可以确认该文件异常,而且没有有效的rman备份.通过分析备份脚本,发现每个备份集1个数据文件,而且没有压缩，并按照10g进行分割为多个文件

QQ20250626-095824

这些本身没有问题,脚本的后面有直接通过系统级别命令删除两天之前的备份文件

QQ20250626-100105

这里有一个问题,由于磁盘空间不足,导致部分备份不成功,但是系统级别删除操作依旧正常进行,导致以前有效的备份被删除,后面的备份又没有成功（这个是本次该文件无法还原的主要原因）,慎重提醒,rman备份尽量使用rman本身的策略来管理不要使用系统命令来维护备份策略,基于这样的情况,可以使用反删除命令找出来了一些该文件的备份集,并注册到控制文件中

RMAN> list backup of datafile 14;

备份集列表

===================

BS 关键字类型 LV 大小设备类型经过时间完成时间

------- ---- -- ---------- ----------- ------------ ----------

35251 Incr 0 10.89G DISK 00:01:20 15-6月 -25

备份集 35251 中的数据文件列表

文件 LV 类型 Ckp SCN Ckp 时间名称

---- -- ---- ---------- ---------- ----

14 0 Incr 758850903 15-6月 -25 D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.DBF

备份集副本号 2 属于备份集 35251

设备类型经过时间完成时间压缩标记

----------- ------------ ---------- ---------- ---

DISK 00:01:20 26-6月 -25 NO TAG20250615T220003

备份集 35251 副本号 2的备份片段列表

BP 关键字 Pc# 状态段名称

------- --- ----------- ----------

78307 1 AVAILABLE H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1

78308 2 AVAILABLE H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_2_1

BS 关键字类型 LV 大小设备类型经过时间完成时间

------- ---- -- ---------- ----------- ------------ ----------

35266 Incr 0 1.81G DISK 00:00:00 17-6月 -25

备份集 35266 中的数据文件列表

文件 LV 类型 Ckp SCN Ckp 时间名称

---- -- ---- ---------- ---------- ----

14 Full 759283192 17-6月 -25 D:\APP\ADMINISTRATOR\ORADATA\ORCL\WASION08.DBF

备份集副本号 1 属于备份集 35266

设备类型经过时间完成时间压缩标记

----------- ------------ ---------- ---------- ---

DISK 00:00:00 26-6月 -25 NO TAG20250617T220049

备份集 35266 副本号 1的备份片段列表

BP 关键字 Pc# 状态段名称

------- --- ----------- ----------

1 DELETED <---缺少一个备份集文件

78309 2 AVAILABLE H:\BAIDUNETDISK\202506191452\L0_ORCL_20250617_79022_5E3S94MC_2_1

尝试rman还原这些备份文件

RMAN> run

2> {

3> SET NEWNAME FOR DATAFILE 14 to 'H:\BaiduNetdisk\202506191452\14.dbf';

4> restore datafile 14;

5> }

正在执行命令: SET NEWNAME

启动 restore 于 26-6月 -25

使用通道 ORA_DISK_1

通道 ORA_DISK_1: 正在开始还原数据文件备份集

通道 ORA_DISK_1: 正在指定从备份集还原的数据文件

通道 ORA_DISK_1: 将数据文件 00014 还原到 H:\BAIDUNETDISK\202506191452\14.DBF

通道 ORA_DISK_1: 正在还原段 1 (属于 2)

通道 ORA_DISK_1: 正在读取备份片段 H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: restore 命令 (在 06/26/2025 08:35:53 上) 失败

ORA-19870: 还原备份片段 H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1 时出错

ORA-00600: 内部错误代码, 参数: [krbvalmrange_badfno], [1], [14], [], [], [], [], [], [], [], [], []

alert日志报错

Thu Jun 26 08:25:26 2025

Checker run found 39 new persistent data failures

Thu Jun 26 08:35:51 2025

Datafile rdba reconstruction error, expected block greater than 804966, got 322047 for datafile 14

Corrupt block 804352 found during reading backup piece,

file=H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1, corr_type=4

Reread of blocknum=804352, file=H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1. found valid data

Datafile rdba reconstruction error, expected block greater than 324095, got 55516 for datafile 14

Corrupt block 806400 found during reading backup piece,

file=H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1, corr_type=4

Reread of blocknum=806400, file=H:\BAIDUNETDISK\202506191452\L0_ORCL_20250615_78847_VV3S3RQP_1_1. found valid data

Errors in file C:\APP\XFF\diag\rdbms\ORCL\orcl\trace\orcl_ora_19208.trc (incident=177):

ORA-00600: 内部错误代码, 参数: [krbvalmrange_badfno], [1], [14], [], [], [], [], [], [], [], [], []

Incident details in: C:\APP\XFF\diag\rdbms\ORCL\orcl\incident\incdir_177\orcl_ora_19208_i177.trc

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Thu Jun 26 08:35:52 2025

后面通过工具分析以及ORA-600 krbvalmrange_badfno的错误,基本上可以确认在反删除恢复的备份集文件中部分rman的block是其他数据文件的,从而导致无法正常还原.基于这种情况,通过工具进行强制还原出来部分14号数据文件的block

QQ20250626-101208

然后再通过磁盘级别碎片,找到部分没有覆盖的block

suip

把rman备份中强制抽取的部分block和底层碎片恢复的没有覆盖的block组合到一起,通过检测确认恢复了大概2/3的数据

QQ20250626-101601

基于恢复的该文件和这个表空间的其他文件一起,使用dul工具把数据恢复到新库中,最大限度完成本次数据的抢救工作.

本次故障本不该发生,或者说发生不该如此严重:
1. rman备份采用系统级别维护策略,在备份没有成功的情况下依旧通过系统层面删除文件,导致故障文件无一份有效备份
2. 发生故障之后,没有保护现场的意识:对于32kb的数据文件所在磁盘进行了大量的写入操作（近1T的数据文件直接在本盘做了一次拷贝,还有rman默认写入到了以前文件所在位置）