SQL Server 迅速定位致使數據庫服務器性能降低的存儲過程或者查詢

生產環境中都會按期作release，release完成後有時候數據庫服務器會出現CPU和內存飆升的現象，須要有監控機制監控。

當這個問題出現的時候，大多數都是由於release時候有數據上的很大變更，統計信息並無更新，致使緩存的執行計劃出現很大的誤差，性能極具降低，尤爲是那種每分鐘屢次調用的存儲過程。

這種狀況下，只須要從新編譯一下這個存儲過程，使之生成新的正確的執行計劃便可。

如何迅速定位是哪一個存儲過程出現的問題，下面的方法快捷方便：

第一步:  查出正在跑的存儲過程，找到耗時長的spid, 多記錄幾個spid，大部分狀況是，雖然spid不一樣，可是調用的存儲過程倒是同一個

select p.session_id, p.request_id, p.start_time,percent_complete,
 p.status, p.command, p.blocking_session_id, p.wait_type, p.wait_time,
 p.wait_resource, p.total_elapsed_time as [total_elapsed_time_milliseconds],
 (p.total_elapsed_time/1000)/60 as [total_elapsed_time_minutes], p.open_transaction_count,
 p.transaction_isolation_level,
 substring(qt.text, p.statement_start_offset /2,
  (case when p.statement_end_offset = -1 then len(convert(nvarchar(max),qt.text) )* 2
  else p.statement_end_offset end - p.statement_start_offset) / 2 ) as sqlstatement,
 p.statement_start_offset, p.statement_end_offset, batch=qt.text
from master.sys.dm_exec_requests p
 cross apply sys.dm_exec_sql_text(p.sql_handle) as qt
where p.session_id>50

 

第二步： 用DBCC 命令，定位存儲過程

dbcc inputbuffer(spid)

 

第三步： 從新編譯此存儲過程

sp_recompile spname

 

搞定！