❶ 語句和事務超時設置都是0，但總是出現超時，提示超時的sql語句很簡單，單獨執行不超過100毫秒
摘要 執行SQL時，需要關注其執行時花費的時間，避免SQL執行過長的時間，佔用資料庫的資源。對於OLTP類型的系統，SQL的執行時間一般來說都是比較短的，假如某個SQL執行時間超出平均值，則需要給予特別的關注，分析下是正常情況還是代碼問題。
❷ 如何解決訪問sql資料庫超時問題
adoconnection1.CommandTimeout = 0命令執行超時時間(以秒為單位),設置為零說明無限制adoconnection1.ConnectionTimeout = 0連接資料庫超時時間(以秒為單位),設置為零說明無限制
❸ SQL資料庫的超時時間怎麼設置
進入企業管理器——單擊資料庫右鍵——屬性——裡面有設置的。
❹ SQL 超時解決方案 有時並不是設置問題
Server.scrīptTimeout,默認值是90秒.
要增大它,在你的asp文件中加一句,如下:
Server.scrīptTimeout=999,
將頁面超時設為999秒.
最初我只設置Server.scrīptTimeout,
但仍會出現timeout錯誤,無論它的值設成都多大.
後在社區里看到一帖子,提到commandTimeout屬性,
於是查看Option
Pack文檔,果然還有timeout.
Connection對象和Command對象都有個CommandTimeOut屬性,
默認是30秒,如果你有一個耗時的查詢或數據處理,
很容易就超時了.要增大它,也很容易,創建對象後,
設置它的屬性,如下:
con.CommandTimeOut
=
999,
設為999秒,其中con是一Connection對象.
如設為零,將無限等待,沒有這一timeout限制.
Command對象不會繼承Connection的這一屬性,
所以對可能超時的Command也要單獨設置CommandTimeout屬性.
最後IE也有個超時設置,5分鍾從伺服器得不到數據,也超時.
這種情況可能很少碰到,
但當我把一10多萬查詢的結果保存為mdb文件時,
就遇到了.(至於保存的方法,請參看精華區中的一篇帖子.)
解決方法:(原文請參照微軟KB中的Q181050)
之前在做IC交易網的時候因數據太大了，超1000萬，加了內存解決
1.
IE要4.01
sp1以上版本.
2.
在注冊表中HKEY_CURRENT_USERSoftwareMicrosoft
WindowsCurrentVersionInternet
Settings中
加一DWORD類型ReceiveTimeout,值設為比如8個9.
3.
restart
computer.
❺ sql 查詢超時
剛才去 VS2010 裡面去創建了一下， 結果如下：
樓主的 超時的寫法是正確的
Data Source=localhost\SQLEXPRESS;Initial Catalog=Test;Integrated Security=True;Connect Timeout=1000
假如 設置了很大的 超時, 但是 還是 30秒 超時了
伺服器那裡， 有個配置信息， 要修改一下
在 伺服器那裡， 運行 SQL Server Configuration Manager
客戶端協議那裡 TCP/IP 那裡， 有個
保持活動狀態
此參數（毫秒）控制 TCP 嘗試發送 KEEPALIVE 包以檢查空閑連接是否仍保持原樣的頻率。默認值為 30000 毫秒。
❻ sql資料庫突然提示超時已過期
應該是運行時長時間未進行數據操作，讓伺服器誤以為客戶端請求已經停止就自動關閉聯接。
一般重新運行一下客戶端程序，其實也就是重新聯接一下資料庫，就可以解決這個問題。
❼ SQL超過伺服器連接限制時間
為應用程序池 『DefaultAppPool』 提供服務的進程關閉時間超過了限制
伺服器經常產生「應用程序池 『DefaultAppPool』 提供服務的進程關閉時間超過了限制。進程 ID 是 『2068′。」的錯誤，導致iis處於假死狀態，經了解是IIS應用程序池的設置問題。解決方法如下：
Internet 信息服務(IIS)管理器－＞應用程序池－＞DefaultAppPool－＞右擊屬性
一、回收
1、回收工作進程（分鍾）：選中，值為1740
2、回收工作進程（請求數目）：不選（原先設置為35000）
3、在下列時間回收工作進程：不填
4、消耗太多內存時回收工作進程：全不選。（2、3、4項可能避免了在訪問量高的時候強制回收進程可能引發的伺服器響應問題，導致iis假死不響應）
二、性能
只選中空閑超時20分鍾。其他都不選。WEB園最大工作進程數為1（默認）。注意web園這里一定要保持默認，如果填寫其他超過1的數字就會導致一些網站程序的後台程序打不開或者刷新不停。
原來的請求隊列限制為4000，現在無限制。
三、運行狀況
前兩項都起用，是原來的默認設置。啟動時間限制90秒，關閉時間限制180秒。
啟動快速失敗保護的鉤去掉！
為了避免真的遇到很多錯誤時沒有提示，可以不關閉，只是把快速保護的保護范圍加大些，例如失敗數50次 時間段5分鍾 則關閉對應的程序。
「關閉時間限制180秒」是必須的，因為進程關閉的時間，原來為90秒限制,是默認值，如果進程關閉時間超過90秒，則認為超時，從而出現：進程關閉時間超過了限制 日誌，所以，適當延長這個時間，可以避免這種錯誤
第2種方法：
原因：獨立進程的 內存堆戔消耗完了，IIS不能創建更多的進程工作空間來處理
解決方法：
1. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC
2. 在Parameters鍵下新建一個DWORD項，名字為：UseSharedWPDesktop 值為1 重啟IIS
第3種
問題已解決,發現是資料庫連接無法釋放,不知道是什麼原因,同樣的代碼在本地就是好的,在伺服器端就有問題,最後在連接串里加入以下語句解決問題.
Pooling=true; MAX Pool Size=512;Min Pool Size=50;Connection Lifetime=30
第4種
新建應用程序池，不同的網站引用不同程序池。
為應用程序池 『AppPool #1′ 提供服務的進程關閉時間超過了限制。進程 ID 是 『3000′。
出現上面情況後，該應用程序池對應的網站就訪問的非常慢，幾乎是打不開。
這種現象是不是iis假死？
重啟下該站點，問題可以得到解決。
可能是應用程序池設置問題，不知道具體應該怎麼設置！
請高手指點。
程序代碼解決辦法：
1 設置進程池回收時間.在進程池屬性里.
2 如果你的程序是使用 asp + acc 資料庫.且acc資料庫大於30m.建議更換sql資料庫. acc資料庫大於這個值.2003系統下會造成iis6的頻繁假死.2000下會造成dllhost.exe佔用大量cpu及內存資源.都會嚴重影響 web訪問速度.
3 asp程序存在死循環.
4 可使用 microsoft office 壓縮修復acc資料庫,須先備份.
引用內容2003應用程序池假死常見問題及解決方法
2006-10-09 09:48
經常見到大家談起，2003應用程序池自動死了，不能恢復了，一直出現 Service Unavailable 常見方法如下。
1：以前沒有SP1打補丁的時候會出現這個IIS6。0假死問題，但現在微軟都在自動更新裡面出補丁了，一般你打好最新補丁後是不會出現此問題了。（所以現在的IIS假死與這個關系不是很大）
2：從IIS6.0開始CPU資源都在應用池裡面限制了，不象以前的IIS。5。所以假死的池的緣故就是池被拉死，你在網站打不開的時候可以看到你的某個應用池是禁用的，上面出現一個紅叉。你滑鼠右鍵啟動網站又會自動恢復。 這個原因：大概是以下幾個因數造成的。
（1）：你限制了應用池的資源限制，限製得太小 比如：50這樣或更少更多一點，這個時候如果你這個池下面的網站佔用CPU太高，比如超過50% 那麼5分鍾後他就自動死了，手工默認建立的應用池默認是超過資源不操作。
出現上面這個情況解決方法：1：不限制CPU資源，（這個是不可取的，不限制資源，有的程序有BUG佔用資源厲害了的，伺服器都會被拉死，你可能都無法操作伺服器。）2：在超過資源那裡選擇關閉，這個關閉默認是失敗5次，90秒內恢復，一般默認就可。網站能自動恢復，這個關閉：不是永久關閉，意思是超過資源關閉，然後在某時間內自動恢復池。不操作就是不恢復，這個是很多人的誤區。上次我寫過相關的這個講解了。
（2）：內存限制 在IIS6。0應用池上面有虛擬內存和最大內存限制，如果你設置了這個。那麼網站訪問量大了 也會出現假死，所以不建議設置這里。默認就可。
3：就是伺服器自身內存太小，網站運行當然需要使用到內存了，當內存不夠的時候應用池也會死掉變成禁用。那麼只有等內存全部釋放出來才能恢復應用池了。出現這個情況：那麼你就要考慮加內存或者檢查到底是什麼程序佔用了內存了。比如MSSQL資料庫，這個可是吃內存得大戶啊，最好別和WEB伺服器同時一個伺服器上。很多人用1G內存做 2003系統，2003NET結構是很佔用內存的，所以做伺服器選2003還得把內存加到2G或更高才好。內存不夠上面 2點講到的，是沒辦法操作了，也無法自動恢復。
4：就是ACCESS資料庫太大或查詢太多，這個也會出現把IIS拉死，解決方法；修復ACCESS資料庫，或盡量少用ACCESS資料庫。
5：不同網站用不同應用池：根據你自己實際情況而定，站點大的最好獨立一個應用池，限制他的資源超過了自動回收，看上面（1）講到的，這樣就不影響其他站點。中型站點：多個網站共用一個應用池，比如5個站點用一個池，設置他資源時間等等。這樣他們就算超資源了也不影響其他應用池的網站。
6：設置回收時間：很多人以為設置回收池越短越好，其實是錯誤的，每次回收當然是把內存回收回來了，但加重了一次伺服器的負擔，當伺服器比較繁忙的時候，有可能導致其他應用池死。所以建議設置共1000就行了。其他獨立池按照他網站流量而設置 可以設置600 也行，共用的不建議設置太短。
7：網站後台過不了多久自動退出又要重新登陸：這個情況就是你設置回收時間太短了，按照 6點設置吧。 不要設置什麼20分、30分這樣的，這樣不好的。
❽ 如何配置MySQL資料庫超時設置
大規模多線程操作事務的時候，有時候打開一個鏈接，會進行等待，這時候如果資料庫的超時時間設置的過短，就可能會出現，數據鏈接自動被釋放，當然設置過大也不好，慢SQL或其他因素引起的鏈接過長，導致整個系統被拖慢，甚至掛掉。SO，適當的設置超時時間。設置方法：
SHOW GLOBAL VARIABLES LIKE '%timeout%'
SET GLOBAL wait_timeout=10000
網頁鏈接
❾ mysql資料庫響應超時怎麼辦
MYSQL_OPT_READ_TIMEOUT 是 MySQL c api 客戶端中用來設置讀取超時時間的參數。在 MySQL 的官方文檔中，該參數的描述是這樣的：
MYSQL_OPT_READ_TIMEOUT (argument type: unsigned int *)The timeout in seconds for each attempt to read from the server. There are retries if necessary, so the total effective timeout value is three times the option value. You can set the value so that a lost connection can be detected earlier than the TCP/IPClose_Wait_Timeout value of 10 minutes.
也就是說在需要的時候，實際的超時時間會是設定值的 3 倍。但是實際測試後發現實際的超時時間和設置的超時時間一致。
而具體什麼時候發生三倍超時，在文檔中沒有找到。所以對 MySQL 5.7.20 的源碼進行了一些分析。
使用 GDB 調試代碼找了實際與 mysql server 通信的代碼，如下：
其中 vio_read() 函數中，使用 recv 和 poll 來讀取報文和做讀取超時。net_should_retry() 函數只有在發生 EINTR 時才會返回 true。從這段代碼來看是符合測試結果的，並沒有對讀取進行三次重試。只有在讀取操作被系統中斷打斷時才會重試，但是這個重試並沒有次數限制。
從上面代碼的分析可以看出，代碼的邏輯和文檔的描述不符。於是在一頓搜索後，找到了一個 MySQL 的 BUG(Bug #31163)。該 BUG 報告了在MySQL5.0 中，MySQL c api 讀取的實際超時時間是設置的三倍，與現有文檔描述相符。於是對 MySQL 5.0.96 的代碼又進行分析。
同樣使用 GDB 找到了通信部分的代碼。這次找到了重試三次的代碼，如下：
這個版本的 MySQL api 的讀寫超時是直接使用的 setsockopt 設置的。第一次循環，在 A 點發生了第一次超時（雖然注釋寫的非阻塞，但是客戶端的連接始終是阻塞模式的）。然後在 B 點將該 socket 設置為阻塞模式，C 點這里重置 retry 次數。由於設置了 alarm 第二次以後的循環會直接進入 D 點的這個分支，並且判斷循環次數。作為客戶端時net->retry_count 始終是 1，所以重試了兩次，共計進行了 3 次 vioread 後從 E 點退出函數。
由上面的分析可知，MySQL 文檔對於該參數的描述已經過時，現在的 MYSQL_OPT_READ_TIMEOUT 並不會出現三倍超時的問題。而 Bug #31163 中的處理結果也是將文檔中該參數的描述更新為實際讀取超時時間是設定時間的三倍。也許是 MySQL 的維護者們在後續版本更新時忘記更新文檔吧。
❿ 連接SQl Server時 出現超時時間已到，在操作完成之前超時間已過或伺服器未響應
連接SQl Server時 出現超時時間已到，在操作完成之前超時間已過或伺服器未響應是設置錯誤造成的，解決方法為：
1、連接資料庫的方法代碼。
