Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

999

积分

1

好友

942

主题
1#
发表于 2017-4-17 15:53:34 | 查看: 2849| 回复: 2
本帖最后由 ALLSTARS_ORACLE 于 2017-4-27 13:57 编辑

两天前删除了一个表空间,不过数据文件还在
drop tablespace tarim concluding contents.
然后把数据文件复制到其他地方
数据库没有归档,怎么恢复这个表空间的数据呢??
可以重新建一个表空间指定数据文件的位置吗?


如果直接恢复的话有可能吗?应该不可能了吧?
这个如果让这个表空间online再强制恢复有可能吗?


加including contents选项后是否数据都已经清除了??恢复也已经没有数据了吧??
including contents删除表空间选项是全部清除数据还是象delete table一样只是做一个标记还是只是离线表空间而不会操作物理文件呢?

没有备份,要有备份的话都好解决了,恢复备份导出导入表空间就可以了
而且还是非归档
下载专业ORACLE数据库恢复工具PRM-DUL  For Oracle http://www.parnassusdata.com/

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 13764045638  QQ: 47079569     邮箱:service@parnassusdata.com
2#
发表于 2017-4-27 13:58:11
DROP TABLESPACE误删除表空间的Oracle特殊恢复

某企业核心业务数据库由于误操作导致多个业务表空间被意外DROP,这些业务表空间存放了300多张表,且无任何形式的有效物理、逻辑备份。
诗檀软件工程师赴用户现场。 具体了解了本问题的细节信息:
数据库采用归档模式,但当时未找到有效的物理或逻辑备份。
多个表空间被DROP ,但因为DROP TABLESPACE没有指定inlucding datafiles,故相关数据文件仍保留在文件系统中未被删除。
尝试使用flashback query闪回查询OBJ$、TAB$等表以便获取被DROP TABLESPACE所删除的字典信息时出现ORA-01555错误,说明相关UNDO数据已过期,无法通过闪回查询挽救DROP TABLESPACE相关的字典数据。
尝试使用bbed观察dbf上的字典表,发现OBJ$、TAB$等字典表仅仅残存少量已删除数据,无法通过特殊恢复已删除数据行的手段来恢复字典数据
以上场景信息,由于DROP TABLESPACE后已无法通过闪回查询或bbed特殊手段来恢复对应的数据字典信息,故恢复数据字典来回退drop tablespace操作已不可能。
针对此种场景,在无有效物理或逻辑备份的情况下,使用ORACLE PRM-DUL工具是唯一有效的恢复途径。

注意:针对此类无有效物理备份的场景采用DUL特殊恢复的,并无法保证100%恢复数据。其恢复数据的比例主要取决于数据空间在被ORACLE回收后是否有被重用或覆盖。DROP TABLESPACE操作本身包含一系列的递归操作,即包括递归地DROP该表空间上的所有数据表,在完全DROP该表空间上的所有数据表后才能真正意义上DROP TABLESPACE,则此DROP TABLESPACE持续的时间内其回收的空间可能被重用或覆盖。

由于字典数据已丢失且不可挽回,故在使用ORACLE PRM-DUL时需采用非字典模式(NON-SYSTEM TABLESPACE),即直接扫描已被DROP TABLESPACE的数据文件,扫描这些数据文件的SEGMENT HEADER或 SEGMENT EXTENTS数据。这些原始数据中虽然包含着实际表上的行数据,但并不包含例如表的名字TABLE_NAME或COLUMN_NAME字段名字或字段类型等元数据。故非字典模式下UNLOAD抽取出来的表的表名为OBJ+其DATA_OBJECT_ID的形式 例如OBJ9999,代表此表为DATA_OBJECT_ID=9999的数据表。故非字典模式下的UNLOAD出来的表,需要人工识别其数据具体属于哪个表,或通过其他手段来识别。

采用PRM-DUL的非字典模式 存在2种扫描方式,基于SEGMENT HEADER 表头或 EXTENT 盘区模式。 对于一个表空间无任何数据文件丢失的且确认表头未丢失的场景优先采用SEGMENT HEADER 表头模式。 PRM-DUL在表头模式下正常 SCAN DATABASE ; SCAN TABLES; 操作后扫描发现了超过190张表,通过业务人员识别和之前获取的表对应关系,优先恢复了部分业务表,但在SEGMENT HEADER 表头模式下未找到5张业务核心表。

通过SEGMENT HEADER 表头模式下未找到五张表,说明了这五张表的SEGMENT HEADER 表头由于DROP TABLESPACE而已损坏或被重用,这说明了DROP TABLESPACE过程中已重用/覆盖部分回收空间。由于扫描SEGMENT HEADER 表头模式下未找到需要的表,故后续采用扫描EXTENT模式。

由于扫描EXTENT模式将扫描出数据文件上所有存有数据行的数据块,而无需一个SEGMENT HEADER 表头,故采用扫描EXTENT模式可以找到最大量的数据,同时由于其扫描范围更广故可能找到更多无需恢复的数据表。由于每一次扫描均需要针对超过1TB数据的数据文件,故每一次扫描均耗费较多时间。
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638   QQ号:47079569    邮箱:service@parnassusdata.com



回复 只看该作者 道具 举报

3#
发表于 2017-7-25 14:32:13
本帖最后由 biotwang 于 2017-7-25 15:12 编辑

恢复思路:

1. DROP TABLESPACE INCLUDING CONTENTS主要是会对数据字典中的表空间相关信息做彻底删除,这其中表空间的段信息(表,索引等)都会被清理。即便表空间文件还在,你仍然需要对数据字典信息恢复才行,即便手工重建控制文件将此表空间重新恢复,但是数据字典上的段信息还是没办法恢复的。由于少了表空间下的段信息,表空间重新指定文件或强制online都成了空想。

2. 在没有备份且非归档的情况,你只能直接对数据文件进行数据救援了,不过由于没有表名和列名信息,这需要自己对数据进行辨别恢复,如果表很多,工作量将是巨大的。这里可以使用PRM Databridge抽取表数据到新数据库中,这样更方便比对。

3. 如果可以直接从字典表中恢复出之前清理掉的表空间及段记录信息,那会对数据辨别和表恢复工作具有重大帮助,因为可以通过object_id进行表结构数据的一一对应修正恢复。如果无法找到的话,那么退而求其次,只能找下是否存在过去的表空间下对象的建立脚本和文档记录并对表数据进行人工辨别了。

使用Flashback Query来查询obj$,tab$,col$字典表, 例如:
select * from obj$ as of timestamp to_timestamp('2017-07-25 14:07:11', 'YYYY-MM-DD HH24:MI:SS');

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-5-17 20:13 , Processed in 0.046497 second(s), 20 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569