oracle碎片 – Database SOS

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中的联系方式联系技术支持，提高恢复效率。
• 为了防止恶意破坏软件，对软件进行了加壳处理，某些杀毒软件可能提示病毒，这个不是真的病毒是由于某些情况下壳被杀毒软件的病毒库误识别为病毒，可以加入到杀毒软件的例外中或者直接关闭杀毒软件之后进行操作。

记录一次win删除数据文件完美恢复案例

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

标题：记录一次win删除数据文件完美恢复案例

有客户在操作系统层面删除了四个数据文件(数据库在关闭情况下直接删除物理文件),然后offline,启动数据库,结果发现被删除的数据文件是业务表空间的,导致大量业务访问报错
ORA-00376

通过数据库层面查询确认这些文件已经不存在
121

对于这样的情况,先尝试从文件系统层面尝试反删除恢复文件

由于删除文件之后,启动了数据库并写入了一些日志和数据导致被删除的文件的元数据信息彻底丢失,这种情况下基于文件系统的反删除恢复肯定无法需要的数据,对于这种情况,考虑进行碎片层面恢复,以前有过类似案例:
win系统删除oracle数据文件恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
删除数据库文件并部分覆盖情况下Oracle恢复
通过底层扫描发现需要恢复的文件头部信息丢失,其他block完整(该文件本身不大,只有100M),扫描出来的数据块类似这样的结果
413

这里比较幸运,丢失的block为1-3,也就是涉及文件头和一些位图信息,通过以前自研的OraFHR工具(Oracle数据库被勒索加密一键open工具–OraFHR)进行重构文件头，再通过oracle recovery tools工具进行文件头的一些修复工作

再重建控制文件打开数据库,并完美导出数据,实现数据0丢失恢复
expdp

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

联系：手机/微信(+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语句来恢复

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

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

rm -rf误删Oracle数据库恢复

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

标题：rm -rf误删Oracle数据库恢复

有客户把虚拟化环境中装有oracle数据库的linux操作系统,由于操作失误在/下面执行了rm -rf *，导致所有文件被删除,系统无法启动.客户希望要求恢复出其中的Oracle数据库.由于是虚拟化环境,然后客户直接从虚拟化平台下载下来磁盘文件,通过工具加载和分析确认是一个xfs的文件系统

使用工具进一步扫描分析,找到部分数据文件

这里可以获取到两个信息:
1. 尝试恢复oracle的control01.ctl文件,然后通过该文件尝试分析其他数据文件位置,运气不错该文件恢复出来是好的,直接加载到新库查询v$datafile,分析出来所有数据文件信息
2. 这里有一个非常不幸的信息,oracle最核心的system01.dbf文件大小明显异常,进一步分析该文件信息,结论是该文件无法通过反删除方式进行恢复

先把可以os层面可以恢复的数据恢复出来,并且检查坏块情况

对于异常的system文件,有两个处理方法:
1. 通过阅览被删除的文件，发现客户有5月14日1点左右的rman备份,通过恢复软件中完整度提示,大概率应该没有什么问题,但是分析发现部分归档日志损坏无法完整恢复
2. 通过对磁盘做碎片,恢复出来该数据文件,参考以往文章:
dbca删除库和rm删库恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
通过这个方法运气不错,恢复出来该库的system01.dbf文件非常完整0丢失

[oracle@localhost oradata]$ dbv file=system01.dbf

DBVERIFY: Release 19.0.0.0.0 - Production on Thu May 15 23:26:57 2024

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

DBVERIFY - Verification starting : FILE = /u01/oradata/system01.dbf


DBVERIFY - Verification complete

Total Pages Examined         : 199680
Total Pages Processed (Data) : 113988
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 26869
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 40253
Total Pages Processed (Seg)  : 1
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 18570
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 658228557 (0.658228557)

完成上述恢复工作之后,目前确认只有sysaux01.dbf有8026个block损坏,但是该表空间不涉及业务数据,尝试在新的系统中直接修改路径并open库

SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-38760: This database instance failed to turn on flashback database


SQL> alter database flashback off;

Database altered.

SQL> recover database;
Media recovery complete.
SQL> alter database open;

Database altered.

运气不错,数据库直接open成功,现在处理sysaux01.dbf中的损坏文件:
1. 确认该文件具体坏块开始位置:

2. 由于坏块在文件中比较靠后,分析实际存储数据最后的位置

SQL> select max(block_id+blocks) from dba_extents where file_id=3;

MAX(BLOCK_ID+BLOCKS)
--------------------
             3493120

最后存储数据的位置小于坏块的位置,证明坏块部分是没有存储数据的,直接resize掉坏块部分

SQL> alter database datafile '/u01/oradata/sysaux01.dbf' resize 27290m;

Database altered.

然后dbv该数据文件,确认没有任何问题

[oracle@localhost trace]$ dbv file=/u01/oradata/sysaux01.dbf

DBVERIFY: Release 19.0.0.0.0 - Production on Wed May 15 22:43:00 2024

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

DBVERIFY - Verification starting : FILE = /u01/oradata/sysaux01.dbf


DBVERIFY - Verification complete

Total Pages Examined         : 3493120
Total Pages Processed (Data) : 1516833
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 1868832
Total Pages Failing   (Index): 0
Total Pages Processed (Lob)  : 56577
Total Pages Failing   (Lob)  : 0
Total Pages Processed (Other): 32107
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 18771
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 658223915 (0.658223915)

使用rman检测全库,也确定没有任何问题

[oracle@localhost trace]$ rman target /

Recovery Manager: Release 19.0.0.0.0 - Production on Wed May 15 22:43:58 2024
Version 19.15.0.0.0

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

connected to target database: XIFENFEI (DBID=2912535091)

RMAN> 

RMAN> 

RMAN> backup validate check logical database skip inaccessible;

Starting backup at 15-MAY-24
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=43 device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=278 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
………………
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
32   OK     0              6273         6400            370625094 
  File Name: /u01/oradata/xff_com.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              0               
  Index      0              0               
  Other      0              127             

File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
33   OK     0              163752       832000          627920639 
  File Name: /u01/oradata/XFF_DATA_202312231.dbf
  Block Type Blocks Failing Blocks Processed
  ---------- -------------- ----------------
  Data       0              374296          
  Index      0              285002          
  Other      0              8950            

Finished backup at 15-MAY-24

[oracle@localhost trace]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Wed May 15 22:47:44 2024
Version 19.15.0.0.0

Copyright (c) 1982, 2022, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.15.0.0.0

SQL> select * from v$database_block_corruption ;

no rows selected

SQL>

至此对于这次rm -rf /*的故障实现了Oracle数据库完美恢复,数据0丢失.

文件系统重新分区oracle恢复

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

标题：文件系统重新分区oracle恢复

最近处理的一个恢复,算是这几年中的一个奇葩.
1. oracle dg 主备库raid同时损坏,找硬件恢复厂商软件重组raid,恢复厂商判断所有磁盘全部都是好的
2. 主库系统被重装,文件系统重新分区.备库在使用duplicate搭建dg的过程中(通过alert日志分析以前的dg是正常的,直接rm掉了所有文件,然后使用duplicate搭建),只是部分文件拷贝到了备库
3. 备份放在一台单独的存储上,但是当上去看是发现存储上面空空的,没有任何数据(通过对ctl的分析,确认存储上面只有一个月之前的备份记录,估计也被删除或者重新分区了(通过后续分析,判断应该是被重新分区了)
客户没有和我们说任何信息,就是说突然两个raid都损坏了,找硬件厂商进行恢复,硬件厂商开始也觉得这个会比较简单,直接通过raid模拟恢复出来lun,然后通过软件恢复出来一些数据文件(反馈给我的信息是少了redo,需要我们协助恢复),通过深入分析,发现少了大量数据文件,基于现在的恢复基本上没意义.然后通过低主库的raid模拟恢复,拷贝出来数据文件,结果发现恢复出来的文件大小,和文件头记录不匹配