Oracle Acs资深顾问罗敏 老罗技术核心感悟:又一次臭显摆之后的
作者为:? SHOUG成员 – ORACLE ACS高级顾问罗敏 现场直播救火过程 2014年8月初的某一天,突然接到东区服务销售经理电话:“老罗,你明天到上海出差,能否先到XX航空公司去一趟,他们一个重要系统宕机了。”据了解,该客户没有采购Oracle现场ACS服务,按Oracl
作者为:?
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日
Related posts:
- Oracle Acs资深顾问罗敏 老罗技术核心感悟:Clusterware是成熟产品吗?
- Oracle Acs资深顾问罗敏 老罗技术核心感悟:自动扫描SQL语句工具?
- Oracle Acs资深顾问罗敏 老罗技术核心感悟:分表还是分区?
- Oracle Acs资深顾问罗敏 老罗技术核心感悟:牛! 11g的自动调优和SQL Profile
- 【Oracle RAC调优】RAC多节点使用不同的gcs_server_processes参数可能导致gc cr multi block request等待事件
- Understand Oracle Validated Configurations
- How many LMS processes for Oracle Rac 9i?
- Oracle database 11g r2最新安装体验
- Oracle RDBMS Server 11gR2 Preinstall RPM For Oracle Linux 6
- Oracle Recommended Kernel Parameter settings for HP Itanium v3 11.31
原文地址:Oracle Acs资深顾问罗敏 老罗技术核心感悟:又一次臭显摆之后的感悟, 感谢原作者分享。
上一篇: 编码-php中ASCII转中文怎么转啊
下一篇: php如何判断http请求来自移动端?