您好,登錄后才能下訂單哦!
生產環境的系統,在查詢數據的時候,日志記錄數據“Timeout 時間已到。在操作完成之前超時時間已過或服務器未響應。”,“等待的操作過時”等,初步判斷是因為查詢超時導致的,根據源碼分析,獲取到查詢操作的SQL腳本,然后跟蹤到查詢業務的SQL參數信息,在數據庫中查詢,發現數據的返回時間小于1s,基本上是實時返回,排除了鎖表等操作。
后更改數據查詢的超時時間,改成3分鐘,系統還是報查詢超時。但是程序在測試環境,反復的測試,也沒有問題;而且程序昨天是正常的,數據量也沒有出現暴增的情況,整體的數據量也不大。
后通過網絡查詢,發現有重啟服務器解決該問題的方法,但是由于是生成環境,沒法進行重啟服務器,客戶在等,很是著急。后在通過萬能的網絡,查詢到,可能是參數化傳參導致的,傳遞參數的SqlDbType和數據庫里的類型不一致會導致出現數據庫上直接查詢,返回數據很快,但是通過程序去查詢,會出現查詢超時的情況。然后去檢查程序和數據庫,發現確實不一致,程序中使用的是SqlDbType.VarChar,但是在數據庫存儲中使用的數據類型是NVarChar。
然后修改程序的SQL語句不是參數化傳參,改為拼接的方式,然后發布程序,登錄檢測,發現程序正常返回數據,這樣看來,問題就出現在C#程序中的參數化的參數類型和數據庫中的類型不一致導致的。
這個Bug,是個隱藏的Bug,問題不會一直出現,因為程序中這樣操作的,不僅僅是這個查詢的一處地方。這次的問題比較特殊,做個記錄,以備下次查詢。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。