标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 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-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)
- 操作系统 (102)
- 数据库 (1,674)
- DB2 (22)
- MySQL (73)
- Oracle (1,536)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (22)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (14)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (67)
- Oracle Bug (8)
- Oracle RAC (52)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (562)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (78)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- GoldenGate 19安装和打patch
- dd破坏asm磁盘头恢复
- 删除asmlib磁盘导致磁盘组故障恢复
- Kylin Linux 安装19c
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
- ORA-01092 ORA-00604 ORA-01558故障处理
- ORA-65088: database open should be retried
- Oracle 19c异常恢复—ORA-01209/ORA-65088
- ORA-600 16703故障再现
- 数据库启动报ORA-27102 OSD-00026 O/S-Error: (OS 1455)
- .[metro777@cock.li].Elbie勒索病毒加密数据库恢复
- 应用连接错误,初始化mysql数据库恢复
- RAC默认服务配置优先节点
标签归档:dbf 0字节
Oracle 数据文件大小为0kb或者文件丢失恢复
接到一个朋友恢复请求,由于rose频繁切换导致文件系统部分数据文件变化为0kb和文件丢失.
故障现象
部分数据文件变化为0kb和文件丢失.
这里比较明显,数据库的users03变为了0kb和users04丢失.数据库alert日志报错信息如下:
Completed: alter database mount exclusive alter database open Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_dbw0_12008.trc: ORA-01157: ????/?????? 7 - ??? DBWR ???? ORA-01110: ???? 7: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS03.DBF' ORA-27047: ?????????? OSD-04006: ReadFile() 失败, 无法读取文件 O/S-Error: (OS 38) 已到文件结尾。 Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_dbw0_12008.trc: ORA-01157: ????/?????? 8 - ??? DBWR ???? ORA-01110: ???? 8: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS04.DBF' ORA-27041: ?????? OSD-04002: 无法打开文件 O/S-Error: (OS 2) 系统找不到指定的文件。 Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_12040.trc: ORA-01157: ????/?????? 7 - ??? DBWR ???? ORA-01110: ???? 7: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS03.DBF' ORA-1157 signalled during: alter database open... Fri May 04 09:35:10 2018 Checker run found 2 new persistent data failures
alert日志的报错也比较明显,users03是文件超过了大小(大小为0kb,读取之后肯定超过大小),users04提示无法打开文件(文件在文件系统层面已经丢失).现在问题比较明显由于文件系统故障导致文件大小为0和丢失
碎片扫描恢复
常规的方法肯定无法恢复,比较好的方法只能是底层碎片扫描重组,结合多种扫描工具,最后发现一个做底层恢复的朋友的工具效果不错,扫描结果如下
通过工具分析坏块情况
C:\Users\Administrator>dbv FiLe=D:\0504\ORCL_TS.4_FILE.7_10.ora DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 5月 5 08:52:53 2018 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = D:\0504\ORCL_TS.4_FILE.7_10.ora ……………… 页 382565 标记为损坏 Corrupt block relative dba: 0x01c5d665 (file 7, block 382565) Completely zero block found during dbv: 页 382566 标记为损坏 Corrupt block relative dba: 0x01c5d666 (file 7, block 382566) Completely zero block found during dbv: 页 382567 标记为损坏 Corrupt block relative dba: 0x01c5d667 (file 7, block 382567) Completely zero block found during dbv: DBVERIFY - 验证完成 检查的页总数: 1374720 处理的页总数 (数据): 27582 失败的页总数 (数据): 0 处理的页总数 (索引): 20114 失败的页总数 (索引): 0 处理的页总数 (其他): 1319752 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 1 标记为损坏的总页数: 7271 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 228271996 (0.228271996) C:\Users\Administrator>dbv FiLe=D:\0504\ORCL_TS.4_FILE.8_8.ora DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 5月 5 08:52:53 2018 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = D:\0504\ORCL_TS.4_FILE.8_8.ora DBVERIFY - 验证完成 检查的页总数: 1136896 处理的页总数 (数据): 36639 失败的页总数 (数据): 0 处理的页总数 (索引): 57038 失败的页总数 (索引): 0 处理的页总数 (其他): 1043218 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 1 标记为损坏的总页数: 0 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 228271997 (0.228271997) C:\Users\Administrator>
这里通过分析恢复的两个文件总的block数量2511618,其中连续损坏7271个block损坏,由于出现问题之后,数据库被offline这两个文件继续启动运行了几个小时,导致少量block被覆盖,恢复软件直接置空.后续的恢复比较顺利,正常open数据库,然后处理坏块对象(正好不是业务核心表的lob字段,所有部分丢失影响不是非常大).
温馨提醒:
1. 数据文件和备份不要放在同一个阵列上,更不能是同一个分区(卷)上
2. 出现此类问题之后,应当理解停止对该分区的任何写操作,方式丢失或者大小为0KB的文件被覆盖.
如果需要专业ORACLE数据库恢复技术支持,请联系我们
Phone:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
发表在 非常规恢复
标签为 dbf 0kb, dbf 0字节, O/S-Error: (OS 2), O/S-Error: (OS 38), oracle 0kb, oracle 0字节, 文件丢失恢复, 文件大小为0, 碎片扫描, 碎片重组
评论关闭