Oracle本机上错删非系统的DBF的文件恢复-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

Oracle本机上错删非系统的DBF的文件恢复

简介:

 

情况是这样的,昨天下午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空间数据库的备份与恢复 ,备份的文件绝非一个文件夹的数据;

数据安全大于天,一定要做好数据定期备份与错误恢复的基本功,做到具备系统性的数据库维护能力。

 

没有整理与归纳的知识,一文不值!高度概括与梳理的知识,才是自己真正的知识与技能。 永远不要让自己的自由、好奇、充满创造力的想法被现实的框架所束缚,让创造力自由成长吧! 多花时间,关心他(她)人,正如别人所关心你的。理想的腾飞与实现,没有别人的支持与帮助,是万万不能的。




    本文转自wenglabs博客园博客,原文链接:http://www.cnblogs.com/arxive/p/6432193.html,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章
最新文章
相关文章