rman备份集中数据文件的SCN不一致，导致备份无法正常恢复...
请教一个oracle的极端问题。
环境：
oracle 9i 9.2.0.1;
solaris 9
sun服务器双机
直连共享sun存储
问题：rman全备中的数据文件的SCN不一致，需要恢复时，无法正常使用，因为其中更老SCN的数据文件所需要的归档已经不存在了。
分析：造成问题的原因可能是用户很早以前在SQL客户端软件中，手工执行过alter tablespace xxxx begin backup命令，但没有end backup，同时又开启了rman后台定时备份脚本，导致两种备份模式并行工作，rman备份的数据涉及表空间xxx的，SCN一直保持不变（很早以前），而数据库系统一直没关闭。直到前两天因业务需要，重启数据库系统，发现启动不了，open database时会报表空间xxxx相关的datafile无法打开。用现有的rman备份也无所法恢复，因为才发现备份集里与xxxx相关的datafile的scn太老了，比如xxxx相关的数据文件SCN是去年某月的，而其它数据文件的SCN前两天的，恢复需要很多以往的归档日志（可能还需要更早的全备），而这些归档日志（和全备）早就被用户删除了，导致数据无法恢复。
请教：
显然，造成这种结果的原因是数据库管理不规范。
但现在这种情况下还有什么好的数据备份恢复方法吗？
另外一个奇怪的问题，为什么rman全库备份时从来不报错？rman的备份策略是每天全库备份+归档备份，rman真的对表空间xxxx的数据长期未备份吗？它默默地进行的全库备份，原来是“骗人”的？或者说，当alter tablespace xxxx begin backup，且并未end时，rman对表空间xxxx的所谓备份全是“tablespace offline”状态下的备份？那它怎么能长久地记住xxxx表空间的某一历史时刻的“静止状态”呢？这相当于一个很早前的一个表空间快照。。
首先是rman备份的数据文件是否包含了最近的数据，如果没备的话，恢复也没用了。
页:
[1]