SQLServer 通过DMV实现低影响的自动监控与历史场景追溯.docVIP

HYPERLINK /fygh/archive/2011/09/20/2182512.html SQLServer 通过DMV实现低影响的自动监控和历史场景追溯一. 背景：我们管理和维护的数据库系统基本都是7*24小时运转的，运转时会出现什么情况谁都无法估计，往往一个平时运行很正常的系统，某天晚上突然就抽风了，而此刻并没有系统负责人在旁边，当值班同事的电话打到正在酣睡的DBA手机上时，DBA不得不朦朦胧胧的，条件反射要上数据库看看；要在家里连到公司的内外一般都需要DBA通知运维人员（也可能是个在做梦的哥们）先给自己开个VPN（某些管控严格的公司还需要DBA打车去公司才能处理），然后通过一大堆的验证才通过慢如蜗牛（往往也和此刻的心态有关）的网络，远程连接到了公司内网出问题的数据库上，此刻DBA才开始真正开始排查起问题来；如果说等待DBA登录到问题数据库上，问题依然在出现，那还算好，可以很快找到问题并处理，但是往往这种抽风的现象是短暂的，可能持续几分钟后，系统又恢复了正常，等到DBA跑山涉水，翻山越岭 的好不容易登录到数据库上检查时，数据库里的进程、锁、日志一起都正常，系统运行的很Hai；于是第二天上班时老大们问起昨天晚上事故的原因时，DBA只能凭空猜测，可能是网络、数据库阻塞、抑或是程序方面的问题吧......，此刻不同部门的人都猜是其他部门管理的东西出了问题，于是大家都把手头上的数据、监控图拿出来，证明自己这里是没有问题的；如果监控网络和系统的图和APP的Log都没用出现啥问题（说实话监控也不一定准确的），那就基本要把问题推到数据库身上了（DBA往往成为炮灰）。数据库有没有出问题，如果出了问题又是啥问题呢？windows Log和DB Log都没异常，如果我们没有把Profile持续的开启（基于性能的考虑，一般都不会持续开启），就很难说清楚在系统出问题时数据库究竟有没有出问题，出了问题又是因为什么原因引起的；如果说此类问题出现了一次，就消失了，那还算好，成为一个无头案，悲剧的是这类问题无规律，反复的出现，如果DBA不能找出问题的原因，也不能证明数据库当时是正常的话，估计在公司里面就没用立足之地了。二 . 对策：其实对这种灵异的系统抽风事件，有两种比较好的解决方案：1. 开启Trace 跟踪，就是数据库的Profile功能 ，这个还可以结合windows的性能计数器一同使用，能够直观的了解到特殊时间点上运行了什么语句，资源消耗情况是怎样的；不过这个方法比较消耗系统的资源，对访问压力比较大的数据库需要慎重；2. 收集数据库DMV当时的情况，使得DBA在故障时间过后，还能通过这些数据了解到事故发生时，数据库里面运行的语句，以及锁和资源的情况；这种方法只是访问系统性能视图，对数据库其他业务影响比较小，也是我接下来要介绍的方案。三. 实施方案：思路：根据数据库中某些动态指标，触发收集DMV的过程，必要时发送报警邮件1. 创建存储系统性能视图的表：--创建四个记录表USE[master]GO/****** Object: Table [dbo].[dc_block_info] Script Date: 05/23/2011 11:35:48 ******/SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOSET ANSI_PADDING ONGOCREATETABLE[dbo].[dc_block_info]( [spid][smallint]NULL, [status][nchar](30) NULL, [SQLBuffer][nvarchar](max) NULL, [hostname][nchar](128) NULL, [BlkBy][varchar](10) NULL, [BlockedSQLBuffer][nvarchar](max) NULL, [LoginName][varchar](100) NULL, [DBName][varchar](50) NULL, [CPUTime][int]NULL, [DiskIO][int]NULL, [LastBatch][datetime]NULL, [program_name][nchar](128) NULL, [Command][varchar](100) NULL, [batch_id][int]NULL) ON[PRIMARY]GOSET ANSI_PADDING OFFGOUSE[master]GO/****** Object: Table [dbo].[dc_