Chinaunix首页 | 论坛 | 博客
  • 博客访问: 354549
  • 博文数量: 608
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 6115
  • 用 户 组: 普通用户
  • 注册时间: 2016-08-02 14:16
文章分类

全部博文(608)

文章存档

2024年(172)

2023年(218)

2022年(181)

2020年(12)

2019年(24)

我的朋友

分类: Oracle

2022-11-04 14:17:12

数据库数据恢复环境:
LINUX EXT3文件系统,部署ORACLE数据库。

数据库故障&分析:
管理员在建立测试库时选错了服务器,在ORACLE数据库平台上CREATE了一套新库,创建至10%左右时发现异常,中止操作。
查看数据库目录发现只剩下SYSTEM2.DBF这一个库,其他的库(主要为SYSTEM1.DBF)丢失。
经过北亚数据恢复工程师团队经过会诊,{BANNED}最佳终确定了方案:
直接重建原先文件的属性节点,即主要恢复原文件的大小、存储位置等信息。通过节点重新描述文件。
如果上述方法不可行,可以按照ORACLE数据库的页面结构特征进行分析与恢复。

数据库数据恢复过程:
1、对故障数据库所涉及到的硬盘做镜像备份,后续的数据恢复操作在镜像备份文件上进行,避免对原始数据造成二次破坏。
2、通过北亚自主开发的针对LINUX EXT3文件系统误删除的恢复软件,我们找到了一些ORACLE数据库文件,导出后发现导出的SYSTEM1虽然结构完好,但文件大小与用户描述的文件大小相差很远。
3、经过仔细分析,确认导出的SYSTEM1.DBF为用户创建测试库时生成的库,因未全部生成便被取消,所以只占用了很小的初始化空间,与原数据库无关。
4、重新对全盘进行扫描,结合ORACLE本身的结构,锁定原SYSTEM1.DBF的数据区,但发现这块数据区已经被新生成的几个新库覆盖了。
5、经过北亚数据恢复工程师的努力,将用户描述大小的丢失的数据成功导出。但经过验证后发现,导出的数据虽然结构完好、无损坏,但因头部库结构及字典均遭受破坏,无法重现,只能在数据完好的区域内再次查找数据。
6、ORACLE工程师通过对中间数据进行分析、重组,重新导入到新库中并进行验证,{BANNED}最佳终用户确认所需要的数据已经全部恢复。
阅读(538) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~