在其他所有恢复方法失败后, Oracle DUL是最后的希望. 例如在没有备份的情况下, 系统表(SYSTEM)空间坏了或丢失了, 表空间被删除了等. DUL是Oracle一个仅供内部使用的工具, 它可以直接地从数据文件中读取所有的据数. 要想获得这个工具的合法拷贝几乎是不可能的, 请Oracle来做这样的恢复服务的成本是很高的. 在研究数据块格式的同时不知不觉地就写了一个具有同等功效的软件: AUL/MyDUL. AUL/MyDUL只是一个个人的在研究技术之余写的软件, 不保证可以百分之百地准确地恢复你的数据, 你可以在没有其他方法可用的情况下请求使用AUL/MyDUL. 作为DBA永远不要考虑将这样的工具作为备份与恢复方案的一部份(事实上有不少人这样想过), 你应当好好设计和测试你的备份策略, 如果遇到了什么问题, 先看看有没有备份, 然后联系Oracle是否能提供官方的技术服务. 在没有这些方法可用时, 当然欢迎你考虑AUL/MyDUL的恢复能力.

该软件修复bootstrap$故障，最常见的错误ORA-00702，使用该工具能够一键修复,实现数据0丢失.

oracle数据库恢复工具，不会使用的请看我2017-10-11博客

目标：Oracle RAC只有一个历史全备（热备），无增量备份和归档备份，现需恢复到单机上。文档给出具体步骤和可能遇到的错误。

oracle数据丢失、坏块，且没备份情况，找回数据的最后手段，支持8i，9i

oracle恢复原理;oracle培训内部资料,数据库爱好者非常值得一看.

牛逼的Oracle恢复实战流程图，响应对用户来说棘手的数据库崩溃，数据库调优，应用报错等问题

oracle dba

不小心Truncate表的事情也是有的, 其中大部份时因为工具连错了库, 从儿跑错了角本. 遇到这种事情而没有备份时怎么办呢? 首先要停止数据库, 将这个表所在的表空间的文件拷贝出来, 因为Oracle在Truncate只时将相应Segment的第一个块格式化掉了, 而后面的都还存在, 到下次用时到才真正地重新格式化. 下面来讲一个Truncate表后进行恢复的例子: SQL> CREATE TABLE T_TRUNCATE AS SELECT * FROM TAB; Table created. SQL> SELECT COUNT(*) FROM T_TRUNCATE; COUNT(*) ---------- 14 SQL> ALTER SYSTEM CHECKPOINT; System altered. SQL> TRUNCATE TABLE T_TRUNCATE; Table truncated. SQL> ALTER SYSTEM CHECKPOINT; System altered. 在Truncate时只是Segment Header格式化了, 并将Data Object ID换成一个新的值, 我们可以在AUL中用DESC命令来查看: AUL> desc anysql.t_truncate Storage(OBJ#=9976 OBJD=9977 TS=4 FILE=4 BLOCK=5235 CLUSTER=0) No. SEQ INT Column Name Type --- --- --- ----------------------------- ---------------- 1 1 1 TNAME VARCHAR2(30) NOT NULL 2 2 2 TABTYPE VARCHAR2(7) 3 3 3 CLUSTERID NUMBER 要恢复这个表的数据, 首先要在AUL中运行SCAN EXTENT命令, 因为Segment Header被格式化了, 所以Extent Map也可能丢失, 而Scan Extent则将扫描整个数据文件并将Extent分配信息写入AULEXT.TXT文件: AUL> SCAN EXTENT FILE 4 2006-12-18 21:32:10 2006-12-18 21:32:24 恢复的关键是要获得这个表原来的Data Object ID, 在这个例子中我在Truncate表后什么也没有做就关闭数据库进行恢复了. 从上面的DESC命令可以看出表的Segment Header是(4,5235), 而新的Data Object ID是9977, 老的Data Object ID我们可以从Segment Header的后面一个数据块中得到, 如果这个表有几个Free List Group, 则可能还要再后面几个块. 用AUL的ORADUMP命令来看一下后面一个块: AUL> ORADUMP FILE 4 BLOCK 5236 RDBA=0x01001474(4/5236)=16782452,type=0x06,fmt=0xa2,seq=0x02,flag=0x04 seg/obj=0x000026f8=9976,csc=0x0000.0006caf5,itc=3,typ=1 - DATA FLG=0x32, fls=0, nxt=0x01001471(4/5233)=16782449 ...... 可以看到原来的Data Object ID是9976, 现在可以恢复了, 先不指定原来的Data Object ID试试? AUL> unload table anysql.t_truncate; 2006-12-18 21:33:37 Unload OBJD=9977 FILE=4 BLOCK=5235 CLUSTER=0 ... 2006-12-18 21:33:37 接下来指定原来的Data Object ID, 再试试? AUL> unload table anysql.t_truncate object 9976; 2006-12-18 21:33:45 Unload OBJD=9976 FILE=4 BLOCK=5235 CLUSTER=0 ... P_MV_FACT_SALES|TABL