惜分飞 » oracle碎片恢复

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

惜分飞 — Sun, 07 Jun 2026 10:21:47 +0000

有硬件恢复圈朋友找到我,说硬件恢复之后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导出数据,完成本次恢复任务.

OraScan(Oracle 碎片扫描工具) 使用说明

惜分飞 — Mon, 27 Apr 2026 16:26:05 +0000

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：OraScan(Oracle 碎片扫描工具) 使用说明

一、软件概述
1.1 软件简介
OraScan 是由惜分飞（官方网址：www.xifenfei.com）自主研发的专业 Oracle 数据库碎片恢复工具，核心作用是扫描磁盘上未被覆盖的 Oracle 数据块，解决多种数据文件无法正常恢复的问题，适用于以下场景（不限于此）：
• 文件系统损坏，无法正常访问数据文件，且文件系统工具无法恢复；
• 误删除数据文件，操作系统层面的反删除工具无法恢复；
• 断电、文件系统故障导致数据文件变为 0KB，或文件大小异常；
• 小文件覆盖了大数据文件；
• 需要扫描磁盘上所有未被覆盖的 Oracle 数据块。

1.2 功能限制
• 对 bigfile 表空间数据文件支持较差，需人工干预；
• 对于 rfile 超过 1024 的数据文件，需人工干预。

1.3 适配环境（新手必看）
请根据自己的操作系统和 .NET Framework 版本，选择对应的软件可执行文件，避免无法运行：
1. .NET Framework 版本适配
￮ OraScan_Net2.exe：适配 .NET Framework 2.0、3.0、3.5 版本，兼容 Windows Server 2008 及更早操作系统；
￮ OraScan_Net4.exe：适配 .NET Framework 4.0 及以上版本，兼容 Windows Server 2012 及更新操作系统。
2. 数据库版本：支持 Oracle 9i 及以后所有版本；
3. 数据块大小：支持 4k、8k、16k、32k（需与数据库实际数据块大小一致）。
4. 支持win磁盘和镜像，支持linux/aix/hp-unix镜像

1.4 版权与技术支持
• 软件版权：归惜分飞（www.xifenfei.com）所有，未经授权不得擅自传播、修改；
• 技术支持（遇到问题可联系）：
￮ QQ：107644445
￮邮箱：dba@xifenfei.com
￮微信/电话：+86-17813235971

1.5 软件下载和说明
OraScan下载
 OraScan使用说明

二、软件使用步骤
核心流程：选择扫描对象 → 扫描碎片 → 加载解析结果 → 提取数据/碎片 → 可选操作（筛选、保存等），每一步操作清晰说明，无需额外复杂操作。

步骤1：选择扫描对象（磁盘/镜像文件，二选一）
打开软件后，首先选择需要扫描的对象，根据实际情况二选一，操作如下：

1.1 扫描磁盘设备（常用场景）
• 按照软件界面提示，选择对应的磁盘设备；
• 调整偏移量和实际扫描大小（不清楚的话，直接选择默认值即可，无需修改）。

1.2 扫描镜像文件
• 按照软件界面提示，选择对应的镜像文件；
• 关键注意点：不要勾选“设备”选项（与扫描磁盘设备的核心区别）。

步骤2：执行文件/设备碎片扫描
选择好扫描对象后，按以下步骤操作，新手无需额外设置：
1. 确认设置：确保块大小、偏移量、文件/设备大小设置正确（块大小需与数据库实际一致，新手可先按默认尝试，若扫描失败再调整）；
2. 开始扫描：点击“开始扫描”按钮，启动碎片扫描；
3. 取消扫描：若需中断扫描，点击“取消扫描”按钮即可，建议尽量等待扫描完成，确保碎片不遗漏；
4. 扫描过程解读：进度条显示扫描进度，括号内显示“总操作系统块数量+已扫描数量”，“碎片数量”表示已找到的有效 Oracle 数据文件碎片；
5. 扫描完成标志：软件会提示“扫描完成”，并告知找到的碎片数量；同时，软件当前目录会自动生成“scandata”文件夹，里面有一个“Oracle_Block.map”文件（记录碎片信息的二进制文件，后续会用到，不要删除）。

步骤3：加载并解析扫描结果
扫描完成后，需加载扫描结果并解析，才能看到可恢复的数据文件，操作步骤如下：
1. 点击软件中的“加载扫描结果”按钮；
2. 在弹出的窗口中，选择生成的“Oracle_Block.map”文件（若扫描后生成的是其他文件，选择对应文件即可）；
3. 选择完成后，点击“解析扫描结果”按钮；
4. 解析完成标志：软件提示“解析碎片完成”，同时软件左侧会显示数据文件列表，包含数据库名称、表空间名字、文件号等关键信息（后续提取数据需用到这些信息）；

5. 可选操作：点击“全部碎片”或“未使用碎片”，可查看各个数据文件的详细碎片信息

步骤4：数据文件提取（核心操作，恢复数据文件）
解析完成后，即可提取需要恢复的数据文件，新手按以下步骤操作：
1. 勾选左侧数据文件列表中，需要恢复的数据文件；

2. 点击“提取数据文件”按钮，即可开始恢复；
3. 注意事项：若软件提示“未授权”，无法提取，需联系作者（联系方式见1.4）进行授权；
4. 进阶操作（可选）：若只需提取某个数据文件的部分数据段，可点击该数据文件，然后选择“全选”或勾选需要的数据段，再点击“提取数据文件”即可。

步骤5：提取碎片（按碎片追加形式提取）
若无需提取完整数据文件，仅需提取碎片（操作系统层面的文件），直接点击软件中的“提取碎片镜像”按钮即可，无需额外设置。

步骤6：保存镜像文件
若需将勾选的数据文件/碎片直接保存为镜像文件，勾选对应内容后，点击“保存镜像文件”按钮，按提示选择保存路径即可。

步骤7：筛选数据功能（可选，精准查找碎片）
当点击“全部碎片”或“未使用碎片”时，软件会显示筛选功能，新手可按以下方式使用：
• 在筛选框中，输入“文件号”和“block范围”；
• 输入完成后，软件会自动筛选出符合条件的碎片，方便精准查找。

步骤8：获取文件碎片
该功能与“提取碎片镜像”类似，在没有授权的情况下，直接提取碎片镜像：
• 在对应输入框中，输入文件号（例如：输入“1|3”表示提取文件号1和3的碎片，输入“1024”表示提取所有文件碎片）；
• 输入完成后，软件会自动生成碎片镜像文件，无需其他操作。

三、注意事项
• 首次使用前，务必确认操作系统和 .NET Framework 版本，选择对应版本的软件（OraScan_Net2.exe / OraScan_Net4.exe），避免无法运行；
• 扫描时，若不清楚“偏移量”“扫描大小”“块大小”，先按默认值操作，若扫描失败再联系技术支持；
• 扫描完成后，“scandata”文件夹和“Oracle_Block.map”文件不要删除，否则无法加载解析扫描结果；
• 提取数据文件时，若提示未授权，需联系作者授权后再操作；
• 遇到任何操作问题，可通过1.4中的联系方式联系技术支持，提高恢复效率。
• 为了防止恶意破坏软件，对软件进行了加壳处理，某些杀毒软件可能提示病毒，这个不是真的病毒是由于某些情况下壳被杀毒软件的病毒库误识别为病毒，可以加入到杀毒软件的例外中或者直接关闭杀毒软件之后进行操作。

删除数据库文件并部分覆盖情况下Oracle恢复

惜分飞 — Mon, 01 Sep 2025 13:00:32 +0000

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：删除数据库文件并部分覆盖情况下Oracle恢复

有客户由于磁盘空间满了,人工删除了数据库30多个数据文件,导致数据库无法正常工作,然后又被人offline这些文件启动数据库,并运行了一段时间,导致写入了大量的trace和部分数据库归档日志,导致被删除的数据文件发生了覆盖,对于这样情况,通过底层反删除工具对磁盘进行扫描,发现了部分被删除文件,但是大小基本上显示0kb

对于这种情况,os层面反删除恢复,肯定无法恢复出来合适的数据文件,只能做底层数据块扫描恢复,参考以前类似case:
rm -rf误删Oracle数据库恢复
win系统删除oracle数据文件恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
解决一次硬件恢复之后数据文件0kb的故障恢复case
这个客户的情况相对复杂一些:
1. 该磁盘分区中有历史库(也就是说单纯的软件直接按照rdba方式无法直接区分出来合适的数据块,儿实现数据重组)
2. 删除的文件比较多(33个数据文件),分区较大(5T+)
3. 删除文件之后,分区还写入了不少数据,会引起一些覆盖和导致碎片数量增加,导致工作量增加和恢复效果变差
通过对客户alert日志分析,发现一个好消息,客户数据每个数据文件是固定大小(没有设置自增长),这种情况,一般来说数据比较连续,碎片相对比较容易区分出来.

通过工具扫描识别出来oracle block,并把结果记录到数据库中,然后通过人工在数据库中对其进行挑选识别,然后生成dd语句恢复出来数据文件,比如这个只是被覆盖了文件头的22号文件,就比较容易恢复

对于一些碎片严重的文件,就需要人工生成大量dd语句来恢复

对于所有恢复出来的文件,使用工具检查坏块情况

然后把这些数据文件中的数据恢复到新库中,完成本次数据恢复工作,最大限度抢救客户数据.

restore database误操作恢复

惜分飞 — Sat, 20 Oct 2018 12:19:15 +0000

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：restore database误操作恢复

接到朋友恢复请求,由于客户的误操作(生产库遇到问题,无法正常open,在没有确认备份和归档日志完全正常的情况下,直接restore database操作),导致原库数据文件被备份中的数据文件还原,而且中间归档丢失,无法一直应用归档把数据文件追到最新.通过Oracle Database Recovery Check脚本check数据库结果如下

这里很明显红色框中数据文件被还原,发现一个可喜的地方,被还原的文件相对都比较小,也就是说相对覆盖的部分可能不会太多.通过alert日志确认数据被rman还原覆盖

然后继续应用日志恢复

悲剧发生了明显thread 2的sequence 297归档日志发现丢失,进一步发现这个rac(2节点)一共丢失了300个左右的归档日志.到这一步常规方法来说,基本上无解,放弃数据库恢复,因为基于现在的情况客户2014-07-27 07:18:12创建的,目前只是恢复到了2014-10-20 08:26:43日期的数据,而且通过数据库现状判断,数据库主要是写入file 4,也就是users表空间的第一个数据文件中,而该文件已经被还原,强制拉库没有意义.考虑通过bbed修改文件头,跳过相关丢失的归档,继续应用以后的归档,因为跳过的归档太多,基本上不可行(跳过这些丢失的归档之后,后面的归档继续应用会报错).基于这样的情况,抱着一丝丝的希望,rman备份是业务上线之后备份(这样被还原的system里面就有完整的业务数据字典信息).通过对system文件进行分析,确认我们比较幸运,业务数据创建于2014-8月份,而且根据客户的反馈之后基本上没有变更.参考:asm disk header 彻底损坏恢复方法扫描效果比较好,file 4 的觉大部分block均存在

然后通过这些block重组成数据文件然后结合以前的system文件,强制open库,基本上实现客户数据的绝大部分恢复.

类似案例还有:
asm磁盘组误删除文件恢复
又一例asm格式化文件系统恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
oracle asm disk格式化恢复—格式化为ntfs文件系统
oracle asm disk格式化恢复—格式化为ext4文件系统
alter database create datafile 导致数据文件丢失恢复
分享oracleasm createdisk重新创建asm disk后数据0丢失恢复案例