【流云】说说在Metalink上开SR这件事

看到一个朋友的MSN签名是：“我不是在开SR，就是准备在开SR”。心里颇有感触，这个朋友是做ORACLE ERP的，听说ORACLE ERP非常复杂，需要经常上METALINK求助。做为一名ORACLE DBA，METALINK是非常重要的资料来源，很多案例查一下METALINK都会有比较好的解决方案。不过METALINK也不是万能的，碰到没有相似的方案，你只能开SR求助于ORACLE SUPPORT了。

我在去年以前从来没有在METALINK上开过SR，基本上日常工作碰到的问题都可以通过种种办法查出原因并解决。但是在采用了最新的Oracle 10g R2 RAC数据库后，碰到了一系列莫名其妙的问题，这时候便只好开SR求助了。从开第一个SR到现在一共开了有十几个SR，真正解决问题的没有几个，往往都是不了了之。最开始便是让你发一通文件，这些文件分布在RAC的好几台主机，我只好一台台主机去找他们要求的文件最后面再打包上传。这是一个非常烦琐的过程，OS日志、CRS日志、CSS日志、alert log、TRACE文件……结果我好不容易将一大堆文件打包上传了，格式是.rar格式的，他们只能打开.zip格式的压缩包，要求重新上传。重新上传完以后，他们说根据已经上传的这些文件还是找不出原因，让部署Oracle的OS Watcher这个工具，等以后出现类似问题时再找原因。于是费了一番精力再部署这东西上去，另外他们还要求部署RDA，也一并弄上去。结果有一次再出现类似问题后，又是一通地找文件，最后压缩文件居然有500MB之大。在自己机器上上传了一天传不上去，就在同事的机器上挂机传了一天。这次传上去了，结果SUPPORTER跟我说传上去的文件太大了，他们也无法打开，让我再传至METALINK的FTP，好，再折腾，又费了一天传至FTP。结果他们还是没有找到问题，给我来这么一句：Now it seems to be LMS are started in Real time mode.We can check if the problem is re-producing or not。只能关掉SR，等待问题重现时再让他们诊断。于是这个SR到现在一个半月了，中间交涉了好多次，今天我还在上传他们要求的文件。

还有另外一次我们生产库的ASM磁盘头损坏，我们之前都没碰到这一类的故障，METALINK上也没有相应案例。我开了1级紧急SR，本来指望他们响应快一些，结果他们还是慢吞吞地在处理，最多的一句话是：Thank you for your patience。而且Oracle Support技术水平不一，有些SUPPORT根据内部文档给出一个建议后也不说明为什么要这么做，下一步要做什么？我们碰到ASM磁盘头损坏后第一个SUPPORT一个劲地让我们清空前1M的内容。问他为什么要清空前1MB的内容他就是不说，就说对照着做把结果告诉他就行了？我们问那清空后下一步怎么办？他就是不说，最后面发现他找到一个错误的解决案例，假如我们按这个SUPPORT的建议来处理的话，那么有可能会丢失整个数据库的数据。还是这个案例，后面问题解决了，我们要找出原因，他们说根据ORACLE的策略，只能另外开一个SR。另外开了SR后，换了另外一个SUPPORT来支持了，结果这个SUPPORT又不清楚具体的情况，于是我又费了一番周折把情况说明清楚，英语本来就不好，好不容易憋出几句英文把情况说明清楚，结果响应又巨慢无比。只好通过销售来推动，这次倒好了，说是因为时区的关系，我的SR负责的工程师刚好是非洲的，而且又出去度假去了。给我换了个印度的工程师，又是不熟悉情况，又是从头介绍情况，结果现在还是在处理状态。

还有一些其他的问题，总之指望METALINK来解决问题你需要足够的耐心，也不能指望能够解决紧急的问题。话说回来，通过网络来解决问题，在对具体环境不熟悉的情况下，他们是需要调查清楚情况后再做出处理，或许他们在工作的同时也在处理其他的案例，毕竟不仅仅就你这么一个案例。ORACLE也有自己的流程和策略，不过这个流程对于用户来说实在是太繁琐了。

SR，你让我怎么说你才好？

--EOF--