2014年初本人正在南方出差，某天晚上从南京坐高铁到了杭州。刚过午夜12点，正准备关灯就寝之际，突然响起了急促的手机铃声。多年从事Oracle服务工作的我们都有“天不怕、地不怕，就怕半夜来电话”的共同感受，果不其然，南京某政府客户数据库出问题了：大规模数据文件损坏！
客户的运维科长电话中心急火燎地希望我马上能回到南京，赶赴现场。但深更半夜的，高铁早没有了，怎么办？更重要的问题是，该客户还没有采购Oracle现场高级客户服务（ACS），按照Oracle公司政策，这种情况下，我们是不能赴客户现场做具体服务工作的。即便采购了ACS服务，作为解决方案售前顾问，我也不能随便去现场做这种实施工程师的事情。这就是大公司：条条框框很多。
但该客户正处于申请预算走流程，准备采购ACS服务的关键时期。于是，为安抚客户、保证客户满意度，我与销售同事商量决定采取折中方法：一方面我在远程提供电话技术支持，另一方面他去负责协调资源，看看能否特事特办，尽快申请到工程师资源赶到现场。
我这边马上通过科长手机与开发公司的DBA进行沟通，大致了解到问题原因和现象：原来他们在晚上欲对数据库表空间进行扩展，通过IBM HACMP软件对LV操作时出问题了，不仅损坏了LV，甚至第二个节点的VG都看不见了！我很快了解到以下Oracle的报错信息：ORA-00376和ORA-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）操作了。
将近2：00还没有客户反馈信息，我自己也因为一路旅途疲劳而睡过去了。是啊，毕竟是奔五的人了，精力远不如当年了。
临门一脚的遗憾
第二天早晨9：00醒来，放心不下的我急忙想给客户去电话，突然发现自己没有DBA的电话，也想到也许客户加班一通宵正在补觉呢。直至中午时分，我才拨通客户运维科长的电话，科长很高兴问题得到解决了！并感激说是某某第三方运维公司救了他们的命！怎么回事？待我要来DBA电话，才得知的确是第三方运维公司的人帮他们解决了问题。如何解决的呢？就是上述提到的两条关键命令！为什么DBA自己不做？原来他还是信心不足，也担心责任，希望有高手来操作。于是，他们通过多种管道，找到了一个第三方运维公司的人，并通过VPN连接到他们的系统，成功地在3：00实施了上述恢复操作。
唉，我和客户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软件的Bug和Patch问题；加强数据库后台运维管理规范，避免在联机操作情况下进行数据库文件的扩容操作（这次故障的另一个诱因）… …
亡羊补牢，为时未晚。重树客户对Oracle原厂服务的信心！这种信心不仅是对Oracle技术实力，还有服务态度、服务深度和服务质量。
最后，还需要强调Oracle多种服务的综合效益。那天晚上针对这么重大的问题，客户其实应该通过Oracle标准服务（PS）在metalink上提出1级SR，这样，第一时间Oracle后台GCS团队就会积极响应，如果客户再采购了ACS现场服务，GCS与ACS配合，将起到更好的效果，问题处理时间也将大大降低。
Leave a Reply