Sql Agent Jobs 執行太慢
我以前發布過這樣的問題,但似乎我沒有清楚地解釋整個故事。所以我做了這個來詳細解釋一下。這是儲存過程
USE [xxxx] GO /****** Object: StoredProcedure [dbo].[MARK_ACTIVE] Script Date: 4/20/2015 5:55:53 PM ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER PROCEDURE [dbo].[xxxx] AS SET ANSI_NULLS ON INSERT INTO [123.456.7.890].[DBASE1].[dbo].[TABLE] (smsfr,smsmsg,smsdt,dbdt,devid,status,status2,IsHEX) SELECT TOP 3 smsfr,smsmsg,smsdt,dbdt,devid,status,status2,IsHEX FROM [098.765.4.321].[[DBASE2].[dbo].[TABLE2] cr WHERE NOT EXISTS (SELECT id,smsfr,smsmsg,smsdt,dbdt,devid,status,status2,IsHEX FROM [123.456.7.890].[DBASE1].[dbo].[TABLE] c WHERE cr.smsdt = c.smsdt)
這是我的工作設置
我的將軍
我的腳步
我的進階步驟
我的調度器
當我執行儲存過程時,它執行不到 10 秒,但是當我嘗試使用作業呼叫該儲存過程時,就會發生這種情況
它只是保持進行中的狀態,但沒有任何反應,看起來它陷入了該狀態。
如果您在連結伺服器設置中使用 Windows 身份驗證,即使您正確設置了 Kerberos,它也無法使用 SQL Server 代理工作。您可以將連結伺服器配置為對這些連接使用 SQL 身份驗證,但我建議為此創建一個 SSIS 包,因為身份驗證將更易於配置。
您能否發布連結伺服器配置以獲取更多資訊?
您的查詢程式碼使用兩台伺服器,由 IP 地址標識,如下所示。伺服器在哪裡
$$ 123.456.7.890 $$? 伺服器在哪裡$$ 098.765.4.321 $$? 我的猜測是
$$ 098.765.4.321 $$是個$$ RemoteServer $$和$$ 123.456.7.890 $$是個$$ LocalServer $$. 首先,程式碼慢不是 SQL Agent 的錯。從 SQL 代理執行的程式碼與直接從 SSMS 執行的程式碼一樣高效或低效。問題是您在連結伺服器上移動的數據比您想像的要多得多。這是您的程式碼的大綱:
INSERT ... INTO [LocalServer].[DBASE1].[dbo].[TABLE] SELECT TOP 3 ... FROM [RemoteServer].[DBASE2].[dbo].[TABLE2] WHERE NOT EXISTS (SELECT ... FROM [LocalServer].[DBASE1].[dbo].[TABLE])
如果我已經正確解釋了這一點,那麼很可能大部分數據
[RemoteServer].[DBASE1].[dbo].[TABLE]
都必須被拖到[LocalServer]
並儲存在tempdb
.
WHERE NOT EXISTS
正在處理查找連結伺服器上的前 3 個匹配行的可能性極小。相反,它可能會等待數據出現在本地,然後再處理工作表數據以過濾WHERE NOT EXISTS
然後選擇TOP 3
行。緩慢是由於在伺服器之間移動了多少數據以及
$$ LocalServer $$無權訪問$$ RemoteServer $$的統計。 您還可以在以下網址閱讀使用分佈式查詢的指南:http ://technet.microsoft.com/en-us/library/ms175129(v=sql.105).aspx 該文件的部分內容是:“創建最好的查詢計劃…,查詢處理器必須具有來自連結伺服器的數據分佈統計資訊。”
使用 OPENQUERY 從遠端伺服器獲取結果通常會帶來更好的性能。使用 OPENQUERY 時,查詢被發送到遠端伺服器並在那裡執行,以便將數據返回到本地伺服器。(您會注意到,在 OPENQUERY 中,查詢使用由三部分組成的名稱,因為它直接在遠端伺服器上執行。)
同樣,有時創建要執行的儲存過程
$$ RemoteServer $$將允許首先在該伺服器上進行處理,然後返回更有限的數據集。返回該數據後,$$ LocalServer $$可以完成這個過程。 數據移動對整體性能的影響很大,而在伺服器之間移動數據的成本更高。