Oracle 数据文件大小为0kb或者文件丢失恢复

来源：这里教程网时间：2026-03-03 16:47:54 作者：

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

标题： Oracle 数据文件大小为0kb或者文件丢失恢复

接到一个朋友恢复请求,由于rose频繁切换导致文件系统部分数据文件变化为0kb和文件丢失. 故障现象 部分数据文件变化为0kb和文件丢失. file_lost file_size_0

这里比较明显,数据库的users03变为了0kb和users04丢失.数据库alert日志报错信息如下:

Completed: alter database 
mount 
exclusive

alter database 
open

Errors 
in 
file 
E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_dbw0_12008.trc:

ORA-01157: ????/?????? 7 - ??? DBWR ????

ORA-01110: ???? 7: 
'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS03.DBF'

ORA-27047: ??????????

OSD-04006: ReadFile() 失败, 无法读取文件

O
/S-Error
: (OS 38) 已到文件结尾。

Errors 
in 
file 
E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_dbw0_12008.trc:

ORA-01157: ????/?????? 8 - ??? DBWR ????

ORA-01110: ???? 8: 
'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS04.DBF'

ORA-27041: ??????

OSD-04002: 无法打开文件

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

Errors 
in 
file 
E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_12040.trc:

ORA-01157: ????/?????? 7 - ??? DBWR ????

ORA-01110: ???? 7: 
'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS03.DBF'

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

Fri May 04 09:35:10 2018

Checker run found 2 new persistent data failures

alert日志的报错也比较明显,users03是文件超过了大小(大小为0kb,读取之后肯定超过大小),users04提示无法打开文件(文件在文件系统层面已经丢失).现在问题比较明显由于文件系统故障导致文件大小为0和丢失 碎片扫描恢复 常规的方法肯定无法恢复,比较好的方法只能是底层碎片扫描重组,结合多种扫描工具,最后发现一个做底层恢复的朋友的工具效果不错,扫描结果如下 file_scan

通过工具分析坏块情况

C:\Users\Administrator>dbv FiLe=D:\0504\ORCL_TS.4_FILE.7_10.ora

DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 5月 5 08:52:53 2018

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

DBVERIFY - 开始验证: FILE = D:\0504\ORCL_TS.4_FILE.7_10.ora

………………

页 382565 标记为损坏

Corrupt block relative dba: 0x01c5d665 (
file 
7, block 382565)

Completely zero block found during dbv:

页 382566 标记为损坏

Corrupt block relative dba: 0x01c5d666 (
file 
7, block 382566)

Completely zero block found during dbv:

页 382567 标记为损坏

Corrupt block relative dba: 0x01c5d667 (
file 
7, block 382567)

Completely zero block found during dbv:

DBVERIFY - 验证完成

检查的页总数: 1374720

处理的页总数 (数据): 27582

失败的页总数 (数据): 0

处理的页总数 (索引): 20114

失败的页总数 (索引): 0

处理的页总数 (其他): 1319752

处理的总页数 (段)  : 0

失败的总页数 (段)  : 0

空的页总数: 1

标记为损坏的总页数: 7271

流入的页总数: 0

加密的总页数        : 0

最高块 SCN            : 228271996 (0.228271996)

C:\Users\Administrator>dbv FiLe=D:\0504\ORCL_TS.4_FILE.8_8.ora

DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 5月 5 08:52:53 2018

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

DBVERIFY - 开始验证: FILE = D:\0504\ORCL_TS.4_FILE.8_8.ora

DBVERIFY - 验证完成

检查的页总数: 1136896

处理的页总数 (数据): 36639

失败的页总数 (数据): 0

处理的页总数 (索引): 57038

失败的页总数 (索引): 0

处理的页总数 (其他): 1043218

处理的总页数 (段)  : 0

失败的总页数 (段)  : 0

空的页总数: 1

标记为损坏的总页数: 0

流入的页总数: 0

加密的总页数        : 0

最高块 SCN            : 228271997 (0.228271997)

C:\Users\Administrator>

scan_resulte

这里通过分析恢复的两个文件总的block数量2511618，其中连续损坏7271个block损坏,由于出现问题之后,数据库被offline这两个文件继续启动运行了几个小时,导致少量block被覆盖,恢复软件直接置空.后续的恢复比较顺利,正常open数据库,然后处理坏块对象(正好不是业务核心表的lob字段,所有部分丢失影响不是非常大). 温馨提醒: 1. 数据文件和备份不要放在同一个阵列上,更不能是同一个分区（卷）上 2. 出现此类问题之后,应当理解停止对该分区的任何写操作,方式丢失或者大小为0KB的文件被覆盖.