干货丨一文学会排查数据库系统故障

数据库系统故障将严重影响业务的正常运行。常见的数据库系统异常现象主要包括：主机CPU利用率异常、主机IO异常、数据库连接异常、数据库响应慢、数据库归档日志产生量异常。面对数据库系统异常问题，每一名合格的DBA，都应该有一套成熟的排查方法和工具。本文针对数据库运行突发变慢这一问题，向大家介绍故障的排查思路。

01
确认系统资源状况

对于任何故障，必须先确认硬件系统的资源使用情况。sar , nmon , top 等都是很好用的工具。为什么要先检查硬件系统资源？因为，大部分的数据库问题都会影响硬件资源的利用率。比如：数据库IO变大，操作系统层面的IOWait就会变高，IOSize也会变大；数据库Active状态的会话变多，对于操作系统最直观的影响就是CPU利用率变高；资源IO突然变小，可能意味数据库层面有堵塞；系统CPU利用率突然变低，可能意味着前端堵塞，请求无法到达数据库。

作为一名DBA，在排查故障时，必须检查系统资源利用率，然后再根据资源利用率的情况，有针对性的进行下一步排查。

02
排查硬件问题

在确定硬件资源利用率异常情况下，比如IOWait 变高，可以先检查下硬件的状况。实际上，任何的问题，都建议先检查下操作系统的日志。

PC 服务器上可能出现的会影响系统运行，但又不至于导致宕机的硬件问题主要是存储及网络故障，二者都有可能引发数据库IO变慢、数据库活动连接数变多、数据库响应慢等现象。如果发现大量的CPU在等待IO，或者出现网络超时的情况，建议先检查硬件问题。

存储故障排查过程如下

1.检查操作系统日志，确认是否有相关的error信息。

grep -i error /var/log/messages | grep -i ‘disk’

2.如果系统是内置盘，并且有配置Raid，可以调用raid卡厂家提供的命令，检查磁盘状态，如MegaCli64命令。
3.如果使用了多路径软件，可以检查多路径的状态。多活的多路径会轮巡使用每条路径，单条路径的损坏，会因木桶短板效应，导致整个IO变慢（路径非offline状态）。

4.操作系统日志没有报错，并不一定表示硬件没问题，比如磁盘处于故障的临界状态，就会导致IO缓慢，但是操作系统日志可能并不会报错。如果主机的IO确实变慢，可以通过dd命令，验证磁盘的IO能力。

dd if=/dev/zero of=/dev/xxx oflag=direct

–测试写IO。默认写OS cache，direct 表示跳过OS cache .

dd if=/dev/xxx of=/dev/null

–测试读IO

注意：使用dd命令务必要小心，不当使用，可能导致数据丢失。

网络故障排查过程如下

1.检查操作系统日志，确认是否有相关的error信息。

grep -i error /var/log/messages | egrep -i ‘up|down’

2.主机网卡的故障通常会伴随up down信息，但网络堵塞或网关故障不并会显示在操作系统日志里，因此，还需要 ping 网关，确认网络是否超时。

ping -s 4096 192.168.237.1

硬件确认没问题后，再从数据库层面去查找问题的根源。

03
排查数据库问题

3.1从数据库连接情况来判断异常

数据库的连接数会占用主机的内存资源，活动连接更会占用CPU、IO资源。数据库连接数变多可能是应用问题，比如：应用连接配置修改、业务量突增等，也可能是数据库自身响应变慢导致。从数据库连接着手来定位问题是个常见的排查问题的方法。

3.1.1检查数据库连接

统计各IP、应用、数据库用户的连接数，与往常的值比较，找出存在的异常。比如，结果显示特定IP连接数量异常增多，可以检查该IP所在服务器的应用连接配置、应用启停是否异常。以下SQL统计各IP、应用、用户的连接数。

select

client_addr,

application_name,

usename,

count(*)

from

sys_stat_activity

where

client_addr is not null

and application_name is not null

and usename is not null

group by

grouping sets(

   (client_addr),

   (application_name),

   (usename),

   ()

)

3.1.2. 检查会话状态

会话连接的状态主要有以下几种：

active：后端正在执行一个查询。

idle：后端正在等待一个新的客户端命令。

idle in transaction：后端在一个事务中，但是当前没有正在执行一个查询。

idle in transaction (aborted)：这个状态与idle in transaction相似，不过在该事务中的一个语句导致了一个错误。

fastpath function call：后端正在执行一个 fast-path 函数。

disabled：如果在这个后端中track_activities被禁用，则报告这个状态。

这里必须关注active状态的会话。我们可以统计active状态的会话数量，通过比较历史数据，判断数据库系统的状态。active 状态的会话数量增多，可能是因为业务的繁忙，也可能是由于数据库系统发生了会话阻塞，如果是会话阻塞情况需要结合后面的等待事件进行分析。以下SQL按用户统计不同状态的会话数量。

select

usename,

state,

count(*)

from

sys_stat_activity

group by

rollup(

   usename

   stat