标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-600 kcratr_nab_less_than_odr ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle碎片 OSD-04016 YOUR FILES ARE ENCRYPTED 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,875)
- DB2 (22)
- MySQL (82)
- Oracle (1,701)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (658)
- Oracle安装升级 (107)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (90)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
-
最近发表
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
- Patch_SCN快速修复ORA-01555数据库open故障
- 快速处理 ORA-01210: data file header is media corrupt 故障
- ORA-00314: log 3 of thread 1, expected sequence# N doesn’t match 0
- 记录block 0损坏,数据文件大量坏块,使用不当数据库版本恢复等各种操作之后的故障处理
- 需要注意:dbv 检测controlfile可能不准
- 达梦数据库redo异常强制拉库
- dd破坏包含50多个pdb的asm 磁盘组恢复
标签归档:OraFHR
记录一次win删除数据文件完美恢复案例
有客户在操作系统层面删除了四个数据文件(数据库在关闭情况下直接删除物理文件),然后offline,启动数据库,结果发现被删除的数据文件是业务表空间的,导致大量业务访问报错

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

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

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


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

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

Oracle数据库被勒索加密一键open工具–OraFHR
软件概述
1)OraFHR是由惜分飞自主研发的专业 Oracle 数据库数据文件头重构工具,通过重构文件头直接打开数据库,专为解决由于勒索病毒加密数据文件,导致Oracle数据库正常运行的情况恢复。
2)软件版权:惜分飞(www.xifenfei.com)所有,未经授权不得擅自传播或修改。
3)技术支持(包含软件授权和使用过程中的问题咨询)
QQ:107644445
邮箱:dba@xifenfei.com
微信 / 电话:+86-17813235971
4)软件使用前提:
在数据文件被加密之后,可以通过obet工具(obet实现对数据文件坏块检测功能)进行坏块检测,只有少量block损坏可以通过此工具进行恢复直接打开数据库,如果无法自行评估可以发给我进行评估确认
5)软件下载地址和使用说明
下载地址和使用说明
数据文件默认值配置

根据实际情况进行调整,如果不太懂,可以保持默认值
DBID:输入10进制数字,可以参考正常库的v$database.dbid值
DBNAME:输入长度不超过8个字符串,可以参考正常库的v$database.name值
版本输入值参考:同版本正常库偏移量block_size+24-28位置倒序,如果不确定当前数据库版本信息或者无法确认版本值该如何填写可以联系我进行分析
11.2.0.1-11.2.0.3 0B200000 11.2.0.4 0B200400 10.2.0.1 0A200100 10.2.0.3 0A200300 10.2.0.4 0A200400(有些平台依旧为0A200300) 10.2.0.5 0A200500 12.1.0.2 0C100200 12.2.0.1 0C200000 19.x 13000000 21.x 15000000 23.4 17040000
字符集:可以通过业务或者运维人员确认,如果没有办法确认可以恢复数据库sys.props$表进行确认
选择需要处理的数据文件

正常情况下,选择数据文件之后,会自动根据数据文件中前面block的信息,计算出来Rfile#信息

如果有Rfile#为0,表示需要人工根据实际情况分析进行修改,一般扩展名在选择数据文件的时候,会自动补充完成,如果不对可以人工进行调整.
完善表格中其他记录

选择wrh$_datafile文件,注意列使用|分割开,然后点击补全表格,就会自动根据当前情况进行完善表格相关信息
某些版本或者由于某些原因导致wrh$_datafile信息不全,可以通过ts$,file$进行完善(这种情况选择第二套参照方案,需要注册软件)

重构数据文件头
补全表格完成之后,可以点击重构数据文件头按钮,进行文件头重构。

后续数据库打开操作
点击后续操作命令按钮,自动生成open数据库相关操作语句文件

生成数据库open操作步骤和相关语句

参照这些文件中内容对于修复的文件进行操作,直接open库导出数据

加我微信(17813235971)
加我QQ(107644445)

