我有一個存儲過程在Microsoft SQL Server 2012數據庫上運行,它經常(但並非總是)在某個點掛起。當我執行特定的更新查詢本身時,它運行良好,但是如果它在整個過程中執行,此後沒有任何反應。這是它出錯:SQL查詢掛起沒有錯誤(並行子查詢?)
UPDATE dbo.gesch_gzp
SET red_ges=1
WHERE uitg_verr_id IN (
SELECT uitg_verr_id
FROM dbo.gzp_flagging_2
WHERE flag BETWEEN 2200 AND 2299
AND flag IN (
SELECT flag
FROM flagging
WHERE lts=1
)
)
注視等待任務(dm_os_waiting_tasks)我強烈地得到的印象是它是與parallellism,由於具有相同的session_id,但不同exec_context_id那裏等待多個子進程彼此。 因此,我已經嘗試添加選項(MAXDOP 1),並添加了一個DISTINCT到第一個選擇,但沒有與所需的效果(重新啓動存儲過程後,它掛在完全相同的點)。
UPDATE dbo.gesch_gzp
SET red_ges=1
WHERE uitg_verr_id IN (
SELECT DISTINCT(uitg_verr_id)
FROM dbo.gzp_flagging_2
WHERE flag BETWEEN 2200 AND 2299
AND flag IN (
SELECT flag
FROM flagging
WHERE lts=1
)
)
OPTION(MAXDOP 1)
所以我想知道是否有一種方法來重寫這個存儲過程,以防止它掛起。複雜的事情是,這個有問題的更新查詢恰好在一個很長的程序的末尾,這個程序需要24小時才能執行。並且執行更新查詢本身不會再現問題(這需要幾分鐘),所以這使測試變得困難。
聽起來像是阻塞問題。你可以在SP應該運行時檢查阻塞嗎? –
@ Dave.Gugg,不確定你的意思,但查詢dm_os_waiting_tasks會導致一些進程具有相同的session_id,並被具有相同session_id的其他進程阻止。例如:'session_id = 76,\t exec_context_id = 3,\t wait_time = 78435004,\t wait_type = CXPACKET,blocking_session_id = 76,blocking_exec_context_id = 1,resource_description =「exchangeEvent id = Pipe4a858fe20 WaitType = e_waitPipeGetRow nodeId = 10」'。但是我必須說,這是在添加Maxdop之前,添加此選項後在服務器重新啓動期間丟失了什麼。 – shardeman