如何檢查SQL Server CPU瓶頸

--檢測CPU壓力的一個方法是計算運行狀態下的背景工作處理序數量，
--通過執行如下的DMV查詢可以得到這個資訊

SELECT COUNT(*) AS workers_waiting_for_cpu,t2.scheduler_id
FROM sys.dm_os_workers AS t1, sys.dm_os_schedulers AS t2 
WHERE t1.state='RUNNABLE' AND  
t1.scheduler_address = t2.scheduler_address AND
 t2.scheduler_id<255
GROUP BY t2.scheduler_id

--也可以執行如下的查詢得到背景工作處理序在可運行狀態下花費的時間

SELECT SUM(signal_wait_time_ms) FROM sys.dm_os_wait_stats

--下面是一個DMV查詢，它可以用來找出每次執行中佔用CPU最多的錢10為查詢，
--也列出了SQL語句的查詢計劃及計劃被執行的次數。如果一個查詢大家雖高，
--但執行次數少，那也可以採納。

SELECT TOP 10 
total_worker_time/execution_count AS avg_cpu_cost, plan_handle,execution_count,
    (SELECT SUBSTRING(text,statement_start_offset/2+1,
        (CASE WHEN statement_end_offset=-1
THEN LEN(CONVERT(NVARCHAR(max),text))*2
ELSE statement_end_offset
END -statement_start_offset)/2)
FROM sys.dm_exec_sql_text(sql_handle)
    ) AS query_text
FROM sys.dm_exec_query_stats 
ORDER BY [avg_cpu_cost] DESC

--以上DMV只顯示當前被緩衝的查詢合計統計資訊
--為了找出工作負載中運行最頻繁的查詢，就需要執行下面的DMV查詢。

SELECT TOP 10 total_worker_time ,plan_handle,execution_count,
    (SELECT SUBSTRING(text,statement_start_offset/2+1,
        (CASE WHEN statement_end_offset=-1
THEN LEN(CONVERT(NVARCHAR(max),text))*2
ELSE statement_end_offset
END -statement_start_offset)/2)
FROM sys.dm_exec_sql_text(sql_handle)
    ) AS query_text
FROM sys.dm_exec_query_stats ORDER BY execution_count

--SQL Server在最佳化查詢計劃上花費的時間可以用下面的DMV查詢

SELECT * FROM sys.dm_exec_query_optimizer_info WHERE counter='optimizations' 
UNION
SELECT * FROM sys.dm_exec_query_optimizer_info WHERE counter='elapsed time'


SELECT TOP 10 plan_generation_num ,plan_handle,execution_count,
    (SELECT SUBSTRING(text,statement_start_offset/2+1,
        (CASE WHEN statement_end_offset=-1
THEN LEN(CONVERT(NVARCHAR(max),text))*2
ELSE statement_end_offset
END -statement_start_offset)/2)
FROM sys.dm_exec_sql_text(sql_handle)
    ) AS query_text
FROM sys.dm_exec_query_stats
WHERE plan_generation_num>1
ORDER BY execution_count

 
 --檢查快取記憶體

 DBCC memorystatus 

本文來自CSDN部落格，轉載請標明出處：http://blog.csdn.net/dz45693/archive/2010/01/27/5260697.aspx