情况是这样的，昨天下午2点，我将Oracle离线了，然后复制一份E:\Files\Oracle\oradata\xxxxxx目录下的文件。其中xxxxxx为本机上的数据库名。
然后晚上22点钟时，我在ArcGIS中对表空间YYYY_SDE进行了致命错误的修改，便随手一删，把E:\Files\Oracle\oradata\xxxxxx\tablespase\YYYY_SDE.DBF删除了，并用昨天下午2点钟冷备份的该文件替换了这个文件。
结果数据库一直启动不了。报如下错误：
删除系统原来'E:\FILES\ORACLE\ORADATA\xxxxxx\TABLESPASE\'目录下的最新的HHCH_SDE.DBF, 想用冷备份的先前文件恢复数据库的该表空间，结果重新启动数据库时实例后报以下错误：
ORA-01113: 文件 7 需要介质恢复
ORA-01110: 数据文件 7:
'E:\FILES\ORACLE\ORADATA\xxxxxx\TABLESPASE\YYYY_SDE.DBF'
由于直接拷贝E:\Files\Oracle\oradata\xxxxxx目录并非为冷备份，之能算是只备份了一部分的文件。所以无法用recover命令加载这个文件，日志文件缺失。
问题演变为如何使用单一的.dbf文件， 去恢复Oracle数据库的表空间了。
解决方案：
首先明确的是本机上的环境，仅一个.dbf被错误替换的场景。
解决办法是死马当做活马医，还是希望能救活的。就把下午2点钟备份的E:\FILES\ORACLE\ORADATA\xxxxxx下的文件，全部拷贝到数据库的那个目录下。
然后重启数据库，但是会报ORA--00214错误，后来索性将CONTROL02.CTL控制文件也给替换了，替换为CONTROL01.CTL，名字直接改为CONTROL02.CTL。也就是
然后替换掉E:\Files\Oracle\flash_recovery_area\xxxxxx\CONTROL02.CTL为E:\Files\Oracle\oradata\xxxxxx\CONTROL01.CTL
重启数据库，奇迹出现了，竟然好了。谢天谢地！
总结：
万万使不得，自己直接删除Oracle数据库中的文件；
万万记住不能看不靠谱的网络博客，比如这次冷备份说直接让我备份数据库目录下的文件即可实现冷备份。错了。完整的冷备份是应该是Oracle空间数据库的备份与恢复 ，备份的文件绝非一个文件夹的数据；
数据安全大于天，一定要做好数据定期备份与错误恢复的基本功，做到具备系统性的数据库维护能力。
