联系：手机/微信(+86 17813235971) QQ(107644445)
标题：硬件故障后数据文件大小不对故障处理—Oracle碎片扫描恢复
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
有硬件恢复圈朋友找到我,说硬件恢复之后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导出数据,完成本次恢复任务.
