SHOUG成员 – ORACLE ACS高级顾问罗敏
- 现场直播救火过程
2014年8月初的某一天，突然接到东区服务销售经理电话：“老罗，你明天到上海出差，能否先到XX航空公司去一趟，他们一个重要系统宕机了。”据了解，该客户没有采购Oracle现场ACS服务，按Oracle公司先有鸡后有蛋的政策，我们是不能去现场做任何实质性的服务工作的。但从国情出发，更考虑客户感受和客户关系，作为ACS服务售前顾问去现场协助分析和解决问题，并进一步了解客户现状和需求，也是合情合理的，并不是趁火打劫哦，呵呵。于是，我决定调整行程，改签第二天头个航班，中午就飞到了上海。
在虹桥机场上了出租车之后，一个劲儿给师傅说抱歉的话，因为师傅可能等了几个小时，碰上我这个倒霉鬼，去机场附近的客户现场只需要起步价。师傅还是非常敬业，顶着中午火热的太阳，10分钟就把我拉到了该航空公司的信息中心大楼。
待我到达现场时，客户运维部门领导早已是翘首以待，把我热情引到会议室，更是把整个运维部门和开发单位的几十号人都召集到会议室，而且还有负责应用开发的印度专家。于是，在客户简短地介绍了系统概况和故障情况之后，就让我直接连入该系统，并把我电脑连接到大屏幕上，几十双眼睛开始齐刷刷地现场观摩Oracle顾问如何救火了，老罗同志又要开始一次臭显摆了，呵呵。
- 现场号脉
说实在的，尽管已经身经百战，但IT系统如此复杂，应用更是如此变化多端，IT新技术也是层出不穷，没有一个专家敢牛烘烘地说手到病除的。但是，分析诊断问题的思路和方式还是相通的，那就是先了解系统概况，然后再了解故障情况，特别是收集故障相关数据，再询问故障前是否有应用或环境的重大变更，再逐步分析和定位问题，并给出最终解决问题方式。以下就是与该系统和故障相关的上述几方面具体情况：
运行在2节点的SUN Solaris平台；数据库版本为11.2.0.4 RAC；数据库容量达到1.6TB。
- 故障现象分析
2014-08-01 14：14左右， 实例1重启；2014-08-01 14:28 实例2重启；2014-08-01 15:15:44 节点一被驱逐。故障发生之前，节点1的内存消耗非常高，达到了100%，并产生了大量SWAP操作。节点2的内存消耗也达到了90%。但客户没有安装OSWatcher，也就是没有采集到故障前后的操作系统数据。同时，RAC、GI的alert.log、crsd.log等日志文件也没有记录下明显的错误数据。
- 故障前变更情况
经客户介绍，该系统在8月1日之前应用软件安装了新补丁，即新部署了一些应用软件。通过对宕机之前的13：00 – 14：00 AWR报告分析，这些新应用软件中的3条SQL语句非常消耗资源。RAC重启之后，新部署的应用软件进行了回退，目前RAC系统运行平稳。
可见，新应用软件问题可能是导致RAC宕机的重要因素！
- 应用深入分析
由于新应用很可能是导致RAC宕机的重要原因，而且负责该应用模块开发的印度专家也在现场，于是我们首先对其中一条SQL语句共同进行了深入分析。限于篇幅，我们只摘取如下的主要部分：
首先，该语句非常消耗资源，Buffer Gets和Disk Reads都非常之高，运行时间更是长达555秒。通过对该语句执行计划的分析，我们发现该语句对三个大表进行全表扫描。而导致全表扫描的直接原因是语句中如下部分的UPPER函数的使用：
AND ((CUSDOCINF.DOCTYP = :2 AND UPPER(CUSDOCINF.DOCNUM) = UPPER(:3)) OR
(CUSDOCINF.DOCTYP = :4 AND UPPER(CUSDOCINF.DOCNUM) = UPPER(:5)))
事实上，当我们去掉UPPER函数，或者将OR操作修改为in操作之后，Oracle执行计划非常合理，语句效率非常之高。
可是，待我仔细观察，发现开发人员其实已经设计了UPPER函数索引，而且也采集了统计信息，但为什么Oracle不走函数索引呢？正纳闷之际，印度工程师主动告诉我Oracle Bug 14630247会导致Oracle优化器不选择函数索引，而是采用全表扫描。于是，我马上通过Oracle相关网站分析了Bug 14630247及相关的Bug 14828235 ,特别是阅读了《Bug 14828235 ORA-7445 [evaopn3] from query with Function based index and ORDER BY clause》之后，发现该Bug已经在11.2.0.4中修复，并且该Bug若爆发，应该有ORA-7445错误。但是，上述语句并没有导致ORA-7445错误，而且该系统已经是11.2.0.4版本，因此是否由于是Bug 14630247或Bug 14828235导致，我在现场尚无法判断。于是建议针对该问题，请客户再创建一个SR，由 Oracle GCS和研发部门确认这些Bug是否已经在11.2.0.4 for Solaris平台修复，或者是Bug再次爆发。但作为ACS现场服务团队，我建议在应用层面采取一些Workaround措施来规避该问题，例如是否取消upper函数，或者取消or运算。
好了，与应用相关的问题在现场只能暂时分析到此了。但这是否是导致上述故障的唯一因素呢？即是不是因为这些语句消耗了太多资源，而导致宕机呢？由于客户没有安装OSWatcher，也就是无法获取系统宕机时的操作系统数据，特别是内存和进程数据，因此，尚无法做出准确判断。
- 发现了更严重问题
除了上述不良应用可能导致内存消耗殆尽的问题之外，RAC环境本身是否有问题呢？于是，我接下来通过Oracle的cluvfy工具对RAC环境进行检查，很快就发现更严重问题了！部分细节如下：
grid@ffpdb01:-bash:~$cluvfy comp sys -n all -p crs -verbose
Verifying system requirement
Check: Total memory
Node Name Available Required Status
———— ———————— ———————— ———-
ffpdb02 96GB (1.00663296E8KB) 2GB (2097152.0KB) passed
ffpdb01 96GB (1.00663296E8KB) 2GB (2097152.0KB) passed
Result: Total memory check passed
… …
Check: Hard limits for “maximum open file descriptors”
Node Name Type Available Required Status
—————- ———— ———— ———— —————-
ffpdb02 hard 8192 65536 failed
ffpdb01 hard 8192 65536 failed
Result: Hard limits check failed for “maximum open file descriptors”
… …
Check: Kernel parameter for “tcp_smallest_anon_port”
Node Name Current Required Status
———— ———————— ———————— ———-
ffpdb02 32768 9000 failed (ignorable)
ffpdb01 32768 9000 failed (ignorable)
Result: Kernel parameter check failed for “tcp_smallest_anon_port”
Check: Kernel parameter for “tcp_largest_anon_port”
Node Name Current Required Status
———— ———————— ———————— ———-
ffpdb02 65535 65500 failed (ignorable)
ffpdb01 65535 65500 failed (ignorable)
Result: Kernel parameter check failed for “tcp_largest_anon_port”
Check: Kernel parameter for “udp_smallest_anon_port”
Node Name Current Required Status
———— ———————— ———————— ———-
ffpdb02 32768 9000 failed (ignorable)
ffpdb01 32768 9000 failed (ignorable)
Result: Kernel parameter check failed for “udp_smallest_anon_port”
Check: Kernel parameter for “udp_largest_anon_port”
Node Name Current Required Status
———— ———————— ———————— ———-
ffpdb02 65535 65500 failed (ignorable)
ffpdb01 65535 65500 failed (ignorable)
Result: Kernel parameter check failed for “udp_largest_anon_port”
… …
Verification of system requirement was unsuccessful on all the specified nodes.
grid@ffpdb01:-bash:~$
我的妈呀，原来这个系统的操作系统核心参数和网络参数都没有满足Oracle RAC安装需求，这将严重导致Oracle GI和RAC运行不正常！这很可能是导致RAC宕机的更重要原因。当然，准确而言，应该是外部应用压力陡增，与RAC环境的上述内部存在问题共同导致了宕机故障。
- 客户的纠结和痛苦
连环境参数都没有配置好，就强行把11g RAC给安装上去了，并带病开始工作了。真牛啊，谁做的？客户领导的回答有点支支吾吾，一会儿说是Oracle公司产品售前部门做的，一会儿又说是Oracle公司硬件部门做的。好了，别深究了，别让领导难堪了。我猜想很可能是找一个第三方本地公司做的安装，而该公司技术人员很可能连Oracle安装文档都没有仔细阅读，具体就是《Oracle® Grid Infrastructure Installation Guide11g Release 2 (11.2) for Oracle Solaris》，更具体就是该文档中的“2.10 Verifying UDP and TCP Kernel Parameters”、“2.11 Checking Resource Limits for Solaris”等小节。唉，很可能是第三方公司技术人员在百度、Google中随便找了篇简洁版的RAC安装短文，就在航空公司这么重要的系统上开练了。
这就是非专业服务团队和原厂专业服务团队的差别，原厂技术人员起码会仔细阅读Oracle官方安装文档，更会以Oracle RAC实施方法论为指导，结合Oracle若干最佳实践经验，在RAC软件和补丁安装、高可用性配置、应用部署等方面展开全面深入的实施，确保数据库RAC实施的高质量。
现在怎么办？是否直接修改几个内存unlimited参数和TCP、UDP参数就能解决问题，确保RAC不宕机了吗？作为现场工程师，毕竟不是产品直接研发者，我无法给出这种承诺。于是，建议客户通过SR进一步寻求Oracle后台服务团队和产品研发部门的确认。但是基于个人以往类似经验，最好的办法是把环境参数重新配置好之后，把RAC系统重新安装一遍。
于是，一方面我提出了重新安装的建议，另一方面为降低对生产系统停机的影响，进一步提出了先安装一个Data Guard 环境，将现有生产系统数据切换到Data Guard环境，再重新安装现有生产系统的11g RAC，并切换回11g RAC的建议。但我这些重新安装建议一出口，立马引来客户领导一阵叹息和苦衷：“系统刚上线还不到一个月，重新安装如何给领导解释？”“唉，你们要是早来一个月，上线前就发现环境问题就好了，那时候重新安装没问题。”
还有更纠结、更痛苦的问题：“罗工，你们Oracle公司能提供这种证据吗？证明我们这次RAC宕机，就是因为环境参数配置不合理导致的？”。这如何证明啊？OSWatcher也没有安装，其它日志文件也没有捕获到有价值的信息。更重要的是，根据以往经验，若发现Oracle软件安装都有问题，Oracle后台根本不会继续进行进一步的分析和诊断，一定会建议客户重新安装软件之后再说。是啊，若A本身就错了，基于A的B也跟着出错了。那Oracle停止分析B，要求先纠正A，再看B的运行情况，太符合逻辑了。
- 更多的感和悟
除了上述对原厂和第三方厂商在RAC安装和实施方面的专业性和非专业性感慨之外，更多的感悟还有：
- 千万别小看Oracle软件安装，特别是集群和RAC安装，这的确是一项非常专业化的工作。一个环境参数配置不合理，很可能给系统埋下深深的隐患。
- 遇到问题和故障的时候，还是应该求真务实，尊重客观规律。不应该过多考虑面子，尤其是领导的评价。把一个事情做得扎扎实实、完完美美，虽然可能付出很大的代价，但最终还是很有面子，领导也会满意的，呵呵。
- 为Oracle服务部门再做个推销，呵呵。Oracle各种专业化的服务部门，无论是后台提供标准服务的PS部门，还是前台提供现场服务的ACS部门，都是专业化的团队，既相互合作，又相互补充，对客户都是有价值的，都是不可或缺的。以该案例为例，后台PS部门可以充分发挥产品实施分析和与研发部门沟通的优势，而前台ACS部门则通过现场与客户沟通，了解更多系统和应用背景，并帮助客户与PS部门沟通，共同推进问题的分析和解决。
- 更多的感和悟留给大家… …
2014年10月6日
Leave a Reply