数据库系统异常排查之DMV(转)

来源: http://www.cnblogs.com/fygh/archive/2012/03/12.html

数据库系统异常是DBA经常要面临的情景,一名有一定从业经验的DBA,都会有自己一套故障排查的方法和步骤,此文为为大家介绍一下通过系统

性能视图(SQLServer05以上版本)来排查系统异常的基本方法,希望能对大家有所帮助。

这里分两部分来介绍:

一.  从数据库连接情况来判断异常:

1. 首先我们来看一下目前数据库系统所有请求情况:

--request infoselect s.session_id, s.status,db_name(r.database_id) as database_name,s.login_name,s.login_time, s.host_name,c.client_net_address,c.client_tcp_port,s.program_name, r.cpu_time, r.reads, r.writes,c.num_reads,c.num_writes,s.client_interface_name, s.last_request_start_time, s.last_request_end_time,c.connect_time, c.net_transport, c.net_packet_size,r.start_time, r.status, r.command,r.blocking_session_id, r.wait_type,r.wait_time, r.last_wait_type, r.wait_resource, r.open_transaction_count,r.percent_complete,r.granted_query_memoryfrom Sys.dm_exec_requests r with(nolock)right outer join Sys.dm_exec_sessions s  with(nolock)on r.session_id = s.session_idright outer join Sys.dm_exec_connections c  with(nolock)on s.session_id = c.session_idwhere s.session_id >50order by s.session_id

某台生产机运行情况:

这个查询将目前数据库中的所有请求都显示出来了,其中比较重要的有Status、Login_name、Host_Name,Client_Net_Address、Program_name

等,但是信息比较多,我们很难查看有什么异常,但是可以通过一图中红色圈的数字:441 初步判断连接数是否超过了平时的标准(很多时候系统异常是连接

数过多造成的,而连接数过多又是因为其他原因影响的)。

2. 哪个用户连接数最多:

--request info by userselect login_name,COUNT(0) user_countfrom Sys.dm_exec_requests r with(nolock)right outer join Sys.dm_exec_sessions s  with(nolock)on r.session_id = s.session_idright outer join Sys.dm_exec_connections c  with(nolock)on s.session_id = c.session_idwhere s.session_id >50group by login_name order by 2 desc

运行结果:

从图中我们可以很方便的看出用户连接数情况,如果我们的不同的功能是使用不同的的数据库账号的话,就能初步判断是哪部分功能可能出现了异常。

3. 哪台机器发起到数据库的连接数最多:

--request info by hostnameselect s.host_name,c.client_net_address,COUNT(0) host_countfrom Sys.dm_exec_requests r with(nolock)right outer join Sys.dm_exec_sessions s  with(nolock)on r.session_id = s.session_idright outer join Sys.dm_exec_connections c  with(nolock)on s.session_id = c.session_idwhere s.session_id >50group by host_name,client_net_address order by 3 desc

运行结果:

这个查询能够一下就帮我们找出来哪些机器发起了对数据库的链接,它们的链接数量是否有异常;这个其实对调查某些问题非常有用,我有一次就遇

到一个case:

用户反映,过一两个星期,系统就会出现一次异常,出问题时数据库连接数量很高,大量的访问被数据库拒绝,过半个小时左右,系统又自动恢复了,但是

在数据库里面查看,并没有发现有异常的进程和错误的信息,问题一时很棘手,很难定位,系统不稳定领导不满,DBA顶着压力一时不知道如何是好;后面

转换方向,通过调查问题发生时,为什么会产生这么多连接,这些连接是那些机器发过来的,这些连接发过来正常吗,是数据库不砍业务的重负,还是业务

在某个时间段内会出现暴涨等一系列原因,最终找出是一台Web因为开发人员代码写的有问题,内存出现内存泄露,导致大量的连接不能释放,出问题是,

发出的数据库连接数比平时高3-4倍,最终影响到了数据库,问题压根和数据库没关系(从这个事实看出,DBA真是的炮灰角色,不是自己的问题,也得顶

着压力调查出原因呀);如果在类似问题发生时,我们能通过这个查询及早知道问题是出在某台Web机器上,那就不用费尽心力来调查数据库了。

4. 这些连接在访问哪个库:

--request info by databasesselect db_name(r.database_id) as database_name,COUNT(0) host_countfrom Sys.dm_exec_requests r with(nolock)right outer join Sys.dm_exec_sessions s  with(nolock)on r.session_id = s.session_idright outer join Sys.dm_exec_connections c  with(nolock)on s.session_id = c.session_idwhere s.session_id >50group by r.database_idorder by 2 desc

结果(为NULL的估计是没办法定位库):

5. 进程状态:

--request info by statusselect s.status,COUNT(0) host_countfrom Sys.dm_exec_requests r with(nolock)right outer join Sys.dm_exec_sessions s  with(nolock)on r.session_id = s.session_idright outer join Sys.dm_exec_connections c  with(nolock)on s.session_id = c.session_idwhere s.session_id >50group by s.statusorder by 2 desc

结果(running数比较多,表面数据库压力比较大):

二. 从阻塞情况来判断异常(这部分内容不再一一贴图,直接上脚本):

1. 查看数据库阻塞情况:

----------------------------------------Blocked Info------------------------------------记录当前阻塞信息 select t1.resource_type as [lock type] ,db_name(resource_database_id) as [database]    ,t1.resource_associated_entity_id as [blk object]    ,t1.request_mode as [lock req]                          -- lock requested    ,t1.request_session_id as [waiter sid]                      -- spid of waiter    ,t2.wait_duration_ms as [wait time]          ,(select text from sys.dm_exec_requests as r with(nolock)                 --- get sql for waiter    cross apply sys.dm_exec_sql_text(r.sql_handle)     where r.session_id = t1.request_session_id) as waiter_batch    ,(select substring(qt.text,r.statement_start_offset/2,     (case when r.statement_end_offset = -1 then len(convert(nvarchar(max), qt.text)) * 2     else r.statement_end_offset end - r.statement_start_offset)/2+1)     from sys.dm_exec_requests as r with(nolock)     cross apply sys.dm_exec_sql_text(r.sql_handle) as qt    where r.session_id = t1.request_session_id) as waiter_stmt    --- statement executing now    ,t2.blocking_session_id as [blocker sid]                --- spid of blocker    ,(select text from sys.sysprocesses as p with(nolock)    --- get sql for blocker    cross apply sys.dm_exec_sql_text(p.sql_handle)     where p.spid = t2.blocking_session_id) as blocker_stmt,getdate() time   from sys.dm_tran_locks as t1 with(nolock) , sys.dm_os_waiting_tasks as t2 with(nolock)      where t1.lock_owner_address = t2.resource_address

2. 查看阻塞其他进程的进程(阻塞源头):

--阻塞其他session的session select  t2.blocking_session_id,COUNT(0) countsfrom sys.dm_tran_locks as t1 with(nolock) , sys.dm_os_waiting_tasks as t2 with(nolock)    where t1.lock_owner_address = t2.resource_addressgroup by blocking_session_idorder by 2

3. 被阻塞时间最长的进程:

--被阻塞时间最长的sessionselect top 10  t1.resource_type as [lock type] ,db_name(resource_database_id) as [database]    ,t1.resource_associated_entity_id as [blk object]    ,t1.request_mode as [lock req]                          -- lock requested    ,t1.request_session_id as [waiter sid]                      -- spid of waiter    ,t2.wait_duration_ms as [wait time]          ,(select text from sys.dm_exec_requests as r with(nolock)                 --- get sql for waiter    cross apply sys.dm_exec_sql_text(r.sql_handle)     where r.session_id = t1.request_session_id) as waiter_batch    ,(select substring(qt.text,r.statement_start_offset/2,     (case when r.statement_end_offset = -1 then len(convert(nvarchar(max), qt.text)) * 2     else r.statement_end_offset end - r.statement_start_offset)/2+1)     from sys.dm_exec_requests as r with(nolock)     cross apply sys.dm_exec_sql_text(r.sql_handle) as qt    where r.session_id = t1.request_session_id) as waiter_stmt    --- statement executing now    ,t2.blocking_session_id as [blocker sid]                --- spid of blocker    ,(select text from sys.sysprocesses as p with(nolock)    --- get sql for blocker    cross apply sys.dm_exec_sql_text(p.sql_handle)     where p.spid = t2.blocking_session_id) as blocker_stmt,getdate() time   from sys.dm_tran_locks as t1 with(nolock) , sys.dm_os_waiting_tasks as t2 with(nolock)      where t1.lock_owner_address = t2.resource_addressorder by t2.wait_duration_ms desc

此文大致总结了通过DMV调查数据库异常的基本方法和步骤,如果大家在调查问题时能够灵活运用,相信对数据库异常情况的定位和解决能够更快更有效。

时间: 2024-10-27 13:12:44

数据库系统异常排查之DMV(转)的相关文章

使用DMV排查数据库系统异常

数据库系统异常是DBA经常要面临的情景,一名有一定从业经验的DBA,都会有自己一套故障排查的方法和步骤,此文为为大家介绍一下通过系统 性能视图(SQLServer05以上版本)来排查系统异常的基本方法,希望能对大家有所帮助. 这里分两部分来介绍: 一.  从数据库连接情况来判断异常: 1. 首先我们来看一下目前数据库系统所有请求情况: --request info select s.session_id, s.status,db_name(r.database_id) as database_n

异常排查_Python-日志模块.NoSectionError: No section: '*' 错误?

问题复现: Traceback (most recent call last):   File "/usr/lib/python2.6/site-packages/logging-0.4.9.6-py2.6.egg/logging/config.py", line 171, in fileConfig     qn = cp.get(sectname, "qualname")   File "/usr/lib64/python2.6/ConfigParse

redis 异常排查

异常排查 redis-server redis.windows.conf D:\redis-2.8.17>redis-server.exe redis.windows.conf[4692] 27 Nov 12:14:05.995 #The Windows version of Redis allocates a memory mapped heap for sharing withthe forked process used for persistence operations. In ord

某企业虚拟化平台时间同步异常排查

背景介绍 某企业使用VMware 5.5U3搭建虚拟化平台,其上运行着近200台虚拟机,无论是Windows还是Linux系统都运行在工作组模式下,由于需要给上级部门上传数据,客户反映部分虚拟机上传时间不对,检查发现是因为虚拟机本身时间不对导致. 解决思路 该企业内部有专门的NTP服务器,搭建平台初期已设置承载虚拟机的虚拟化物理主机向NTP服务器同步时间,且所有虚拟机都已安装Vmware Tools,根据VMware白皮书介绍,安装了VMware Tools的操作系统会定期通过VMware To

服务器流量异常排查步骤(查看进程的流量)

在工作中经常遇到服务器流量异常,时不时的流量很高,今天就是一台服务器的内网端口的流量很短时间内达到了50Mbps,下面是我排查问题的方法和步骤,记录一下. 1.使用iftop -P 确定哪个进程的流量比较大 或者使用iptraf,jnettop  请读者自行研究 可以看出来api-node3:58218 的进程流量最大.下一步要根据端口号确定对应的进程PID 2.确定该端口号对应的应用进程PID # lsof -i:58218   或者   netstat -atunp |grep 58218

Linux下Mysql启动异常排查方案

遇到Mysql启动异常问题,可以从以下几个方面依次进行问题排查: (1)如果遇到“Can't connect to local MySQL server through socket '/tmp/mysql.sock'”类似问题,查看Mysql配置文件(默认在/etc/my.cnf目录下),使用命令vi /etc/my.cnf,查看是否具备如下配置, [mysqld]port            = 3306socket       = /var/lib/mysql/mysql.sock 可能

HttpClient连接池抛出大量ConnectionPoolTimeoutException: Timeout waiting for connection异常排查

今天解决了一个HttpClient的异常,汗啊,一个HttpClient使用稍有不慎都会是毁灭级别的啊. 这里有之前因为route配置不当导致服务器异常的一个处理:http://blog.csdn.net/shootyou/article/details/6415248 里面的HttpConnectionManager实现就是我在这里使用的实现. 问题表现: tomcat后台日志发现大量异常 [plain] view plain copy print? org.apache.http.conn.

异常排查_Python.[alembic.env] No changes in schema detected?

问题复现: INFO  [alembic.runtime.migration] Context impl SQLiteImpl. INFO  [alembic.runtime.migration] Will assume non-transactional DDL. INFO  [alembic.env] No changes in schema detected. 配置文件: #!/usr/bin/env python # -*- coding: utf-8 -*- """

连接不到JDBC异常排查

连接不到数据库的报错一般有以下几种原因: 1.数据源配置文件有问题,检查数据源配置文件中的IP,账号和密码. 2.检查数据库是否正常运行.使用plsql输入账号和密码进行验证. 3.查看在deploy目录下是否存在两个数据源配置文件,对照别的环境查看是否需要连接两个数据库.也可和开发核对是否需要那样连接. 4.如果第一遍启动报数据源连接不到异常,重启不报错,这种是因为数据库连接数较小,增加数据库的连接数,增大数据库服务器的文件打开数和用户最大进程数.这里应该是调整oracle用户的相关参数. 要