5. SQL Server数据库性能监控 - 当前请求
对于在线运行的系统，当前数据库性能监控，通常监视以下几点：
(1) 是否有阻塞 (Blocking);
(2) 是否有等待 (Waiting)，阻塞就是锁 (Lock) 等待;
(3) 是否运行时间过长(Long running)；
(4) 是否有死锁 (Deadlock)；
sys.dm_exec_query_stats之类，等一些统计性的信息，通常不作为实时告警内容，而是在性能优化时，作为参考。
一. 阻塞/等待/长时间运行
1. SQL Server 2005 及以后版本检查
SELECT r.session_id,r.blocking_session_id,DB_Name(r.database_id) as database_name,r.start_time,r.total_elapsed_time,r.[status],CASE WHEN r.blocking_session_id <> 0 THEN 'Blocking'WHEN r.blocking_session_id = 0 AND r.wait_type is not null THEN 'Waiting'ELSE 'Long-running'END as slowness_type,r.percent_complete,r.command,r.wait_type,r.wait_time,r.wait_resource,r.last_wait_type,r.cpu_time,r.reads,r.writes,r.logical_reads,t.[text] as executing_batch,SUBSTRING(t.[text],r.statement_start_offset/2,(CASE WHEN r.statement_end_offset = -1 THEN DATALENGTH (t.[text]) --LEN(CONVERT(NVARCHAR(MAX), t.text)) * 2ELSE r.statement_end_offset END - r.statement_start_offset )/2 + 1) as executing_sql,bt.[text] as blocking_batch,SUBSTRING(bt.[text],br.statement_start_offset/2,(CASE WHEN br.statement_end_offset = -1 THEN DATALENGTH (bt.[text]) --LEN(CONVERT(NVARCHAR(MAX), bt.text)) * 2ELSE br.statement_end_offset END - br.statement_start_offset )/2 + 1) as blocking_sql--,p.query_planFROM sys.dm_exec_requests rCROSS APPLY sys.dm_exec_sql_text(r.sql_handle) as tCROSS APPLY sys.dm_exec_query_plan(r.plan_handle) as pLEFT JOIN sys.dm_exec_requests brON r.blocking_session_id = br.session_idOUTER APPLY sys.dm_exec_sql_text(br.session_id) as btWHERE r.session_id > 50 and r.session_id <> @@SPIDAND r.total_elapsed_time > 30 * 60 * 1000ORDER BY r.total_elapsed_time DESC;
以上脚本返回运行超过30分钟的语句，需要注意的是：
(1) 如果返回执行计划，会让以上脚本变慢很多，可以不返回，在收到告警后检查语句时，再去查看执行计划；
(2) 显示TEXT，比如: xp_cmdshell这样的语句，start_offset, end_offset都为0，截取的 text是空白，只有看TEXT才知道是什么语句；还有就是有时需要知道这个请求来自哪个batch或者存储过程；
(3) 有时显示TEXT还不够，还以xp_cmdshell为例，需要dbcc inputbuffer才能看到完整的sql语句；另外已运行结束但还没有commit/rollback的事务，在requests中已经没有了，也需要借用dbcc inputbuffer来查看sql 语句；
dbcc inputbuffer(@@SPID)
(4) SQL Agent作业，在这里会被一并检查，也可以通过msdb..sysjobactivity另行检查；
select b.name, * from msdb..sysjobactivity ainner join msdb.dbo.sysjobs bon a.job_id = b.job_idwhere b.name like '%backup%'
2. SQL Server 2000沿用过来的方法
select p.dbid, p.spid, p.blocked, p.waittime/1000.0/60.0 as wait_minutes, ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0) elapsed_minutes, p.last_batch, p.status, p.program_name, (select [text] FROM ::fn_get_sql(p.sql_handle)) sql_text from master..sysprocesses pwhere spid > 50 and spid <> @@SPIDAND (status <> 'sleeping' AND ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0) > 30)
以上脚本返回运行超过30分钟的语句，需要注意的是：
sysprocesses中把connection/session/request信息三者合一，其中没有请求开始的具体时间，通过last_batch监视运行时长并不准确。测试如下：
(1) 通过ISQL连接到SQL Server，如果当前连接没发起过任何请求，last_batch的时间为 1900-01-01 00:00:00，在此连接上发起请求时，通过last_batch计算当前请求运行时长不准确；
(2) 在SQL Analyzer/SSMS中新建查询窗口，未发起任何查询时，last_batch与login_time一样，而非1900-01-01 00:00:00，通过last_batch计算当前请求运行时长不准确；或者当前窗口发起的请求已结束，但窗口/连接未关闭，则在此连接上再次发起请求，last_batch为上次请求结束的时间，通过last_batch计算当前请求运行时长也不准确；
(3) SQL Agent作业运行结束后，会把在sysprocesses的连接关闭，下次运行时重新建立连接，新建连接中last_batch等于login_time，通过last_batch计算作业运行时长准确；
作为一个老的方法，估且不再去深究，不过用sysprocesses来监视阻塞/等待还是没有问题的，另外作业的运行时长也是可以监视的，脚本改动后如下：
select p.dbid, p.spid, p.blocked, p.waittime/1000.0/60.0 as wait_minutes, ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0) elapsed_minutes, p.last_batch, p.status, p.program_name, (select [text] FROM ::fn_get_sql(p.sql_handle)) sql_text from master..sysprocesses pwhere spid > 50 and spid <> @@SPIDand ((p.program_name like 'SQLAgent - TSQL JobStep (Job %' AND ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0) > 30)or (p.blocked <> 0 and p.waittime/1000.0/60.0 > 30))
这样一来，只剩下未被阻塞但长时间运行的sql请求未被监视到。如果一定要全面监视的话，可以选择开启跟踪，进而分析跟踪文件。
二. 死锁
死锁的监控可以通过监视SQL Server的ERRORLOG来实现，不过需要事先打开死锁的跟踪标记。脚本如下：
--sql server 2000 dbcc traceon(1204,-1)--sql server 2005 + dbcc traceon(1222,-1)
这样发生死锁时，死锁详细信息就会被写入ERRORLOG，检查deadlock或者victim关键字即可进行监控。
小结
各个语句的运行时长/基线并不一样，通常不好设置统一的阀值，有时会借用第三方工具针对不同的请求设置不同的时长阀值并告警，所以在数据库这层大多告警阻塞即可，大致步骤如下 ：
(1) 部署数据库邮件；
(2) 部署作业：定时检查阻塞，发邮件告警。
转载于:https://www.cnblogs.com/lonelyxmas/p/3984880.html
5. SQL Server数据库性能监控 - 当前请求相关推荐
- (转)SQL Server数据库状态监控 - 作业状态
4. SQL Server数据库状态监控 - 作业状态 有很多地方可以设置定时任务,比如:Windows的计划任务,Linux下的crontab,各种开发工具里的timer组件.SQL Server也 ...
- 从外到内提高SQL Server数据库性能
如何提高SQL Server数据库的性能,该从哪里入手呢?笔者认为,该遵循从外到内的顺序,来改善数据库的运行性能.如下图: 第一层:网络环境 到企业碰到数据库反映速度比较慢时,首先想到的是是否是网络环 ...
- sql server数据库性能的优化
编者按:数据库性能优化和数据库管理系统密切相关,不同的数据库管理系统在具体操作上有很大不同.继本报连续在2003年第48期.49期上刊登<sybase数据库性能调优>和<oracle ...
- 10步骤优化SQL Server 数据库性能
作者从基础的数据库索引开始全面讲述了SQL Server数据库应用程序的性能优化,包括数据库设计和数据访问代码.系列文章如下: Top 10 steps to optimize data access ...
- 4. SQL Server数据库状态监控 - 作业状态
有很多地方可以设置定时任务,比如:Windows的计划任务,Linux下的crontab,各种开发工具里的timer组件.SQL Server也有它的定时任务组件 SQL Server Agent,基 ...
- 3. SQL Server数据库状态监控 - 可用空间
数据库用来存放数据,那么肯定需要存储空间,所以对磁盘空间的监视自然就很有必要了. 一. 磁盘可用空间 1. 操作系统命令或脚本.接口或工具 (1) DOS命令: fsutil volume diskf ...
- 微软SQL Server数据库的两种请求游标
游标(cursor)是系统为用户开设的一个数据缓冲区,存放SQL语句的执行结果.每个游标区都有一个名字.用户可以用SQL语句逐一从游标中获取记录,并赋给主变量,交由主语言进一步处理. 关系数据库中的操 ...
- SQL Server 数据库性能优化
对一个数据库来说,只能做到更优,不可能最优,并且根据实际需要,优化方案也是有所差异的,大概需要我们关心的有它的读取速度.存储空间.可维护性以及可扩展性等,而这些方面往往又是相互矛盾的,那么本文就着重讲 ...
- SQL Server数据库性能优化（三）之 硬件瓶颈分析
参考文献 http://isky000.com/database/mysql-performance-tuning-hardware 由于对DBA 工作了解不多 所以只从网上简单的看了下 硬件 ...
最新文章
- springboot 事务_原创002 | 搭上SpringBoot事务源码分析专车
- win32程序启用控制台-- 调试输出
- 线上服务CPU100%问题快速定位实战(转载公众号：架构师之路)
- windows10 环境下的amqp安装步骤（图文）
- Linux上Libevent的安装
- esc指令检查打印状态_Z.115 胶片自助打印设备
- 《深入react技术栈》学习笔记（一）初入React世界
- 【软考】面向对象程序设计复习指南
- MySQL 清除表空间碎片
- vue2.5版本源代码编译报 Could not load ..\vue\src\core/config 错误的问题 npm run dev 编译报错...
- 这7个OKPlus的新功能，知道后做PPT的效率直接起飞！
- citrixreceiver云桌面系统_基于Citrix的云桌面方案
- 爬虫--05：多线程与生产者消费者模型
- 卡尔曼滤波（Kalman filter)算法以及Arduino应用-mpu6050（导航贴）
- 从SEO优化角度打造移动端网站的移动建站指南
- 【shell】网络处理：判断IP是否在网段、两个ip是否同网段、IP地址范围、网段包含关系
- 4四层电梯三菱fx2n系列plc独立程序带注释新3plc接线图io表
- 牛客网Python笔试技巧
- 小程序的版本(正式版、体验版、开发版)
- [LeetCode]67.Add Binary