第二天,陈总随着上级领导来到A公司后却意外地发现,公司上下秩序井然,电销部门依然热火朝天地在进行工作,其它各部门的运作也毫无异样。IT主管介绍卧龙系统时也是一副成竹在胸的样子,完全不像在掩饰昨晚的事故……
究竟是A公司上下一起在演戏?还是老P骗了大家?又或者是……
正想着,上级领导发话了:你们的系统在性能和功能上的特点让我们非常开眼啊!不过,我们行业毕竟也是对数据可靠性与服务连续性有相当要求的行业,你们的系统在这方面有什么值得介绍的吗?
A公司IT主管仔细聆听着,在问题结束后略加思索了一两秒,然后回答领导的话:“不瞒您说,昨天出现了一个重大事故,核心存储上所有的数据库数据全部被删除掉了……”
话说到这,整个会议室里一片哗然。A公司IT主管双手下压,示意大家冷静。
“多亏了Oracle的ZDLRA零数据丢失恢复一体机系统。正是在这台设备的帮助下,我们仅花了两个小时多一点的时间就恢复了所有数据。这台设备是Oracle公司专为自己的Oracle数据库设计的。ZDLRA部署实施后仅需要在第一次上线工作时对数据库进行一次全备份,之后就是永远进行增量备份了,所以我们的备份窗口大为缩小。”
“但数据备份恢复也不能保证零数据丢失啊?”一位专家插嘴问道,显然他更感兴趣的是这此事件中数据零丢失是如何做到的。
主管说:“没错,刚才说的这项功能仅仅是解决了我们备份窗口的问题。能让我们在这此事故中毫发无损的关键是另一技术,也就是实时数据备份。大家想必都知道Oracle的数据卫士功能,也就是Data Guard功能。在ZDLRA中,Oracle利用了类似的机制,允许受保护数据库把自己的数据变更实时传输到ZDLRA,经过验证,我们一笔数据都没有丢。换句话来讲,我们应对这种事故或是说灾难的RPO是不可思议的‘0’。”
“那么你们怎么可能两个多小时就恢复这么庞大的数据库呢?”陈总终于忍不住发问了。
“首先,因为我们使用了Oracle FS1-2存储,所以我们可以使用Oracle数据库里神奇的HCC混合列压缩功能,让我们海量的数据能够在一面提升系统性能的同时一面被压缩至从前的几十分之一。这样一来,备份/恢复数据集也就相应的小了很多。再有,ZDLRA虽然永远都是在做增量备份,但是却能够在获得了增量备份之后利用自己的处理能力自动合成虚拟全备份。也就是说:永远都是在用增量备份的时间窗口和增量备份的存储空间去获取全备份的实际效果。所以,虽然我们已经有半年没有做过全备份了,但是在做恢复时我们完全不需要经历数据库恢复中痛苦的‘追增量’的步骤,所以恢复时间,也就是我们的RTO要比同等数据量的其它用户小出几十甚至几百倍……”