可以利用如下脚本获得较多OBJECT_ID与OBJECT_NAME的映射关系Select * from(select object_name,object# from DBA_HIST_SQL_PLANUNION select object_name,object# from GVSQL_PLAN) V1 where V1.OBJECT# IS NOT NULL minus select name,obj# from sys.obj;select obj#,dataobj#, object_name from WRH_SEG_STAT_OBJ where object_name not in (select name from sys.obJ) order by object_name desc;另一个查询:SELECT tab1.SQL_ID,current_obj#,tab2.sql_textFROM DBA_HIST_ACTIVE_SESS_HISTORY tab1,dba_hist_sqltext tab2WHERE tab1.current_obj# NOT IN(SELECT obj# FROM sys.obj)AND current_obj#!=-1AND tab1.sql_id =tab2.sql_id(+);注意以上方法仅仅在用户确实找不到所要恢复的数据表的任何定义信息时使用(即用户找任何对该应用模式设计有了解的人、脚本和文档),且由于依赖于AWR数据,所以并不十分准确。
D 公司的DBA由于误操作删除了TS数据字典基表导致数据库无法启动Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit ProductionWith the Partitioning, Automatic Storage Management, OLAP, Data Miningand Real Application Testing optionsINSTANCE_NAME—————-ASMMESQL>SQL>SQL> select count(*) from sys.ts;COUNT(*)———-5SQL> delete ts;5 rows deleted.SQL> commit;Commit complete.SQL> shutdown immediate;Database closed.Database dismounted.ORACLE instance shut down.Database mounted.ORA-01092: ORACLE instance terminated. Disconnection forcedORA-01405: fetched column value is NULLProcess ID: 5270Session ID: 10 Serial number: 3Undo initialization errored: err:1405 serial:0 start:3126020954 end:3126020954 diff:0 (0 seconds)Errors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc:ORA-01405: fetched column value is NULLErrors in file /s01/diag/rdbms/asmme/ASMME/trace/ASMME_ora_5270.trc:ORA-01405: fetched column value is NULLError 1405 happened during db open, shutting down databaseUSER (ospid: 5270): terminating the instance due to error 1405Instance terminated by USER, pid = 5270ORA-1092 signalled during: ALTER DATABASE OPEN…opiodr aborting process unknown ospid (5270) as a result of ORA-1092
此场景中由于数据字典已经损坏,所以想要正常打开数据库是十分困难的。此时则可以使用PRM-DUL来抽取数据库中的数据。具体步骤与场景1中的相似,用户仅仅需要输入该数据库的所有数据文件即可,其简要步骤如下:Recovery Wizard选择字典模式 Dictionary Mode合理选择Big或者Little Endian加入数据文件并点击Load根据实际需求恢复表中的数据
D公司的SA系统管理员误删除了某数据库的SYSTEM表空间所在数据文件,这导致数据库完全无法打开,数据无法取出。 在没有备份的情况下,可以使用PRM-DUL恢复接近100%的数据。此场景中启动PRM-DUL后,进入Recovery Wizard后 选择《Non-Dictionary mode》非字典模式:
No-dictionary模式下需要用户指定 字符集和国家字符集,这是因为丢失了SYSTEM表空间后,数据库的字符集信息无法正常获得,所以需要用户的输入。 只有输入正确的字符集设置以及安装了必要的语言包才能保证No-Dictionary模式下正常抽取多国语言。与场景演示1类似,输入用户目前可得的所有数据文件(不包括临时文件),并设置正确的Block Size和OFFSET:
之后点击SCAN,SCAN的作用是扫描所有数据文件上的Segment Header,并记录到SEG.DAT和EXT.DAT中;在ORACLE中一个非分区表或者一个分区表的分区都对应着一个SEGMENT HEADER数据段头,只要能找到SEGMENT HEADER就可以获得整个表数据段的盘区EXTENT MAP 信息,通过EXTENT MAP可以获得该表上的全部记录。
完成SCAN 后,主界面左侧出现数据库图标。此时可以选择2种模式:Scan Tables From Segments,此模式适用于丢失了SYSTEM表空间,但是所有的应用数据表空间均存在Scan Tables From Extents不适用于Dictionary模式的Truncate表数据恢复丢失了SYSTEM表空间,而且丢失了SEGMENT HEADER所在数据文件通俗地说 除非你无法使用场景2中的方式来恢复已经TRUNCATE掉的数据,否则总是优先使用Scan Tables From Segments模式,如果发现Scan Tables From Segments下找不到你要的数据,再考虑使用Scan Tables From Extents模式。