非常规数据恢复的几种场景（利用AUL恢复数据）

<<INTRO>>
同Oracle内部数据恢复工具DUL一样，利用AUL可以直接读取数据文件内容，当有坏块出现且无备份或者有备份但常规方法无法恢复数据库时，一旦常规手段无法解决问题，可以通过此工具拯救数据。
当然，备份重于一切，DUL、ODU、AUL等数据恢复方式只作为最后手段


<<STEPS>>
1)创建配置文件，如 aul.cfg，该文件数据来自 v$datafile的file#,rfile#,name列
# this is a demo AUL config file, wanna use it, create it manually
1 1 D:\Oracle\product\10.2.0\oradata\orcl\SYSTEM01.DBF
4 4 D:\Oracle\product\10.2.0\oradata\orcl\USERS01.DBF


2)在aul中打开配置文件并提取system表空间信息，如：
AUL>open aul.cfg
AUL>unload table user$;
AUL>unload table obj$;
AUL>unload table tab$;
AUL>unload table col$;
此时会生成 auluser.txt aulobj.txt aultab.txt aulcol.txt 四个文件


3.1)此时可在aul中查询表结构也可以开始恢复，如
AUL>list table scott
可得到恢复scott用户下的表的脚本（亦可输入list table scott to recover_scott.sql可把该输出做成脚本运行，通过运行该sql脚本来生成恢复脚本）执行生成的脚本，如：unload table scott.e to scott.e 即可在AUL目录下生成要恢复的sqlldr脚本[e.txt，e_sqlldr.ctl E_syntax.sql]


4) 利用sqlldr生成数据[e_sqlldr.ctl中可能需要修改成绝对路径，及添加表前缀为用户名]
<<Done>>


用AUL恢复truncate：
由于是对数据文件直接读取，故AUL等工具都是假定所有数据文件中的数据都是已经提交了的，没有对数据文件进行数据一致性的校验，做的实际上是脏读。不过关于这一点也是有点好处的，可以用此恢复truncate/drop误操作的表。
鉴于truncate只是将相应块头(segment的第一个块)格式化, segment中存储数据的部分都还存在, 到下次用时到才真正地重新格式化
方法类似，不同之处在第3步
<<STEPS>>
3.2）
AUL>desc scott.d     --得到其OBJD=52598 BLOCK=435
由于truncate表时，segment header被格式化，extent map可能丢失，可先扫描整个数据文件并将extent分配信息输出到文本中，如
AUL>scan extent file 4         --将结果输出到aulext.txt中
本例中，segment header是(4,435)    --(文件号,块号)
AUL>oradump file 4 block 443    --得到新的OBJD=52598，老的OBJD可以从segment header后面一个数据块得出，即OBJD=52597。若该表有多个Free List Group则可能还需要后面几个块，以此类推。使用oradump查看前一个块442信息，如下
AUL>oradump file 4 block 442
得出seg/obj=0x000cd7f=52607 即OBJD=52606


4)根据得出的OBJD生成恢复脚本，如：
AUL>unload table scott.d object 52606


5)利用sqlldr将数据注入到要恢复的表中完成恢复。
<<Done>>


<<SUMMARY>>
相对于Oracle内部恢复工具DUL，AUL更好地支持中文字符及大对象等（如DUL恢复CLOB对象会造成乱码）
主要用于数据库宕机后，无法启动实例，为最后拯救数据的手段；
要恢复相关DML操作而数据库无法闪回数据，或未启用闪回日志时要无停机恢复被truncate的表[比较适用于数据量不大的情况，若是数据量较大建议停机后用备份恢复]
最后手段。DUL的我朝山寨增强版。可能存在脏读。


切记：第一守则--备份重于一切！仅在常规手段无法恢复数据时采用
参考：http://www.anysql.net/download