熬了一周，终于熬到了周五，欢脱的双休已近在眼前。

可时间到了周五晚上8点。突然，H市某三甲医院的“急救”电话打给了MC工程师……

几分钟前，医院的emr系统数据库里某张重要的表被删除一个字段，导致整个电子病历系统无法使用！！

后背一凉！幸好是在晚上，否则患者肯定要炸锅了。

挂了电话，MC工程师迅速远程到服务器。经过检查发现，原来是该表字段已经删除，ddl操作无法闪回恢复，数据库是11g的库，只有一个当天凌晨rman物理备份。

一顿噼里啪啦后，凭借高超的职业技能，MC工程师当机立断，准备一个新环境将rman物理备份恢复出来，然后导出该表。这是唯一的办法。

客户立刻准备环境，晚上必须加班加点，希望能赶在次日早八点前将此表恢复，让系统正常使用。否则后果不堪设想！

准备新环境，搭建操作系统，安装数据库软件，争分夺秒和时间赛跑，终于在凌晨1点前将新环境准备完毕。

接下去就是拷贝备份集到新的环境。问题来了，400g的文件传输过去需要好几小时。你还能如期恢复系统吗？

在焦急的等待过程中，MC工程师发现系统有一个OGG同步到备库，该进程虽然停了，但仔细一查是停在删除字段操作的时候，也就是说ogg同步的数据正是所需要的最新的数据。（感到前方有一道曙光，明媚得睁不开眼）

工程师立刻在备库上导出这张表再导入的主库，搞定完成！电子病历系统重新可用，如愿赶在天亮前解决了问题。

作为MC素养的工程师，哪能只是解决眼下的故障问题？MC工程师向客户提出了升级备份策略的建议，为此emr系统搭建一套dataguard 物理备库并部署了每天定时的逻辑备份脚本。通过这样的备份恢复策略，能将业务损失降低至最小。

通过此次故障，可以得出这样的总结：

1.容灾软件的必要性，如果有容灾软件，可以在半小时内恢复业务。

2.对数据库的备份，有条件的话最好是物理逻辑各备份一次，这样此类情况也可快速恢复。