运维的故事,故障处理系列(二)

有什么工具可以辅助我们?
老姜和他的团队有条不紊的干着运维的活,团队有新人进来了也不怕,直接把运维的文档丢给新人,让他拿着看。直到有一天,有一个叫小李的新人提出了一些疑问。
”姜总,对于一些问题的搜集方法,我仔细的读了一遍,我想说,甲骨文还推出了一些工具如RDA,SQLT等可以用来辅助我们搜集一些信息,我们可以把这一部分也加入到这里面来。“
”哦?这个我也有听说,不过我们这些老人不习惯用这些新玩意罢了,不过你的提议很好,这一部分的补充就教给你来写吧。“
老姜心想:“这个新人还不错,刚来就知道向我们提一些建设性的意见。”
RDA
RAD是Remote Diagnostic Agent 的简写,是Oracle 用来收集数据库的参数信息和配置信息的一个常用工具,并且可以取到数据库相关主机的配置信息如主机内核参数,网络内核参数等。
使用RDA的步骤如下:

1.运行rda的配置.
./rda.sh –S
执行完成这个脚本后,会有一个向导界面让你根据你当前的数据库实际安装的产品完成初始化配置,完成配置后会在rad目录下生成配置文件setup.cfg。如果要修改里面的配置,直接修改setup.cfg文件即可。
2.进行采集
./rda.sh
执行rda.sh就开始进行采集了,如果要看到详细的采集过程,可以使用参数-v。

SQLT
SQLT可以帮助我们诊断一条SQL的性能问题,当你输入一条SQL语句,SQLT会连接到数据库,收集当前的和历史的执行计划,CBO的参数,统计信息,SCHEMA对象的元数据,配置参数等等。它可以快速的帮助我们定位执行计划改变的根本原因。
1.安装SQLT

sqlplus /as sysdba
SQL> @/home/oracle/sqlt/install/sqcreate.sql
Define SQLTXPLAIN password (hidden and case sensitive).
Password for user SQLTXPLAIN:
Re-enter password:
…
Default tablespace [UNKNOWN]: USERS  <== hidden and case sensitive
…
Temporary tablespace [UNKNOWN]: TEMP  <== hidden and case sensitive
…
Main application user of SQLT: test    <==administrator;grant SQLT_USER_ROLE
…
Oracle Pack license [T]: T  <==choose
…
SQCREATE completed. Installation completed successfully.

2.使用SQLT

SQL> start sqltxtract.sql sql_id

运行完成之后,我们就可以得到一份很强大的报告,SQLT是分析执行计划改变和sql效率低下最有效的工具之一
ORA CHECK
ORA Check这个工具和RAD有点类似,它主要用于检查RAC,CRS,ASM和GRID IInfrastructure中各个参数配置的情况。例如OS内核参数、OS软件包、数据库初始化参数等等。

1.安装ora check.
从oracle官方网站上下载解压。
$ chmod 755 orachk
2.运行rac check
./oracheck

同样的,运行完成之后会生成一份报告。方便我们进行检查。
Cluster Health Monitor
Cluster Health Monitor这个工具是在11.2才有的,它也是用来监控系统的资源(CPU、内存、Swap、进程、I/O和网络等等),和Os Watcher的作用看起来差不多,不过这个工具是直接调用操作系统的API的,可以降低对操作系统CPU的开销,默认是1秒钟收集1次,而在11.2.0.3版本上,降低到了每隔5秒调用一次。而OS Watcher则是调用的操作系统的命令。OS Watcher的优点是可以用traceroute检测私有网络之间的连通性。
CHM的安装很复杂,由于文章的篇幅有限,大家可以移步到Oracle官方的博客。
<>https://blogs.oracle.com/Database4CN/entry/
如何安装独立版的chm_oracle_cluster_health_monitor
小李把这些工具添加到了新的文档里面,并把文档交给老姜,老姜看完点了点头道:“嗯,有时候我们开SR,SR也让我们下载这些工具,把运行的结果打包上传给他们。只不过,我们还不是太习惯使用这些工具,不过新事物总会取代旧事物,不然社会怎么进步呢?所以我们这些老DBA虽然有经验,还是要时刻学习才能跟的上形式的发展呀!“

老姜的搜集案例?
把文档整理了一份新的版本之后,老姜通过邮件群发到了整个团队里面。然后给大家开了一个会,介绍了整个流程。

  • 一线监控人员请求支持,描述清楚故障的现象;
  • 二线和三线团队人员根据故障的现象做判断,给一线监控人员发送故障收集的脚本;
  • 一线人员进行基础的收集。收集完成后传给二线和三线团队的人员;
  • 二线和三线团队的人员开始分析问题,定位原因,如果需要进一步的交流,在发起第二次的Trace信息搜集脚本给一线监控人员;
  • 再次反馈回来,二线和三线在Trace文件齐全的情况下定位故障原因。

整个过程和Oracle Support的交流方式一样。不一样的是内部的这种邮件交流形式要明显高于Oracle Support的效率,有不清楚的地方也能直接通过电话沟通,而且二线和三线的人员可以不在现场。
讲完这些后,老姜问道:”还有什么补充的没有?“
看到没人发言,老姜就结束了会议,然后下班回家接孩子去了,人到了中年,有太多的牵绊在里面,孩子放学了也不能不管,数据库宕机了也不能不管,如何平衡好工作与生活对于老姜来说已经是一件刻不容缓的事情了,还好老姜在工作上技术管理做的还算到位,把各种事情安排的井井有条,工作效率也非常的高,只要不出什么大故障,老姜都能按时的下班。
接完孩子回家,老姜陪孩子玩了一会,突然手机响了,老姜一看,是小李打过来的电话,应该是出大问题了,老姜赶紧接了起来问:”小李,什么事情?“
只听到电话的另外一头小李慌慌张张的说到:”不好了,数据库挂掉之后起不来了?“
老姜问道:”起不来,是什么现象?“
“就是输入startup命令后一直hang在那个地方?后台没有任何的Trace,也没有任何的报错,操作系统的资源也是正常的。我看了数据库alert的日志,crs的日志,还有os watcher的日志,都是正常的!“
老姜又问道:”既然启动不了,那一定是hang住了,有没有做hang analyze的trace呢?“

小李一下子突然像被点醒了一样说道:”我居然忘了还有这一招。“
老姜默默的说道:”遇到问题不要慌张,要仔细的想想,我们现在能做什么,我们还能够再做什么?把这两个问题想清楚。“
“嗯,我现在立马去搜集!“
小李在启动数据库的那一台机器上又开了一个会话,使用了全局的方式进行了hang analyze数据的搜集。

SQL> oradebug setmypid
SQL> oradebug setinst all;
SQL> oradebug -g def hanganalyze 3;
……
Open chains found:
Chain 1:<cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<1/65/34910/gc buffer busy> -- <1/87/47375/enq: DX - contention>
Chain 2:<cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<1/146/33737/SQL*Net message from client>
-- <0/1320/3/0xf5001830/2407/enq: TT - contention>
-- <1/944/7836/enq: TT - contention>
Chain 3 : <cnode/sid/sess_srno/proc_ptr/ospid/wait_event> :
<1/526/1/No Wait> -- <1/965/8056/log file sync>
……

这一下问题就很明显了,启动数据库的这个会话1320被另外一个实例的146进程阻塞着。查询另外一个146进程的信息,居然是在Grid Control的agent。把这个进程杀掉之后,数据库顺利的启动了。 小李打电话跟老姜说:”姜总,搞定了,是另外一个节点的Grid Control的agent进程阻塞了它。“
”嗯,问题虽然现在修复了,但是你有没有想过这个问题产生的原因是什么啊?以后该如何再一次避免这类似的问题再次发生啊?“老姜押了一口接着说道:”故障处理的第一个阶段是要快速的修复问题,保障业务的连续性。而第二个阶段就是要找出故障产生的根本原因,并且保证以后此类故障再也不要发生。“
小李在电话另外那头笑嘻嘻的说:”现在先修复好了,就没那么大的压力了,至于原因我会尽量的查出来。“
”你小子可别偷懒啊,虽然现在恢复了,但是原因是一定要查清楚的,否则明天要是开故障会,我们没法交待,一起事故一定要有一个责任方,如果你说不清楚原因,那责任方就在我们这里了,知道吗?大客户和小客户在这一点上是不同的。对于故障的原因的查找,你一刻也不要懈怠。“
小李拉低了嗓子嘟哝着嘴道:“知道了!”
小李在Oracle support上搜索了一番,功夫不负有心人,他找到了一篇文章Sessions Hang Due to Self Deadlock on TT Enqueue [ID 948668.1]描述了这种类似的故障现象,最终把这起故障定位成了bug。</

分享到: 更多

Post a Comment

Your email is never published nor shared. Required fields are marked *