数据库底层存储恢复的疑惑
前几天的真实场景，由于我只能恢复少量数据，无法全部恢复数据而最终方式，丢失了几天的数据。希望大家可以一起聊聊这种问题的解决方式
场景如下：
OS：LINUX 5 X64
DB：10g R2 RAC + ASM
RMAN备份、归档均无
起因：
数据库中USER用户的表空间已满，需要添加数据文件。有人添加在NODE1节点上将数据文件建立在节点的本地磁盘的文件系统上，之后5分钟不到发觉怎么做不对，会有应该问题。
因此将数据文件移除，但是文件系统中物理文件还在。执行了：alter database datafile 11 offline drop；
现在问题来了，在这几分钟内，已经有其中几张表（比如5张吧）将数据写入到数据文件中，但是未全部MORE到这个数据文件。接手的时候已经是2个多小时后，期间业务没有停止，因此联机日志早已经switch掉。最终造成表意外被截断数据意外丢失，通过SELECT可以查询到原表的数目正确，但是具体条目缺少很多。无法正常IMPDP导出，因此只能从现有SELECT的结果集中将残余数据导出txt。
恢复尝试：
由于无法recover这个数据文件，因此尝试希望通过BBED修改文件头信息，比如控制文件中5个数据文件头信息其中4个正常的都是99999，offline的那个还是88888，最终修改头信息希望强制online失败。
最终开始尝试DUL的方式恢复，最终还是失败，因为无法取得任何数据机构或是用户信息等数据，查看数据文件中的使用块数为0（怀疑数据文件被人为删除后重新建过），但是非常疑惑的问题如下：
1、存储在本地的数据文件，但是ASM中针对这个数据文件有个标识性文件，如：user000000000xxxx00。这个文件除了标识数据文件的物理指向外，具体会不会记录一些什么信息会影响到DUL的数据抽取（比如：数据的格式转换）
2、基于以上情况下，用ASMDUL还是直接使用DUL就可以抽取（实际中两个都进行过尝试），
3、这种恢复如果出来的数据，应是基于什么形态的？因为没有数据字典和其它任何标识性信息，多张表的数据会如何区别？
由于这段时间太忙，而且本本的配置差点，前段时间尝试用ORACLEVM做个测试环境11g RAC，费劲装个GRID后就不动了。因此测试环境还存在难度。
希望有了解的，可以给说说，了解的不多的大家一起讨论下。也算是相互学习，谢谢！
页:
[1]