昨日Oracle灾难现场的经历

a13698822086

昨天刚发了要重新出发的帖子，没想到这么快就上了前线。　　本来希望早点回家的，不曾想突然接到一个北京本地金融客户的通知，Oracle RAC宕机，交易系统中断，迅速到现场救急。嗨马上出发吧……为啥去？还不是因为这个客户部署了我们的Oracle 容灾软件，随时要进行切换。于是，怀揣忐忑不安的心情，我和同事上路了。
　　现场气氛是紧张的，CIO是焦急的，DBA是无奈的，外援人员是茫然的，办公室传出大声争论的声音，情绪有点失控……Oracle RAC的listener不能启动，原因不明，业务不能做。不时的有公司领导过来询问下午3点之前能不能搞定，“一定尽快解决，即使3点不行，也不能耽误晚上的业务。”CIO嘴上自信，心里却彷徨的很，不能在浪费时间找原因了，尽快让业务恢复是第一要务。于是转头对我们说：“程工，先看看Oracle复制软件运行有没有问题，如果数据没问题，我就先把业务切换到深圳灾备中心的数据库上做，这边的RAC大不了重做了，我们还有个测试系主机可以应急。”听了这话，我们哪敢大意，马上在键盘上噼里啪啦一番，还好，虽然listener问题造成业务中断，可是Oracle复软件运行正常。“复制软件显示最后一笔交易有记录，14：23分。” CIO终于放心了--灾备系统关键时刻起了作用--紧张的神情至少放松了一半。
　　CIO理清了思路，环顾了手下的各位工程师，重新部署工作：1、业务系统链接到深圳数据库做交易；2、马上在metalink上填写问题，向Oracle求助（服务费不能白花）；3、交易做完后，将深圳的数据exp出来，传到北京测试系统，业务人员进行数据比对，看看容灾端的数据有没有问题；4、修复Oracle RAC，如果不行，明天用测试系统顶上。总之，一切的目标是保证明天的业务能运行……混乱的局面结束了，大家迅速行动起来，各司其职。
　　事实证明，Oracle的应急服务是靠不住的，至少我这么认为。火烧眉毛的时候，没有人上门，没有电话支持，DBA和CIO茫然的看着metalink的屏幕期待着远在美国或者印度的某个工程师传来的解决问题回帖。10分钟过去了，终于来了一条系统自动回复，让我们等待，失望值+1；20分钟过去了，看到一条不知谁写的英文的对我们问题解释。这真是发挥了全球的资源，哈哈。失望值+2；1个多小时过去了，终于有一个老外专家的留言，可是对解决问题没有任何帮助。CIO选择了放弃，他详细的看了Oracle响应的时间，没有关注任何其他内容，然后拿起电话不知道找谁抱怨去了。我不能完全想象他当时的心情，但这事儿给我留下了一个疑问，Oracle的服务凭什么要那么多钱？怎么算的？这也许是人世间最不公平的一个数字游戏。
　　不过我还是要感谢oracle，尤其是RAC。看见过好几次RAC崩溃，都是与其稳定性有关。呵呵，Oracle问题越多，我们的容灾软件就越受欢迎。大家都去用RAC吧……不好意思，心理有点阴暗啊！
　　总之后来是一切顺利，经过业务人员检查，容灾的数据没问题，业务也顺利的做完了。我们苦等了3个多小时没有任何遗憾，因为换回了一个满意的结果--CIO说通过这次问题，验证了你们的Oracle容灾软件的实用性，可以马上签署验收报告了。
　　出来的时候看见了天上的月亮和二环路永不中断的车流，肚子有点儿饿，很高兴大家都得到一个完美的结果。我相信客户的RAC很快就会修好，至于Oracle是不是会被拉来清算我不知道，不过我对自己的产品还是很满意的。呵呵，可以去吹牛了。