--检测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
