在具有多個分區表的數據庫上連接系統表和DMV時的性能問題？

Question

我在環境中的每個數據庫上運行以下查詢，每天兩次，以進行跟蹤。我有一個數據庫相對較忙的服務器，該查詢的計數爲95k行（該數據庫包含許多大約20個可以有多個分區，一些多於300個的表）。在我的所有其他服務器上運行良好，但對於這個數據庫，我開始遇到問題，它在幾分鐘內完成，但現在將運行超過18分鐘。

如果我只是做一個COUNT，它會在大約1秒內回到93462。

SELECT i.name需要2秒（返回93462行）

SELECT p.rows至少需要18分鐘

sp_whoisactive顯示沒有WAIT_INFO。我嘗試使用SQL Sentry計劃資源管理器的WAIT STATS功能，但由於查詢永遠不會結束（最長我已經讓它運行了18分鐘），我沒有得到任何結果。

這是SQL服務器2016年SP1的CU2，企業，64位

所有幫助非常感謝！

SELECT distinct 'mydbname' AS database_name, 
     SCHEMA_NAME(o.schema_id) AS table_schema, 
     o.name AS table_name, 
     i.name AS index_name, 
     o.type_desc as type_desc_full, 
     CASE i.type 
       WHEN 0 THEN 'HP' 
       WHEN 1 THEN 'C' 
       WHEN 2 THEN 'NC' 
       WHEN 3 THEN 'XM' 
       WHEN 4 THEN 'Sp' 
       WHEN 5 THEN 'CS' --clustered columnstore, which doesn't exist (yet) 
       WHEN 6 THEN 'cs' --nonclustered columnstore, available in 2012. 
     ELSE 'UK' END AS type_desc_brief, 
     MAX(a.type) as allocation_type, 
     MAX(p.rows) AS rows_in_table, 
     SUM(a.total_pages * 8/1024) AS Total_MB, 
     avg(u.user_seeks) AS user_seeks, 
     MAX(last_user_seek) AS last_user_seek, 
     avg(u.user_lookups) AS user_lookups, 
     MAX(last_user_lookup) AS last_user_lookup, 
     avg(u.user_scans) AS user_scans, 
     MAX(last_user_scan) AS last_user_scan, 
     avg(u.user_updates) AS user_updates, 
     MAX(last_user_update) AS last_user_update 
FROM sys.indexes i 
JOIN sys.objects o 
     ON i.object_id = o.object_id 
LEFT JOIN sys.dm_db_index_usage_stats u 
     ON i.object_id = u.object_id 
      AND i.index_id = u.index_id 
      AND u.database_id = DB_ID() 
inner JOIN sys.partitions as p 
     on i.object_id = p.object_id 
     and i.index_id = p.index_id 
INNER JOIN sys.allocation_units AS a 
     on (a.type = 2 AND p.partition_id = a.container_id) 
     OR ((a.type = 1 OR a.type = 3) AND p.hobt_id = a.container_id) 
--WHERE o.type_desc NOT IN ('SYSTEM_TABLE', 'INTERNAL_TABLE','SQL_TABLE_VALUED_FUNCTION')   -- No system tables! 
GROUP BY SCHEMA_NAME(o.schema_id), 
     o.name, 
     i.name, 
     o.type_desc, 
     CASE i.type 
       WHEN 0 THEN 'HP' 
       WHEN 1 THEN 'C' 
       WHEN 2 THEN 'NC' 
       WHEN 3 THEN 'XM' 
       WHEN 4 THEN 'Sp' 
       WHEN 5 THEN 'CS' --clustered columnstore 
       WHEN 6 THEN 'cs' --nonclustered columnstore, available in 2012. 
     ELSE 'UK' END 

Answer 1

我見過由於訪問sys.partitions而導致阻塞。我相信sys.partitions.rows來自stats對象。可能是從大量的單個對象中收集，而任何一個統計對象可能是阻塞的軌跡。

sys.dm_session_wait_stats是否會流光？