数据库文件变成32k故障恢复
惜分飞发表于 2025-06-26 02:26:02
联系：手机/微信(+86 17813235971) QQ(107644445)
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
最近一个客户数据库重启系统之后,数据文件大小变为了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文件
这其中有一个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
基于当前情况,可以确认该文件异常,而且没有有效的rman备份.通过分析备份脚本,发现每个备份集1个数据文件,而且没有压缩，并按照10g进行分割为多个文件
这些本身没有问题,脚本的后面有直接通过系统级别命令删除两天之前的备份文件
这里有一个问题,由于磁盘空间不足,导致部分备份不成功,但是系统级别删除操作依旧正常进行,导致以前有效的备份被删除,后面的备份又没有成功（这个是本次该文件无法还原的主要原因）,慎重提醒,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
然后再通过磁盘级别碎片,找到部分没有覆盖的block
把rman备份中强制抽取的部分block和底层碎片恢复的没有覆盖的block组合到一起,通过检测确认恢复了大概2/3的数据
基于恢复的该文件和这个表空间的其他文件一起,使用dul工具把数据恢复到新库中,最大限度完成本次数据的抢救工作.
本次故障本不该发生,或者说发生不该如此严重:
1. rman备份采用系统级别维护策略,在备份没有成功的情况下依旧通过系统层面删除文件,导致故障文件无一份有效备份
2. 发生故障之后,没有保护现场的意识:对于32kb的数据文件所在磁盘进行了大量的写入操作（近1T的数据文件直接在本盘做了一次拷贝,还有rman默认写入到了以前文件所在位置）