Oracle Acs资深顾问罗敏 老罗技术核心感悟:又一次臭显摆之后的感悟

作者为: 

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

 

 

  1. 现场直播救火过程

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

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

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

 

  1. 现场号脉

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

 

  1. 发现了更严重问题

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

 

  1. 客户的纠结和痛苦

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

 

  1. 更多的感和悟

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

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

 

 

2014年10月6日

Comment

*

沪ICP备14014813号

沪公网安备 31010802001379号