SQL Server 2005效能測試之CPU篇（編譯與重編譯）

　　如果在沒有額外複雜條件下突然出現CPU瓶頸，有可能是因為沒有最佳化查詢，錯誤的資料庫配置，或者是資料庫設計上的原因和硬體資源不足引起。在決定採用增加CPU數量或者使用更快速的CPU之前，應該先檢查消耗CPU資源最多的操作是否能夠被最佳化。

　　如果發現效能計數器Processor: % Processor Time的值很高，每一個CPU的% Processor Time都超過80%時，可視為出現CPU瓶頸。也可以通過視圖sys.dm_os_schedulers監視SQL Server的進程調度（schedulers）來確認可執行檔任務是否為非零值。非零值表示任務被迫等待時間片來運行，如果這個數值非常高，說明存在CPU瓶頸。

Select scheduler_id,current_task_count,
runnable_task_count from sys.dm_os_schedulers where scheduler_id<255

　　下面的查詢將給出一個較高層的視圖來說明當前被緩衝的消耗CPU資源最多的批處理或者過程。查詢通過相同查詢控制代碼的所有語句合計CPU的消耗情況。

Select top 50 sum (qs_total_worker_time) as total_cpu_time,sum(qs.execution_count)
as total_execution_count, count(*) as number_of_statements,
qs.plan_handle from sys.dm_exec_query_stats qs group by qs.plan_handle order
by sum(qs.total_worker_time) desc

　　過多的compilation和recompilation

　　在批處理或者遠端程序呼叫（RPC）提交到伺服器執行之前，系統會檢查查詢計劃的有效性和正確性。如果在檢查過程中出現了失敗的情況，這些批處理可能會被再次編譯來產生新的查詢計劃。這樣的編譯被稱為重編譯（recompilations）。這些重編譯一般必須確定正確性且通常在伺服器認定在潛在資料發生變化後存在可能被優厚的查詢計劃時執行。編譯的特性是CPU敏感的操作，因此過分的重編譯可以導致CPU效能問題。