【TechTarget中国原创】有时候感觉做做什么事情都需要讲究天时的,上周对于我来说就不是一个很好的日子,在经过了近24小时的连续奋战后,客户新的6T存储终于替代了在风雨飘摇中运行了3年的3510老存储,本以为可以回家好好睡个觉,然后继续研究魔方,可就在这个时候,突然接到客户的claim:用户通过ERP无法登录到服务器,检查了下中间件运行正常,看了下中间件的日志,提示无法连接数据库!难道是监听没启动,telnet一下,发现数据库shutdown了,而且只能启动到mount模式,日志报:ORA-01251: Unknown File Header Version read for file number 21,23,27,39,51......,看了下存储正常挂载,没有报错!系统日志也没有说什么,无语了!
这么大规模的文件损坏,没一个去恢复有点不太现实了,当时幸好有前天晚间的veritas备份,把现在的库shutdown,封存起来,检查了下归档日志都正常,启动rman;
RMAN> startup mount
RMAN> restore database;
RMAN> recover database;
RMAN> sql'alter database open'; |
经过7个多小时提心吊胆的恢复后,系统终于恢复正常了!汗!揉了揉我这饥肠辘辘的肚子,拿了一个客户的康师傅香菇炖鸡面大吃起来!15mins later!在结束了和方便面的激烈战斗后,我们言归正传,通过上面的恢复后系统确实已经可以正常使用了,但问题的原因却还没有找到,回忆了一下整个迁移过程,怀疑应该是文件系统补丁的问题,最后更新了SOLARIS 9的PATCH BUNDLE后,问题解决,到目前为止系统运行良好,没有再次发生类似故障!
从这里也可以看出保障备份系统的安全可靠是多么的重要!在故障发生后有一份确实有效的数据对于维系企业的业务稳定运行是多么重要的!
PS:以上的情况是在数据文件损坏较多的情况下,图省劲的一种恢复方法,在数据量不大的情况下勉强可以,如果业务数据量很大,且损坏的文件不是很多的情况下,推荐可通过备份恢复单个数据文件,具体方法如下：
RMAN> restore datafile ***;
RMAN> recover datafile ***; |
石权，TechTarget中国Oracle论坛版主。ORACLE 9I,10G OCP,一直致力于业务可持续性，数据存储架构及ORACLE数据库的使用、优化、高可用及容灾的实施及方案设计。典型项目：东北电网异地容灾，沈阳铁路总局ORACLE数据库运维，沈阳煤气公司ORACLE数据库运维，中国移动沈阳数据中心数据库系统运维优化。