數據集超時而查詢運行時立即

我直接運行查詢，它在本質上是簡單的：數據集超時而查詢運行時立即

SELECT * FROM [dbo].[vwUnloadedJobDetailsWithData] WHERE JobId = 36963

當我運行這個從Management Studio中的查詢甚至不採取第二個。當我從表格適配器中運行它時，它超時。我已經多次修復這個問題，但修復很可笑。如果我從我的xsd文件中刪除表格適配器並重新創建它，查詢時間與管理工作室的查詢時間相匹配大約兩天，但是我必須重新部署它是asinine。

任何有關可能導致此問題的見解將不勝感激。我已經看到另一個關於這個問題，但在查詢之前涉及set arithabort的解決方案對我沒有任何影響。

編輯：有人問我顯示我的代碼調用查詢。現在，這種情況發生，當我進入我的XSD文件，只是做預覽數據爲好，但爲了清楚起見，在這裏它是：

using (TEAMSConnection connection = new TEAMSConnection()) 
{ 
    connection.OpenConnection(); 

    _JobDetailsDAO jobDetailDao= new _JobDetailsDAO(connection); 
    return jobDetailDao.GetUnloadedJobDetailsByJobId(jobId); 

}

在處置連接的數據庫連接被關閉。使用這行代碼：

if (_DBConnection != null && _DBConnection.State == ConnectionState.Open) 
    _DBConnection.Close();

EDIT2：我跑了跟蹤和這裏是正在建立

SET QUOTED_IDENTIFIER上 SET ARITHABORT關閉集NUMERIC_ROUNDABORT關閉 SET ANSI_WARNINGS上組的設置選項在集上集CONCAT_NULL_YIELDS_NULL SET ANSI_NULLS ANSI_PADDING CURSOR_CLOSE_ON_COMMIT關閉集IMPLICIT_TRANSACTIONS關閉集語言美國英語設置日期格式MDY 設置DATEFIRST 7 組的事務隔離級別讀取承諾

我去，並補充說，以我在管理Studio生成查詢，它仍然在不到一秒鐘跑了。我甚至完全按照跟蹤複製了查詢。

exec sp_executesql N'SELECT * FROM [dbo].[vwUnloadedJobDetailsWithData] WHERE JobID = @JobId',N'@JobId int',@JobId=36963

並且它仍然不到第二個返回時間。我非常困惑。

感謝，喬希

來源

2009-07-22 joshlrogers

這聽起來像你沒有關閉你的數據庫連接，但很難確定發生了什麼事情，因爲你沒有共享c＃代碼。 – 2009-07-22 14:33:38

對不起，沒有太多的代碼可以分享.....只要關閉連接，他們肯定會關閉。如果你認爲它有幫助，我會發布我的查詢和連接處理。 – joshlrogers 2009-07-22 14:35:57

最有可能scenarion爲什麼會發生在SSMS和ado.net之間SET選項的區別。這種差異導致（重新）制定可能不是最佳的執行計劃。

來源

2009-07-22 14:43:12

好的，以及我找不到任何解決方案，將繼續允許我使用數據集，所以我直接在代碼中使用SqlDataAdapter而不是使用自動生成的TableAdapter。

根據跟蹤它執行完全相同的查詢，但到目前爲止它的工作。它可能不會在兩天內，但現在看來似乎起作用。

來源

2009-07-22 20:46:10 joshlrogers

只是試圖大聲思考：也許是由另一個進程/人員造成的鎖定？有沒有人同時更新同一行？有沒有人從Management Studio或查詢分析器打開表格並打開表格功能並使用過濾器進行播放？嘗試使用sp_who2

來源

2009-07-26 15:33:38

的幾點思考尋找鎖：

我會打電話參數嗅探存儲過程。嘗試OPTION (RECOMPILE)提示，讓您發送SQL是這樣的：

exec sp_executesql 
    N'SELECT * 
     FROM [dbo].[vwUnloadedJobDetailsWithData] 
     WHERE JobID = @JobId 
     OPTION (RECOMPILE)', 
    N'@JobId int', 
    @JobId=36963

說明：當查詢計劃生產和緩存，它可能是一個壞的，非典型的價值。說JobID通常是非常有選擇性的，但是對於那個執行它不是。當您運行查詢時，下一個計劃的緩存計劃對於下一個選擇性JobId是錯誤的。計劃將因各種原因重新編譯，但重新編譯的價值很重要。

否則，Jobid的確切數據類型是什麼？如果smallint，那麼該列將在參數化查詢中轉換爲int。當使用常量時，它將是smallint。確保類型正確定義：這在SQL代碼中很重要。

來源

2009-08-01 08:34:12 gbn

數據集超時而查詢運行時立即

回答

相關問題