硬件故障后数据文件大小不对故障处理—Oracle碎片扫描恢复

惜分飞2026-06-08 23:38

有硬件恢复圈朋友找到我,说硬件恢复之后dbv报dbv-00102错误,让我给看看是否可以处理

这个是oracle dbv中一种常见错误,一般是由于block 0 不对,或者是由于文件大小不对引起,让把恢复文件发给我,进行检查

|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| SQL> ``select name,bytes``/1024/1024/1024 from ``v``$datafile_header; NAME BYTES``/1024/1024/1024 -------------------------------------------------------------------------------- -------------------- H:\BAIDUNETDISK\ORADATA\XXXXORCL\SYSTEM01.DBF 2.080078125 H:\BAIDUNETDISK\ORADATA\XXXXORCL\SYSAUX01.DBF 2.880859375 H:\BAIDUNETDISK\ORADATA\XXXXORCL\UNDOTBS01.DBF 9.0087890625 H:\BAIDUNETDISK\ORADATA\XXXXORCL\USERS01.DBF 31.993408203125 H:\BAIDUNETDISK\ORADATA\XXXXORCL\USERS02.DBF 8.1640625 H:\BAIDUNETDISK\ORADATA\XXXXORCL\USERS03.DBF 7.958984375 H:\BAIDUNETDISK\ORADATA\XXXXORCL\USERS04.DBF 7.958984375 H:\BAIDUNETDISK\ORADATA\XXXXORCL\USERS05.DBF 7.890625 已选择8行。 |

确定USER02-USERS05的dbf文件实际大小(数据文件头记录)在8G左右,但是目前恢复出来的文件大小只有4G左右

在恢复工具中直接查看文件大小情况

这里比较明显rs中虽然显示文件状态良好,但是实际大小也不对(得出经验:以后恢复中不能太依赖这个状态),根据反馈现场是三个盘的raid5,中途做了一次强制上线,然后客户也使用win pe拷贝过一次数据,大小和现在一样,也是少了近4G.第一反应可能是由于raid盘弄的不对,但是经过对其他文件的确认,多完全没有问题,排除了盘错误的问题,怀疑是由于文件系统异常导致,对于这种的情况,文件系统层面肯定无法恢复,考虑使用自研的OraScan工具进行扫描(OraScan(Oracle 碎片扫描工具) 使用说明)

通过OraScan扫描找到相关block,并提取出来数据文件

使用dbv检测文件

|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| C:\Users\XFF>dbv ``file``=H:\BaiduNetdisk\xff\YFKJORCL.USERS.4.7.4.N.DBF DBVERIFY: Release 11.2.0.4.0 - Production on 星期日 6月 7 18:06:30 2026 Copyright (c) 1982, 2011, Oracle and``/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = H:\BAIDUNETDISK\XFF\YFKJORCL.USERS.4.7.4.N.DBF DBVERIFY - 验证完成 检查的页总数: 1043200 处理的页总数 (数据): 67167 失败的页总数 (数据): 0 处理的页总数 (索引): 37995 失败的页总数 (索引): 0 处理的页总数 (其他): 861109 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 76929 标记为损坏的总页数: 0 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 347454063 (0.347454063) |

把文件拷贝替换掉之前恢复的USERS02-USER05.DBF,然后尝试打开数据库

|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| SQL> recover ``database ; 完成介质恢复。 SQL> ``alter database open ; alter database open * 第 1 行出现错误: ORA-03113: 通信通道的文件结尾 进程 ID: 3308 会话 ID: 14 序列号: 3 |

查看alert日志分析原因

|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Sun Jun 07 14:43:51 2026 Recovery of Online Redo Log: Thread 1 Group 2 Seq 36464 Reading mem 0 ``Mem``# 0: H:\BAIDUNETDISK\ORADATA\YFKJORCL\REDO02.LOG Completed: ALTER DATABASE RECOVER database alter database ``open Beginning crash recovery of 1 threads ``parallel recovery started with 19 processes Started redo scan Completed redo scan ``read 2353 KB redo, 0 data blocks need recovery Started redo application at ``Thread 1: logseq 36464, block 15876 Recovery of Online Redo Log: Thread 1 Group 2 Seq 36464 Reading mem 0 ``Mem``# 0: H:\BAIDUNETDISK\ORADATA\YFKJORCL\REDO02.LOG Completed redo application of 0.00MB Completed crash recovery at ``Thread 1: logseq 36464, block 20582, scn 347475303 ``0 data blocks ``read``, 0 data blocks written, 2353 redo k-bytes ``read Sun Jun 07 14:43:57 2026 Errors ``in file c:\app\xff\diag\rdbms\yfkjorcl\o11201\trace\o11201_lgwr_2204.trc: ORA-00314: ?? 3 (???? 1) ??? sequence``# 36462 ? 32025 ??? ORA-00312: ???? 3 ?? 1: ``'H:\BAIDUNETDISK\ORADATA\YFKJORCL\REDO03.LOG' Errors ``in file c:\app\xff\diag\rdbms\yfkjorcl\o11201\trace\o11201_lgwr_2204.trc: ORA-00314: ?? 3 (???? 1) ??? sequence``# 36462 ? 32025 ??? ORA-00312: ???? 3 ?? 1: ``'H:\BAIDUNETDISK\ORADATA\YFKJORCL\REDO03.LOG' Errors ``in file c:\app\xff\diag\rdbms\yfkjorcl\o11201\trace\o11201_ora_3308.trc: ORA-00314: 日志 1 (用于线程 ) 要求的 sequence``# 与 不匹配 ORA-00312: 联机日志 3 线程 1: ``'H:\BAIDUNETDISK\ORADATA\YFKJORCL\REDO03.LOG' USER (ospid: 3308): terminating the instance due to error 314 Sun Jun 07 14:44:02 2026 Instance terminated by USER, pid = 3308 |

由于redo group 异常导致库无法正常open,但是由于已经recover database成功,因此大概率可以clear该redo 组

|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| SQL> ``select group``#,status ``from v$log; ``GROUP``# STATUS ---------- ---------------- ``1 INACTIVE ``3 INACTIVE ``2 ``CURRENT SQL> ``alter database clear logfile ``group 3; 数据库已更改。 SQL> ``alter database open``; 数据库已更改。 |

数据库open成功，然后使用expdp导出数据,完成本次恢复任务.

热门推荐
01GitHub 镜像站点02【AI】2026 年具身智能模型和世界模型总结03Codex 下载安装指南：Windows 和 macOS 官方版下载042026 年 AI 编程工具终极横评：Cursor vs Claude Code vs Copilot vs Windsurf05CC-Switch & Claude 基于 Linux 服务器安装使用指南06【踩坑记录 | 第一篇】微软商店无法使用时，如何手动安装 OpenAI Codex？附`.msix`文件系统错误解决方法07Agnes AI 全模态 API 免费实测报告：文生图 + 文生视频完整测试08Codex 桌面端更新后 Chrome 插件和 Computer Use 不可用，怎么排查和修复09CC-Switch 下载、安装与使用配置指南【2026.5.29】102026 AI 编程工具终极实战指南：Cursor vs Claude Code vs Copilot，开发者该怎么选？