标签: dmv

提交更改索引重组/重建时如何检查进度/状态？

运行包含实际执行计划的查询时，根运算符 ( SELECT) 告诉我缓存计划大小为 32KB。

该连接的查询sys.dm_exec_cached_plans和sys.dm_os_memory_objects，看问题的计划，称该值pages_in_bytes和max_pages_in_bytes为32768（32KB），它匹配缓存计划的大小。

我不明白的是 中的值sys.dm_exec_cached_plans.size_in_bytes，即 49152 (48KB) 代表什么。我已经阅读了所有这些专栏的 BOL，特别是size_in_bytes其中说：

"缓存对象消耗的字节数。 "

我无法解决最后一点难题，无法理解它的真正含义。

我知道所有操作符（不是谈论用于排序和散列的额外内存授予）都需要一定数量的固定内存，以存储状态、进行计算等，这些内存与缓存中的优化计划一起存储，但在哪里？

所以，我的问题是：

• 什么size_in_bytes意思
• 为什么它的值高于“缓存计划大小”？
• 所有运算符/迭代器的固定内存量在哪里保留，是“缓存计划大小”（在我的示例中为 32Kb），还是其他任何地方？

我知道它们是具有不同功能的不同 DMV，但它们是相关的。在编译（缓存）计划sys.dm_exec_cached_plans加入sys.dm_os_memory_objects在memory_object_address列。我在这里发布问题的原因是我在寻求帮助，了解如何解释 DMV 及其专栏。

如果size_in_bytes是缓存计划大小，为什么SQL Server在实际执行计划中说另一个值？

新查询，新号码：

• 实际计划
  • 缓存计划大小 16KB
  • 编译内存 96KB
• DMV：
  • sys.dm_exec_cached_plans.size_in_bytes 24KB
  • sys.dm_os_memory_objects.pages_in_bytes, .max_pages_in_bytes 16KB。

另请注意，此查询不需要为排序和散列操作分配任何额外的内存。

Microsoft SQL Server 2012 - 11.0.5343.0 (X64)

除非我误解了列的用途，否则以下代码表明聚集索引结构的更改不会更改sys.stats_columns DMV 中stats_column_id列的序数位置 ( ) 。（在 AdventureWorks2014、AdventureWorks2008R2 中测试）

select i.name, c.name, ic.column_id, ic.index_column_id
from sys.indexes i 
join sys.index_columns ic
    on i.object_id = ic.object_id
    and i.index_id = ic.index_id
join sys.columns c 
    on i.object_id = c.object_id
    and ic.column_id = c.column_id
where i.name = 'PK_BusinessEntityAddress_BusinessEntityID_AddressID_AddressTypeID'
order by ic.key_ordinal;

select sh.name,s.name, c.name, c.column_id, sc.column_id, sc.stats_column_id
from sys.stats s 
join sys.stats_columns sc
    on s.object_id = sc.object_id
    and s.stats_id = sc.stats_id
join sys.columns c 
    on s.object_id = c.object_id
    and sc.column_id = c.column_id
join …

在维护工作期间，我试图获取碎片索引的列表。但查询速度极慢，执行时间超过 30 分钟。我认为这是由于对 sys.dm_db_index_physical_stats 的远程扫描。

有什么办法可以加快以下查询的速度：

SELECT
    OBJECT_NAME(i.OBJECT_ID) AS TableName,
    i.name AS TableIndexName
FROM
    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat 
    INNER JOIN sys.indexes i 
        ON i.OBJECT_ID = phystat.OBJECT_ID AND i.index_id = phystat.index_id 
WHERE 
    phystat.avg_fragmentation_in_percent > 20 
    AND OBJECT_NAME(i.OBJECT_ID) IS NOT NULL
ORDER BY phystat.avg_fragmentation_in_percent DESC

我不是 DBA，可能在上面的查询中犯了一个明显的错误，或者可能有一些索引或统计信息会有所帮助？也许这只是数据库的大小（大约 20Gb，大约有 140 个表）。

我问的原因是我们只有一个非常小的夜间维护窗口，而这占用了大部分时间。

众所周知，DMV 不保存有关页数和行数的准确信息。但是，当您更新统计数据时，我不明白为什么他们不会。

我正在开发一个监控工具，想知道每个索引和数据的磁盘大小等。最终我想找到合适的填充因子，以及其他一些东西。

The space used by my function and the old sp_spaceused differs a little bit on the space usage, but not on record count.

Can you see if there is anything missing in my select?

this is the sp_spaceused (then I convert the numbers in MB):

sp_spaceused 'tblBOrderRelationship'
go

select 318008/1024.00 AS reserved,
140208/1024.00  AS data,
177048/1024.00 AS index_size,
752/1024.00    AS unused

But when I run my select, code below\picture below, I get slightly different figures.

SET TRANSACTION …

我正在运行 SQL Server 2012 并尝试将一些查询放在一起以使用 DMV 进行监控。但是，当查看DMV中的total_elapsed_time字段时sys.dm_exec_requests，这些数字看起来相差甚远。下面是一个例子：

SELECT
  session_id, RunTime = CURRENT_TIMESTAMP,
  start_time, total_elapsed_time
FROM sys.dm_exec_requests
WHERE session_id = 284;

session_id  RunTime                 start_time              total_elapsed_time
284         2016-04-07 16:14:03.690 2016-04-07 16:08:14.587 1419976

根据我的计算*，经过的时间应该在 349,103 左右——而不是 1,419,976。这减少了超过 4 倍。

_{* 从当前时间和start_time之间的差异，以毫秒为单位，即
SELECT DATEDIFF(MILLISECOND, '2016-04-07T16:08:14.587', '2016-04-07T16:14:03.690');}

这是服务器信息：

SELECT @@VERSION;

Microsoft SQL Server 2012 - 11.0.5592.0 (X64) 
    Apr 17 2015 15:18:46 
    Copyright (c) Microsoft Corporation
    Enterprise Edition: Core-based Licensing (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack …

确定正在执行的存储过程的一种方法是使用“动态管理”方法，如下所示：

SELECT 
    sqlText.Text, req.* 
FROM 
    sys.dm_exec_requests req
OUTER APPLY 
    sys.dm_exec_sql_text(req.sql_handle) AS sqltext

但是，这仅显示存储过程的 create 语句的文本。例如：

CREATE PROCEDURE IMaProcedure @id int AS SELECT * FROM AllTheThings Where id = @id

理想情况下，我想看看运行过程的参数是什么，导致它针对特定的一组违规参数运行这么长时间。

有没有办法做到这一点？（在这个问题中， Aaron Bertrand提到了DBCC InputBuffer，但我认为这不适合这个问题。）

DMV sys.dm_exec_query_stats中last_worker_time和last_elapsed_time是什么意思，它们之间有什么区别？

    SELECT TOP 20 
qs.last_worker_time, qs.last_worker_time/1000000 last_worker_time_in_S,
qs.last_elapsed_time, qs.last_elapsed_time/1000000 last_elapsed_time_in_S
FROM sys.dm_exec_query_stats qs
order by qs.last_worker_time desc