與TomTom一致,你必須深入到底部。好的猜測是缺乏/不準確的索引,它通常會導致高CPU數量的會話。 檢查您的DMV的信息(不過要小心,他們剛剛從SQL引擎提示,應該由受過培訓的專業人員進行分析):
SELECT
migs.avg_total_user_cost * (migs.avg_user_impact/100.0) * (migs.user_seeks + migs.user_scans) AS improvement_measure,
'CREATE INDEX [missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle)
+ '_' + LEFT (PARSENAME(mid.statement, 1), 32) + ']'
+ ' ON ' + mid.statement
+ ' (' + ISNULL (mid.equality_columns,'')
+ CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END
+ ISNULL (mid.inequality_columns, '')
+ ')'
+ ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement,
migs.*, mid.database_id, mid.[object_id]
FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
WHERE migs.avg_total_user_cost * (migs.avg_user_impact/100.0) * (migs.user_seeks + migs.user_scans) > 10
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC
2008 R2 - 什麼是SQL Server的忙?使用分析儀表板來找出cpu實際在做什麼。可能是一些卡住的數據庫檢查/修復,只需要很長時間,並重新啓動服務器重置它啓動? – TomTom 2012-03-08 10:02:58
即使我們重新啓動數據庫服務器,問題也是一樣的。當我們停止SQL服務器服務時,只有cpu使用情況是正常的。 – Bangar 2012-03-08 10:46:04
你讀過我說過的嗎?當然,當它卡住了數據庫tc。並且您重新啓動它將會再次嘗試。你有沒有考慮過查看sql服務器日誌以瞭解服務器啓動後會發生什麼? – TomTom 2012-03-08 11:53:09