2011-12-10 39 views
3

過去幾天我的數據庫服務器的CPU負載持續很高。在調查這個問題,我一直在尋找在目前執行的請求使用查詢在數據庫服務器上使用CPU的查詢

SELECT session_id, 
     request_id, 
     Db_name(database_id), 
     start_time, 
     status, 
     command, 
     Substring(txt.TEXT, (statement_start_offset/2) + 1, 
     ((CASE statement_end_offset 
     WHEN -1 THEN Datalength(txt.TEXT) 
     ELSE statement_end_offset 
                    END 
      - statement_start_offset)/2) + 1) AS statement_text, 
     wait_type, 
     wait_time, 
     blocking_session_id, 
     percent_complete, 
     cpu_time, 
     reads, 
     writes, 
     logical_reads, 
     row_count 
FROM sys.dm_exec_requests 
     CROSS APPLY sys.Dm_exec_sql_text([sql_handle]) AS txt 
WHERE session_id <> @@SPID 
     AND session_id > 50 

大多數時候,我發現,除了從應用服務器發送的常規查詢,也有這似乎是消費這些怪異的小號查詢一小部分CPU時間。 例如

Screen shot from query analyzer I took yesterday for the above query

它們不會出現在SQL事件探查器。任何人都有想法他們是什麼以及應該怎樣處理他們?

+0

命令列告訴它它是一個SELECT語句。但看看Statement_Text欄 - 它只是說S.沒有別的。然後看看cpu_time,logical_reads等等。這個S似乎並沒有出現在SQL分析器中。我想知道如何進一步調試。 – shashi

+3

嘗試捕獲整個'txt.text'。很確定你的'子串'代碼會被證明是錯誤的。 –

+0

我使用Derek Dieter的sp_who3進行此類調查。你的子串代碼與他有點不同。 :http://sqlserverplanet.com/dmv-queries/a-better-sp_who2-using-dmvs-sp_who3/ – brian

回答

2

我的猜測是,如果你有statement_start_offsetstatement_end_offset一起捕捉整個的txt.text,你會發現,有一些情況下,當偏置列既可以變成是0等顯示statement_text被截斷,只顯示你SELECT查詢的第一個字符。

DECLARE @text nvarchar(max); 
SET @text = 'SELECT .....'; 
DECLARE @statement_start_offset INT; 
SET @statement_start_offset = 0; 
DECLARE @statement_end_offset INT; 
SET @statement_end_offset = 0; 


SELECT 
     Substring(@text, (@statement_start_offset/2) + 1, 
     ((CASE @statement_end_offset 
     WHEN -1 THEN Datalength(@text) 
     ELSE @statement_end_offset END 
      - @statement_start_offset)/2) + 1) AS statement_text 

我找不到的時候statement_end_offset將返回0而不是-1雖然任何指示。

相關問題