养生 装修 购物 美食 感冒 便秘 营销 加盟 小吃 火锅 管理 创业 搭配 减肥 培训 旅游

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

时间:2024-11-01 14:39:47

D公司的SA系统管理员误删除了某数据库的SYSTEM表空间所在数据文件,这导致数据库完全无法打开,数据无法取出。在没有备份的情况下,可以使用PRM-DUL恢复接近100%的数据。

工具/原料

ORACLEPRM-DUL

ORACLE数据库

Xmanager远程图形化

方法/步骤

1、D公司的SA系统管理员误删除了某数据库的SYSTEM表空间所在数据文件,这导致数据库完全无法打开,数据无法取出。在没有备份的情况下,可以使用PRM恢复接近100%的数据。此场景中启动PRM后,进入RecoveryWizard后选择《Non-Dictionarymode》非字典模式。

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

2、No-dictionary模式下需要用户指定字符集和国家字符集,这是因为丢失了SYSTEM表空间后,数据库的字符集信息无法正常获得,所以需要用户的输入。只有输入正确的字符集设置以及安装了必要的语言包才能保证No-Dictionary模式下正常抽取多国语言。与场景演示1类似,输入用户目前可得的所有数据文件(不包括临时文件),并设置正确的BlockSize和OFFSET:

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

3、之后点击SCAN,SCAN的作用是扫描所有数据文件上的S娣定撰钠egmentHeader,并记录到SEG$.DAT裘沲谡迹和EXT$.DAT中;在ORACLE中一个非分区表或者一个分区表的分区都对应着一个SEGMENTHEADER数据段头,只要能找到SEGMENTHEADER就可以获得整个表数据段的盘区EXTENTMAP信息,通过EXTENTMAP可以获得该表上的全部记录。通常存在这样一种情况,例如一张非分区的单表存放在某个由2个数据文件组成的表空间上,其SEGMENTHEADER以及一半的数据存放在A数据文件上,另一半数据存放在B数据文件上。但是由于某些原因,SYSTEM表空间和存放有SEGMENTHEADER的A数据文件均丢失了,只剩下B数据文件了,此时若希望仅仅恢复B数据文件上该表的数据,则不能依赖于SEGMENTHEADER,而只能依赖于从B数据文件上扫描盘区图EXTENTMAP信息了。为了同时满足基于SEGMENTHEADER和EXTENTMAP数据的NO-Dictionary模式恢复需要,所以SCAN操作在这里会填充SEG$.DAT和EXT$.DAT2个文件(文本文件仅仅为了便于诊断,所有程序实际依赖于PRM自带嵌入数据库DERBY的数据),并记录到DERBY数据库中。

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

4、完成SCAN后,主界面左揲褐逞孽侧出现数据库图标。此时可以选择2种模式:ScanTablesFromSegments,此模式适用于丢失了SYSTEM表空间,但是所有的应用数据表罗嵯脶姥空间均存在ScanTablesFromExtents不适用于Dictionary模式的Truncate表数据恢复丢失了SYSTEM表空间,而且丢失了SEGMENTHEADER所在数据文件通俗地说除非你无法使用场景2中的方式来恢复已经TRUNCATE掉的数据,否则总是优先使用ScanTablesFromSegments模式,如果发现ScanTablesFromSegments下找不到你要的数据,再考虑使用ScanTablesFromExtents模式。我们优先采用ScanTablesFromSegments模式

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

5、ScanTablesFromSegments完成后可以点开主界面左边的树形图:

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

6、ScanTables操作基于SEG$中的SEGMENTHEADER信息来构建数据表信息,树形图上每一个节点表示一个数据表段,其名字为obj+数据段上记录的DATAOBJECTID。点中一个节点并观察主界面右侧边栏:

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

7、智能字段类型解析由于丢失了SYSTEM表空间,故NO-锓旆痖颧Dictionary模式下缺乏数据表的结构信息,这些结构信息包括表上的字段名字和字段恽贴淑溪类型,而且在ORACLE中这些信息均只保存为字典信息,不会在数据表上存放。当用户只有应用表空间时,需要基于数据段上的ROW行数据来猜测每一个字段的类型,PRM采用先进JAVA类型预判技术,可以解析多达10来种主流数据类型;、智能解析准确度超过90%,可以自动解决大部分场景。右侧边栏上部各字段的含义:Col1no字段号SeenCount:取到的行数MAXSIZE:最大长度,单位为字节PCTNULL:采样到的NULL的比例StringNice:将该字段解析为字符串,并成功的比例NumberNice:将该字段解析为数字,并成功的比例DateNice:将该字段解析为Date,并成功的比例TimestampNice:将该字段解析为Timestamp,并成功的比例TimestampwithtimezoneNice:将该字段解析为TimestampwithtimezoneNice,并成功的比例示例数据分析SampleDataAnalysis:

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

8、该部分依据智能字段类型解析的结果来解析10条数据,并显示解析结果。通过示例数据可以帮助用户了解实际该数据段中存放数据的情况。如果数据段上记录条数不足10条,则显示所有记录。TRYTOANALYZEUNKNOWNcolumntype:

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

9、该部分是对于智能字段类型分析不能100%确认的字段,尝试用各种字段类型来解析,并呈现给用户,以便用户自行判断其究竟是什么类型。目前PRM还不支持的类型包括:XDB.XDB$RAW_LIST_T、XMLTYPE、用户自定义类型等UnloadStatement:这部分是PRM生成的UNLOAD语句,此生成的UNLOAD语句仅作为系统内部使用和PRM开发团队以及ParnassusData原厂支持工程师使用。

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

10、在此《Non-DictionaryMode》非字典模式下同样可以采用常规和数据搭桥模式,与字典模式相比,主要的区别在于在非字典模式下数据搭桥时用户可以自行执行字段的类型,如下图中中部分字段类型为UNKNOWN,即未知的。这些字段可能是PRM目前还不支持的例如XML字段,也可能是PRM的智能解析没有顺利分析器类型。如果用户知道这张表设计时的结构(也可以来源于应用开发商的文档),那么可以自行去填选正确的ColumnType类型,以便PRM顺利将该表数据搭桥到目标数据库。

ORACLE DUL 恢复误删除SYSTEM01.DBF的数据库

© 一点知识