标签: activity-monitor

当我检查我们的 SQL Prod 服务器时，每次打开活动监视器时，我总是SQLCLR在活动监视器的资源等待部分的第一个列表中看到。它总是有一个很高的数字。是SQLCLR为了什么？SQLCLR在活动监视器中具有高资源等待数的服务器是否有害？

是否有任何脚本可以像活动监视器一样获取输出？

或者当活动监视器显示在屏幕上时，我可以使用哪些 DMV 来获取输出？

它应该能够显示存储过程名称以及当前正在运行的存储过程中的语句以及与块相关的信息。

我有一个 SQL Server 2008 R2 服务器。我打开“活动监视器”，在“资源等待”类别中，我看到“记录”类别占用的时间超过 1400 毫秒/秒。

这似乎不正常，这是什么意思，我该如何诊断原因？

更新：

我运行了这个查询，由 Shark 建议：

select * from sys.dm_os_wait_stats order by wait_time_ms desc

并得到了这些结果：

wait_type                         waiting_tasks_count  wait_time_ms         max_wait_time_ms     signal_wait_time_ms
--------------------------------- ------------------- -------------------- --------------------- ---------------- 
LCK_M_IX                          3662                 102060386            31410                233
LAZYWRITER_SLEEP                  741527               63315760             305163               28805
WRITELOG                          3531635              42147142             4142                 309360
REQUEST_FOR_DEADLOCK_SEARCH       6327                 31676553             5038                 31676553

我使用 .NET 在 SQL Server 2014 上执行 SQL 操作，这里是使用的代码：

using(SqlConnection conn = new SqlConnection(connectionString)){
    //https://stackoverflow.com/questions/1880471/capture-stored-procedure-print-output-in-net
    conn.InfoMessage += new SqlInfoMessageEventHandler(logSqlMessages);
    conn.Open();
    using(SqlCommand stmt = new SqlCommand{
        Connection = conn,
        CommandText = sql,
        CommandTimeout = 30000 // The time in seconds to wait for the command to execute. The default is 30 seconds.
        //,CommandType = CommandType.StoredProcedure
    })
    {
        affectedRecords = stmt.ExecuteNonQuery();
    } // using stmt
} // using conn

当我查看 Active Monitor 时，有数十行引用相同的操作。它们都具有相同的session_id，其中一些具有正在运行的任务状态，并且大多数处于暂停状态。其中一些具有 LastWaitTime CXPACKET，大多数具有PAGEIOLATCH_SH.

我还在 SQL …

我想查看 SQL 服务器上的活动。所以我可以在服务器负载低时运行查询。我知道 SQL Server 中有一个活动监视器，但我的公司不希望我授予使用此工具的权利。显然，您可以杀死其他人的查询，这太危险了。

有没有办法用代码检查服务器的状态？（或者在不需要这些权限的情况下查看活动以便我可以手动运行它们？）

我正在跟踪 SQL Server 活动监视器中报告的处理器百分比与资源监视器中使用的总处理器百分比之间的显着差异。我看到两者之间大约有 50% 的差异，而活动监视器总是更高。

系统规格：

• SQL Server EE 2008 R2
• 视窗 2008 R2
• 裸机
• 96 个核心，无处理器关联集（4 个物理插槽，每个 12 个核心，启用超线程）
• 768 GB 内存
• 主动/被动集群
• SSD 的直连存储

什么会导致这种差异？

我应该看哪一个？

更新：

我看到资源监视器将其分为不同的类别，但是“CPU - 总计”图表不会显示机器上的所有 CPU 使用情况吗？

任务管理器性能选项卡显示它与活动监视器之间的相同差异。

• 活动监视器刷新 1 秒。

活动监视器没有看到每个核心都是超线程的，这会不会有问题？不确定 SQL Server 如何看待所有 96 个内核。

2018 年 6 月 28 日更新

即使在迁移到 AWS 并将操作系统更新到 Server 2012 R2 之后，SQL Server 2008 r2 活动监视器仍然与任务管理器显示的内容相差甚远。下面的屏幕截图来自刚刚执行的负载测试。两个指标之间存在明显的 20% 差异。即使任务管理器报告总体 CPU 刚刚超过 55%，SQL 活动监视器也被锁定在 100%。来自 AWS Cloud watch 的指标显示的结果与 Task Manager 相同，因此我有两个数据指标与第三个甚至不在球场上相关。

更新的系统规格： 系统规格：

• SQL Server …

我有以下查询来跟踪当前日期修改了哪些表：

SELECT TABLE_OWNER, 
       TABLE_NAME, 
       INSERTS,
       UPDATES,
       DELETES,
       TIMESTAMP AS `LAST_CHANGE`
FROM  ALL_TAB_MODIFICATIONS
WHERE TO_CHAR(TIMESTAMP,'DD/MM/YYYY') = TO_CHAR(sysdate,'DD/MM/YYYY') 
ORDER BY LAST_CHANGE DESC;`

结果

如您所见，查询工作正常，但我想添加更多复杂性，例如添加一个字段“LAST_CHANGE_TYPE”，显示最新进程中的最后一个事务类型（添加、删除或修改）。

另一个对监视我的 DW 有用的查询也很好。

就像监控所有可能的操作一样，跟踪用户所做的事情，例如：

• 删除约束，如果它可能指定什么样的约束
• 修改包正文

列出操作后，有必要查看每个操作的用户和日期。

| 对象 |类型 | 来源 | 操作类型 | 用户 | 日期 |

| 约束 | PK | 表A | 下降 | 斯科特 | 11/11/2011|

| 表 | 表 | 表 B | 改变 | 人力资源 | 05/05/2002|

目前对所有建议开放

要查看“最近的昂贵查询”，我使用活动监视器。那里的一些查询带有参数。

有没有办法知道这些值？

尝试创建一个大型测试数据库时，我创建了一个 SP，它使用预定义的表列表（我感兴趣的 35 个）并将每个表中的数据相乘。

换句话说，一张表有一个商店的数据。我将相同的数据插入到该表中，但具有不同的商店编号（这给了我 2 个商店）。然后我调用将 2 个商店数据乘以 4 个商店的同一个 SP，依此类推。上周末，我开始对 SP 进行 6 次后续调用，认为当我周一回来时，我的数据库将拥有 64 家商店的数据。不幸的是，事实并非如此......

当我周一来时，我发现数据高清已满，但该过程从未崩溃并且似乎已暂停。我的数据库处于简单恢复模式，我通过移动文件和缩小 TempDB（通过 SSMS 中的缩小文件选项）来腾出空间，并在外部驱动器上创建了一个初始大小为 100GB 的额外 ndf 文件......进程仍在运行（腾出空间后超过 24 小时）。

spid 的任务状态显示暂停，等待类型为 PAGEIOLATCH_EX，但等待时间很短（低于 100 毫秒），这让我相信进程仍在运行。

35 个表中有 34 个大小合适，乘法速度足够快... 该过程已将所有表中的 1 个数据存储乘以 8 个存储，并且仍在完成数据从 8 个存储到 16 个存储的乘法过程......它似乎正在处理的一张桌子是所有桌子中最大的......

将这个表的 8 个存储区的数据乘以 16 个存储区的实际过程是从 4 亿条记录中插入 4 亿条记录，该表有 200 列所有不同类型。

我是在浪费时间等待吗？恐怕杀死进程需要几天时间才能回滚......我应该等待吗？它变成了一个 Phantom 过程吗？我怎么知道它在做什么？

任何意见/想法将不胜感激。

谢谢