系统应急处理过程的问题排查方案.docxVIP

?

?

系统应急处理过程的问题排查方案

?

?

【导读】作者分享了一次系统应急处理中的惊险经历，并借此总结了应用层、数据库、网络中的故障排查点以及一些非技术因素可能引起的问题。智能化运维还有很长的路，当下的运维还应脚踏实地，做好该做的工作。

经历了一次系统应急处理，可谓惊险。简单回顾一下，梳理排查思路，算是总结，也是学习。由于涉及些隐私问题，所以屏蔽了一些信息，只阐述技术问题。

应用逻辑并不很复杂，需要访问远端数据库，进行一些数据交互的操作，从应用端日志看，出现问题的时候，现象就是卡在某一步，不动了，hang的状态，具体来讲，就是卡在数据库操作，比如SELECT语句，正常来讲，毫秒级就能返回，但当前几秒、几十秒、甚至几十分钟，都没有响应。选择重启应用，偶尔能起作用，但随着时间推进，效果不很明显。

由于很久没有更新过应用，软硬件环境，同样许久未变更，突然出现这现象，第一感觉，就是怀疑数据库层面(Oracle)，例如SQL语句执行计划的突变，或者数据量累积起来，没有清除策略，导致到达一个临界点，影响CBO的判断。

排查一：应用层面是否有问题

应用已经许久未更新了，包括软硬件环境，而且从应用层面，几乎将所有异常，都记录于日志当中了，换句话说，只要是应用问题，日志都会记录。但出现问题时，应用未有任何的报错。

trace了出现问题的应用进程，也并未出现任何异常。

因此初步判断，不是应用层面的问题。

排查二：数据库层面是否有问题

我们团队的DBA-albert久经沙场了(P.S.推荐一下，albert的博客/)，第一步就是让对端DBA用如下SQL，检索当前数据库的等待事件，如果是数据库层面的问题，操作慢，就一定在等待着什么

selectusername,event,count(*)fromv$sessionwhereusername=****groupbyusername,EVENT;

但从实际来看，没有任何异常的等待，数据库层面都比较正常。

此时，另一个现象，就是我从应用服务器，sqlplus几十秒才能登陆，执行应用使用的语句，几十秒未返回，其中sqlplus执行cancel出现过，

oerr?ora?1215212152,?00000,?TNS:unable?to?send?break?message//?*Cause:??Unable?to?send?break?message.?Connection?probably?disconnected.//?*Action:?Reestablish?connection.?If?the?error?is?persistent,?turn//ontracingandreexecutetheoperation.

又让对端DBA做了如下操作：

本地sqlplus登陆。

速度很快。

本地通过监听登陆数据库。

速度很快。

本地执行SQL语句

速度很快。

因此初步判断，不是数据库层面的问题。

排查三：网络层面是否有问题

排查网络问题，常用的方法，可能就是如下这些了，

ping

telnet

tnsping

traceroute(Linux)

前三个很好理解，第四个指令，其实在排查网络问题时，非常实用。

traceroute最早是由VanJacobson在1988写出的小程序。可以让我们看到IP数据报从一台主机传到另一台主机所经过的路由及RTT(往返时间)。通过traceroute我们可以知道信息从你的计算机到互联网另一端的主机是走的什么路径。当然每次数据包由某一同样的出发点(source)到达某一同样的目的地(destination)走的路径可能会不一样，但基本上来说大部分时候所走的路由是相同的。linux系统中，我们称之为traceroute，在MSWindows中为tracert。traceroute通过发送小的数据包到目的设备直到其返回，来测量其需要多长时间。一条路径上的每个设备traceroute要测3次。输出结果中包括每次测试的时间(ms)和设备的名称(如有的话)及其IP地址。

从工作原理上，traceroute程序的设计是利用ICMP及IPheader的TTL(TimeToLive)栏位(field)。首先，traceroute送出一个TTL是1的IPdatagram(其实，每次送出的为3个40字节的包，包括源地址，目的地址和包发出的时间标签)到目的地，当路径上的第一个路由器(router)收到这个datagram时，它将TTL减1。此时，TTL变为0了，所以该路由器会将此datagram丢掉，并送回一个[ICMPtimeexceeded]消息(包括发IP包的源地址，IP包的所有内容及路由器的IP地址)，traceroute收到这个消息