mssql最佳化學習筆記之三

昨天終於看到了MSSQL接近真正最佳化的東西，總結一下：
工作負荷的監視：
1、系統負載突然很大程度的偏離基線有如下原因：
（1）統計資訊更改和有用索引的刪除；
（2）鎖粒度的變化；
（3）“無賴”會話；
（4）工作負載變化；
（5）正常的業務和相關負荷的增長；
（6）mssql升級；
（7）硬體資源極限；
2、探測、隔離和解決常見效能問題：主要涉及cpu、memory、I/O、tempdb、blocking：
（1）cpu:工作者（worker）用來完成使用者和系統內部任務，它一般處於三個狀態：
running:正在CPU上；
runnable:在CPU佇列上等待；
suspended:等待其他資源；
探測：
你可以透過系統效能監視器的計數器：Processor:% Processor  Time(所有CPU平均值)來診斷CPU瓶頸，如果該計數器15-20分鐘內持續高於80%，說明該系統CPU資源緊張；
你也可以透過效能監視器的計數器：System:Processor Queue Length(估計所有CPU平均值)來確定CPU瓶頸，如果該計數器持續高於2，那麼說明該系統CPUT緊張，這裡，需要說明一點，對多CPU或多核CPU來說，個人感覺應該該值/系統cpu數；
同時，你也可以透過效能監視器的計數器：Process:%Processor Time(程式所有執行緒處理時間總和)來確定MSSQL使用CPU的比例，前提是如果系統上只有MSSQL應用，除了程式花費CPU資源，我想還有系統的吧。如果系統上還有其他應用，那麼就不能確定MSSQL到底用了系統的CPU資源的比例，那麼只能透過自己設定的基線來進行對比了。
當然，你也可以透過DMVS來獲取工作者數目（workers）來探測CPU的負載狀況：
SELECT COUNT(*) AS workers_waiting_for_cpu, t2.Scheduler_idFROM sys.dm_os_workers AS t1, sys.dm_os_schedulers AS t2WHERE t1.state = 'RUNNABLE' AND   t1.scheduler_address = t2.scheduler_address AND   t2.scheduler_id < 255GROUP BY t2.scheduler_id
也可以透過獲取workers處於runnale狀態的時間來確定CPU負載：
SELECT SUM(signal_wait_time_ms)FROM sys.dm_os_wait_stats