使用系统存储过程来监控SQLServer进程和会话具体解释



承接上文,本文讲述怎样使用系统存储过程来监控系统。

SQLServer相同也提供了一系列系统存储过程用于监控SQLServer,获取当前进程、会话、请求以及锁定的具体信息。本文将演示系统存储过程来实现这些监控。

情景:

有时候你会发现应用程序突然变得非常慢,常常须要等待数据库响应,此时你须要高速查看是否请求被堵塞或者挂起。

准备工作:

在本文中,将使用下面存储过程来获取当前进程的信息:

  • Sp_who
  • Sp_who2

步骤:

1、  打开SSMS连到SQLServer实例并打开新查询窗体。

2、  在新查询窗体中输入下面脚本

分析:

本例中,创建了两个暂时表,用于存放sp_who 和sp_who2存储过程返回的数据结果,然后通过INSERT…EXECUTE命令把结果插入到暂时表中,样例中演示了对sp_who的使用。至于sp_who2的使用是一样的。

之所以使用暂时表来存放数据,是由于sp_who/sp_who2这两个系统存储过程不能直接筛选结果。所以须要存到表里面做二次处理。

扩充信息:

如今来简介一下,在DMO被增加到SQLServer之前,sp_moitor、sp_who2、sp_who这三个系统存储过程被广泛用于监控系统当前信息。

Sp_monitor在上文中已经提到过。而且能够和系统统计函数互换使用。

Sp_who是用于获取当前SQLServer进程、会话和请求的具体信息的系统存储过程。

通过这个存储过程,能够知道谁运行了什么操作或者命令,和哪些进程被哪些进程堵塞了。

这个存储过程有一些可选的參数:@loginame(类型为sysname),session ID(类型为smallint),和ACTIVE。

能够通过传入@loginame来筛选特定的登录名的信息,假设Session ID也被定义,也会筛选特定sessionid的信息。

假设没有參数,将范围实例级别的信息。

假设你没有VIEW SYSTEM STATE权限,你只能够查看自己这个会话的信息。假设使用了ACTIVE參数。

存储过程将返回活动的进程。

对于sp_who返回的结果:

Spid:返回sessionID也就是会话ID。这些ID中。1到50(含)为系统会话。

51及以上sessionid才是用户会话ID。

Exid:有时候结果中可能会有多个同样的SPID,这往往是由于发生了并行查询。这一列代表了查询的上下文ID。而0代表了父线程,其它值代表子线程。

Status:返回进程的的状态,包含:Dormant(休眠)、Running(正在执行)、Background(正在后台执行的进程如死锁侦測)、Rollback(事务正在回滚)、Pending(挂起,该会话正在等待可用的工作线程)、Runnable(会话的任务在等待获取时间量程时位于计划程序的可执行队列中)、Spinloop(会话的任务正在等待调节锁变为可用)、Suspended(会话正在等待时间如I/O完毕)。

Loginame:会话所相应的登录名

Hostname:会话相应的机器名

Blk:假设会话被堵塞。这里将显示堵塞的会话ID,假设没有,降为0。

Dbname:返回特定会话所请求的数据库名。

Cmd:返回数据库引擎的命令类型。

Request_id:会话中的请求ID。

相对于sp_who,sp_who2返回很多其它的信息。可是sp_who2是未公开的系统存储过程,意味着你在联机丛书中找不到相关信息。

原文地址:https://www.cnblogs.com/clnchanpin/p/6900274.html