作者为:? SHOUG成员 – ORACLE ACS高级顾问罗敏 现场直播救火过程 2014年8月初的某一天，突然接到东区服务销售经理电话：“老罗，你明天到上海出差，能否先到XX航空公司去一趟，他们一个重要系统宕机了。”据了解，该客户没有采购Oracle现场ACS服务，按Oracl

作者为:?

SHOUG成员 – ORACLE ACS高级顾问罗敏

1. 现场直播救火过程

2014年8月初的某一天，突然接到东区服务销售经理电话：“老罗，你明天到上海出差，能否先到XX航空公司去一趟，他们一个重要系统宕机了。”据了解，该客户没有采购Oracle现场ACS服务，按Oracle公司先有鸡后有蛋的政策，我们是不能去现场做任何实质性的服务工作的。但从国情出发，更考虑客户感受和客户关系，作为ACS服务售前顾问去现场协助分析和解决问题，并进一步了解客户现状和需求，也是合情合理的，并不是趁火打劫哦，呵呵。于是，我决定调整行程，改签第二天头个航班，中午就飞到了上海。

在虹桥机场上了出租车之后，一个劲儿给师傅说抱歉的话，因为师傅可能等了几个小时，碰上我这个倒霉鬼，去机场附近的客户现场只需要起步价。师傅还是非常敬业，顶着中午火热的太阳，10分钟就把我拉到了该航空公司的信息中心大楼。

待我到达现场时，客户运维部门领导早已是翘首以待，把我热情引到会议室，更是把整个运维部门和开发单位的几十号人都召集到会议室，而且还有负责应用开发的印度专家。于是，在客户简短地介绍了系统概况和故障情况之后，就让我直接连入该系统，并把我电脑连接到大屏幕上，几十双眼睛开始齐刷刷地现场观摩Oracle顾问如何救火了，老罗同志又要开始一次臭显摆了，呵呵。

2. 现场号脉

说实在的，尽管已经身经百战，但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，也就是无法获取系统宕机时的操作系统数据，特别是内存和进程数据，因此，尚无法做出准确判断。

3. 发现了更严重问题

除了上述不良应用可能导致内存消耗殆尽的问题之外，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环境的上述内部存在问题共同导致了宕机故障。

4. 客户的纠结和痛苦

连环境参数都没有配置好，就强行把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的运行情况，太符合逻辑了。

5. 更多的感和悟

除了上述对原厂和第三方厂商在RAC安装和实施方面的专业性和非专业性感慨之外，更多的感悟还有：

• 千万别小看Oracle软件安装，特别是集群和RAC安装，这的确是一项非常专业化的工作。一个环境参数配置不合理，很可能给系统埋下深深的隐患。
• 遇到问题和故障的时候，还是应该求真务实，尊重客观规律。不应该过多考虑面子，尤其是领导的评价。把一个事情做得扎扎实实、完完美美，虽然可能付出很大的代价，但最终还是很有面子，领导也会满意的，呵呵。
• 为Oracle服务部门再做个推销，呵呵。Oracle各种专业化的服务部门，无论是后台提供标准服务的PS部门，还是前台提供现场服务的ACS部门，都是专业化的团队，既相互合作，又相互补充，对客户都是有价值的，都是不可或缺的。以该案例为例，后台PS部门可以充分发挥产品实施分析和与研发部门沟通的优势，而前台ACS部门则通过现场与客户沟通，了解更多系统和应用背景，并帮助客户与PS部门沟通，共同推进问题的分析和解决。
• 更多的感和悟留给大家… …

2014年10月6日

Related posts:

1. Oracle Acs资深顾问罗敏 老罗技术核心感悟：Clusterware是成熟产品吗?
2. Oracle Acs资深顾问罗敏 老罗技术核心感悟：自动扫描SQL语句工具？
3. Oracle Acs资深顾问罗敏 老罗技术核心感悟：分表还是分区？
4. Oracle Acs资深顾问罗敏 老罗技术核心感悟：牛! 11g的自动调优和SQL Profile
5. 【Oracle RAC调优】RAC多节点使用不同的gcs_server_processes参数可能导致gc cr multi block request等待事件
6. Understand Oracle Validated Configurations
7. How many LMS processes for Oracle Rac 9i?
8. Oracle database 11g r2最新安装体验
9. Oracle RDBMS Server 11gR2 Preinstall RPM For Oracle Linux 6
10. Oracle Recommended Kernel Parameter settings for HP Itanium v3 11.31

原文地址：Oracle Acs资深顾问罗敏 老罗技术核心感悟：又一次臭显摆之后的感悟, 感谢原作者分享。