Oracle 大规模数据文件损坏ORA-00376和ORA-1110

2014年初本人正在南方出差,某天晚上从南京坐高铁到了杭州。刚过午夜12点,正准备关灯就寝之际,突然响起了急促的手机铃声。多年从事Oracle服务工作的我们都有天不怕、地不怕,就怕半夜来电话的共同感受,果不其然,南京某政府客户数据库出问题了:大规模数据文件损坏!

客户的运维科长电话中心急火燎地希望我马上能回到南京,赶赴现场。但深更半夜的,高铁早没有了,怎么办?更重要的问题是,该客户还没有采购Oracle现场高级客户服务(ACS),按照Oracle公司政策,这种情况下,我们是不能赴客户现场做具体服务工作的。即便采购了ACS服务,作为解决方案售前顾问,我也不能随便去现场做这种实施工程师的事情。这就是大公司:条条框框很多。

但该客户正处于申请预算走流程,准备采购ACS服务的关键时期。于是,为安抚客户、保证客户满意度,我与销售同事商量决定采取折中方法:一方面我在远程提供电话技术支持,另一方面他去负责协调资源,看看能否特事特办,尽快申请到工程师资源赶到现场。

我这边马上通过科长手机与开发公司的DBA进行沟通,大致了解到问题原因和现象:原来他们在晚上欲对数据库表空间进行扩展,通过IBM HACMP软件对LV操作时出问题了,不仅损坏了LV,甚至第二个节点的VG都看不见了!我很快了解到以下Oracle的报错信息:ORA-00376ORA-1110。其实这类错误比较普遍,处理过程并不复杂,本书第十一章 那些常见的Oracle错误就有相关错误的处理。我也很快在Metalink中找到了该类错误的若干篇官方处理文档。例如:《Resolving ORA-00376 Error Encountered in database (Doc ID 1339985.1)》,其中最主要的步骤就是两步:

SQL>recover datafile <数据文件名>;

SQL>Alter database datafile <数据文件名> online;

于是,DBA与我分析了错误现象和处理办法之后,DBA就准备对几十个数据文件进行恢复(recover)操作了。

将近200还没有客户反馈信息,我自己也因为一路旅途疲劳而睡过去了。是啊,毕竟是奔五的人了,精力远不如当年了。

临门一脚的遗憾

第二天早晨900醒来,放心不下的我急忙想给客户去电话,突然发现自己没有DBA的电话,也想到也许客户加班一通宵正在补觉呢。直至中午时分,我才拨通客户运维科长的电话,科长很高兴问题得到解决了!并感激说是某某第三方运维公司救了他们的命!怎么回事?待我要来DBA电话,才得知的确是第三方运维公司的人帮他们解决了问题。如何解决的呢?就是上述提到的两条关键命令!为什么DBA自己不做?原来他还是信心不足,也担心责任,希望有高手来操作。于是,他们通过多种管道,找到了一个第三方运维公司的人,并通过VPN连接到他们的系统,成功地在300实施了上述恢复操作。

唉,我和客户DBA从后场开始带球,运过中场,DBA带球至门前,结果关键时刻他犹豫了,要找个外援进场,外援按我们设计的角度和射门方式,轻松一脚,球就进了!于是,所有的镜头和光环都对准了这位外援。而DBA和我都被埋没了。呵呵。

更多的故事和反思

首先,我自己需要深刻反思:原以为已经有Oracle官方文档为依据,DBA该大胆操作了,可惜我当时在电话里没有把这个信心充分传递给DBA。另外,我怎么没有感觉到DBA信心不足,从而主动提VPN连接到他们系统,亲自进行操作呢?说明还是我自己主动性不够,导致现在上述局面。

其实,已经快知天命的人了,当然不会患得患失。更大的遗憾是通过此次故障的处理,客户对Oracle公司非常失望,其它公司都派人去现场了,唯独Oracle受限于公司政策,销售、技术一个人都没去现场。尽管我在远程提供了一定的支持,但客户领导并不充分知晓。

事后,更得知客户之所以找到第三方公司的人,是因为Oracle公司另一个服务部门一位已经离职的的销售牵线搭桥的结果。而由于Oracle内部竞争等因素,该销售并没有在客户面前对我们ACS团队美言,反而起到了负面的效果。唉。内部倾扎啊。

再者,尽管Oracle政策比较僵化,尽管国内客户不能从感情上理解Oracle这种一板一眼的行事风格,也幸亏当天的故障并不难解决,但假设当天的故障是某个很难解决的问题,例如Oracle Bug呢?还是说明针对重大的生产系统,客户应该采购Oracle高级运维服务包,有了这种服务包,Oracle完全可以按正常流程和渠道进行操作:我们会第一时间通过电话、远程登录等方式进行处理,同时也将第一时间派出工程师赶赴现场,而且会不计成本地帮助客户解决问题,恢复生产,甚至会找出问题根源,防止问题的再次爆发。—- 这就是Oracle高级服务包的价值。

这个案例也是典型的先有鸡,还是先有蛋的问题,呵呵。Oracle的心态是:出了这么重大的问题,赶紧采购Oracle高级服务包吧。客户的心态是:我出了这么重大的问题,你Oracle都不管不顾,以后买了你们Oracle高级服务包,能尽心尽力为我服务吗?服务也要讲感情的。

的确如此,服务是人去实施的,人与人交往是要讲感情的。为弥补此次故障处理的不足,我们已决意在遵循Oracle政策的前提下,去做进一步的工作了。例如,告诉客户ORA-00376故障的官方处理流程;帮助客户梳理未来故障处理流程;给客户建议一定要解决此次故障的真正原因:HACMP软件的BugPatch问题;加强数据库后台运维管理规范,避免在联机操作情况下进行数据库文件的扩容操作(这次故障的另一个诱因)… …

亡羊补牢,为时未晚。重树客户对Oracle原厂服务的信心!这种信心不仅是对Oracle技术实力,还有服务态度、服务深度和服务质量。

最后,还需要强调Oracle多种服务的综合效益。那天晚上针对这么重大的问题,客户其实应该通过Oracle标准服务(PS)在metalink上提出1SR,这样,第一时间Oracle后台GCS团队就会积极响应,如果客户再采购了ACS现场服务,GCSACS配合,将起到更好的效果,问题处理时间也将大大降低。


Posted

in

by

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *