这样的故障通过oracle dul 是否可以找回数据？
本帖最后由 ALLSTARS_ORACLE 于 2017-5-3 16:34 编辑控制文件的checkont_change# 和v$datafile_header中checkpoint_change#一致（除了system表空间对应的数据文件，这个要落后很多，也就是说system tbs对应的数据文件太旧了），noarchivelog模式，再没有任何可用的备份，联机日志也损坏了，是否能用dul 处理？
1 如果这两个时间差中间, 对表做了move或创建了新表
这个时间差实在是太大了，因为system tbs对应的数据文件和其他数据文件头的checkpint_change#相差太大了！也就是说中间发生了太多的事情，出故障的时候没有保护现场，在场工程师没有专业的，后来的这个system tbs对应的数据文件不知道是从哪儿搞来的，谁也说不清楚
2 其他数据文件应该没有问题，因为他们头上的changepoint_change#都是一直的
方便的话msn上聊聊！
unload应该是dul 中的东西吧，我不懂
如何取出来？取出来的格式是什么？
system坏了，其他的能取出来吗？
控制文件的checkont_change# 和v$datafile_header中checkpoint_change#一致（除了system表空间对应的数据文件，这个要落后很多，也就是说system tbs对应的数据文件太旧了），noarchivelog模式，再没有任何可用的备份，联机日志也损坏了，是否能用dul 处理？
==> 当然可以 ， dul本来就是脏读 ， 是不纠结这些。 在不一致的时间段中有表move或表创建操作，但是由于所得到的系统表空间文件过旧可能这些信息未落地到系统表文件中。DUL在 Unload 过程中不会考虑到数据库一致性，它假定所有数据文件中的数据都是已经提交了的，因为没有了数据一致性的校验， DUL 实际做的是脏读，其并不能读出发生事故前未落盘的数据。
只要保证其它数据文件完整并最新即可。这样取出的业务数据也会是最近提交的。
读出的数据会被以SQL*Loader平文件的形式保存。
但是这会带来额外的存储空间和导出导入时间。
你也可以尝试PRM DUL的Data Bridge方式来进行恢复，这样能直接将数据库恢复到新库的表中。
页:
[1]