Chinaunix首页 | 论坛 | 博客
  • 博客访问: 41656
  • 博文数量: 2
  • 博客积分: 540
  • 博客等级: 中士
  • 技术积分: 120
  • 用 户 组: 普通用户
  • 注册时间: 2007-09-11 07:36
文章存档

2008年(2)

我的朋友

分类: 数据库开发技术

2008-11-14 09:07:13

    昨天刚发了要重新出发的帖子,没想到这么快就上了前线。
    本来希望早点回家的,不曾想突然接到一个北京本地金融客户的通知,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是不是会被拉来清算我不知道,不过我对自己的产品还是很满意的。呵呵,可以去吹牛了。
                                                             昨日Oracle容灾现场经历
 
 
 
Oracle 容灾 rongzai DBA CIO
阅读(805) | 评论(0) | 转发(0) |
0

上一篇:Restart

下一篇:没有了

给主人留下些什么吧!~~