|
|
|
|
|
|||||
|
|||||
| 樓主 純真的人
發送站內信![]() |
Microsoft OLE DB Provider for SQL Server 錯誤 '80004005'
[DBNETLIB][ConnectionRead (recv()).]一般網路錯誤。 查閱您的網路文件。 請問遇過此問題的高手們~這種錯誤到底是怎樣引起的?要如何解決?? 我一台主機已經用2年了,是win2003系統,會用到MSSQL 2005資料庫原本也只有公司在查詢資料使用。 年初時,有個客戶進來主機寄放,他網站是用到MSSQL資料庫,使我的主機增加了些負荷~ 然後這個問題在3月出現過一次(清晨1點左右掛掉),當時將主機重開就正常了,不然都無法連入資料庫操作。 今天又出現了一次這狀況(清晨5點左右掛掉)...也是將主機重開機修復此問題。 不知道是不是MSSQL不能負擔太多連線查詢?(因為要開放1433埠讓外面許多的程式不斷查詢或異動資料) 想請問這問題是不是有什麼建議可以解決的? 周邊設備光纖50M/5M網路、基本Router一台分享器、主機普通等級
本篇文章發表於2012-05-06 14:11
個人網站:純真之家-jerwei暫定網址:http://w3.loxa.com.tw/jer5173 |
||||
| 什麼是iT Power資訊報 | 2010年藍色小舖認證專家風雲榜完全名單 |
| 1樓
不錯的參考
pilipala |
之前的討論文章 [DBNETLIB][ConnectionRead (recv()).] 怎麼都沒有官方技術文件
本篇文章回覆於2012-05-06 16:36
--未登入的會員無法查看對方簽名檔--
|
| 2樓
作者回應
純真的人 |
其實我有看過這篇~
但是看起來是微軟系統的瑕疵..... 感覺是MSSQL的TCP連線數過多會掛掉.... 雖然重開機就會好了,但不知道還有沒有其他的辦法解決的類似MSSQL資料庫的Bug...
本篇文章回覆於2012-05-06 19:46
--未登入的會員無法查看對方簽名檔--
|
| 3樓
不錯的參考
小羊窒息 |
我也遇過客戶的系統(當時是win2000 server)三不五時出現類似的問題,
基本上是死在SQL Server, 但不是TCP連線數的問題, 而是特定的查詢方式必死... (每次都是某一支程式的查詢指令丟下去,就死掉..., 就算是Server剛重開機完也一樣) 後來為了解決問題,把SQL簡化,一些原本在SQL內直接完成的事,移到 asp.net來處理... 但同樣的問題程式在別台SQL Server就沒問題, ====================== 後來,因為資安問題,客戶的系統升級到2003 Server(重新灌一個2003 Server), 然後再把SQL Server裝好, 原本的問題就沒了... 從此之後,遇到那種問題時,我會去客戶那邊準備另一個環境, 然後展示給客戶看,表示換一台資料庫主機就完全沒問題。。。 然後就可以跟客戶表示,是原主機本身的問題........
本篇文章回覆於2012-05-06 20:14
--未登入的會員無法查看對方簽名檔--
|
| 4樓
作者回應
純真的人 |
所以說...SQL查詢下到極度用法~造成MSSQL出問題~
也許可能當初我寫在程式查詢的SQL指令...應該是3月左右...把他存到Procedure裡面~ 導致會有這狀況發生.... 當初會寫到Procedure就是,因為SQL資料查詢計算過久,導致ASP網頁出現MSSQL存取過久被強制中止~ 所以...我想應該是我把他存到Procedure那段惹的問題... 嗯~想想那段SQL該怎樣處理...因為那個SQL把原本分次跑都幾10萬筆的更新運算,一次變更資料...造成過久.. 以後累積到幾百萬筆...可能會更慘...
本篇文章回覆於2012-05-07 01:33
--未登入的會員無法查看對方簽名檔--
|
| 5樓
最有價值解答
小羊窒息 |
如果你遇到【[DBNETLIB][ConnectionRead (recv()).]一般網路錯誤】的時候,
還有一些程式是可以跑的(可以查資料) 而不是所有的程式都出現 一般網路錯誤, 那, 應該就是了... 簡單來說就是超出了SQL Server的預期 (例如:有某個排序指令將文字轉成數字再排序, 在Table本身的資料量少的時候影響不大, 但遇上Table本身的資料量大的時候, 非預期的轉換問題就會出現...) 其實也可以歸咎於 舊系統當初在規畫時, 沒有做好一定程度的[反正規化]... (資料少的時候都不會有問題, 問題都是在資料量變多時, 才開始浮現...) 我最近在規劃系統時, 幾乎會盡可能的去避免join... 盡量減少join的機率...或是join的Table數...(原本要join 3個, 可能就試著去調整到剩2個之類的) 不然光是執行效率這種事, 就會讓人哭死...
本篇文章回覆於2012-05-07 15:50
--未登入的會員無法查看對方簽名檔--
|
| 6樓
作者回應
純真的人 |
>>還有一些程式是可以跑的(可以查資料)
>>而不是所有的程式都出現 一般網路錯誤, 是有用到MSSQL資料庫的網站都掛掉,除了一般用Access的網站可以正常運作。 因為出現那種錯誤,連MSSQL管理工具的介面都無法登入,所以在重開機後MSSQL就正常了。 說到join的確是有用到2~3個資料表,果然計算獎金的查詢方式,雖然很快....但容易讓資料庫趴了~
本篇文章回覆於2012-05-08 09:40
--未登入的會員無法查看對方簽名檔--
|
| 7樓
作者回應
純真的人 |
也許問題在...每5分鐘(24Hr都在跑)Run一次大量查詢,對MSSQL負荷滿大...
不知道你們客戶的網站也會像我這樣需求的嗎?常常在跑大量查詢~24小時每五分鐘都在檢查資料有沒有異動~有異動就做一堆update的更新動作...
本篇文章回覆於2012-05-08 09:46
--未登入的會員無法查看對方簽名檔--
|
| 8樓
作者回應
純真的人 |
最近又多了一項異地遠端查詢更新...希望這個應該不要出問題...
例如: update [xxxx.com.tw].DBName.dbo.Web_Table set a.Web_Date = b.Web_Date from [xxxx.com.tw].DBName.dbo.Web_Table as a left join Web_Table as b on a.Web_Table_ID = b.Web_Table_ID where a.Web_Table_ID in(select c.Web_Table_ID from Web_Table as c where Convert(varchar,c.Web_Date,111) = Convert(varchar,GetDate(),111)) 因為現在電腦上傳頻寬都在5M(等hinet開放上傳100M再申請吧),所以這樣的更新都在幾秒內完成。
本篇文章回覆於2012-05-08 10:03
--未登入的會員無法查看對方簽名檔--
|
| 9樓 |
你的問題太嚴重了,幾乎是SQL Server。。。Direct Crash。。。。
本篇文章回覆於2012-05-08 11:49
--未登入的會員無法查看對方簽名檔--
|
| 10樓
作者回應
純真的人 |
Q_Q!...意思是我把SQL Server操的太過火了嗎...
本篇文章回覆於2012-05-08 11:54
--未登入的會員無法查看對方簽名檔--
|
| 11樓
作者回應
純真的人 |
那我還是不要把SQL指令都改存到預存程序好了..
還是用程式慢慢更新到資料庫好了@@"""
本篇文章回覆於2012-05-08 14:03
--未登入的會員無法查看對方簽名檔--
|
| 回覆 |
| 如要回應,請先登入. |
|
![]() |
|
|