SSRS報表連接超時的問題

這段時間遇到一個問題就是ReportService 中採用了遠程連接的報表偶爾會斷開連接，導致報表導出異常，查閱了很多資料，幾天來就是斷斷續續的終於解決了這個問題，下麵把一些解決的點一一展示出來，便於大家將來遇到同樣問題無從下手。

首先是報錯，接下來我馬上去看日誌，很多人不知道文件的位置，一般預設就是這個路徑（Program Files\Microsoft SQL Server\MSRS11.MSSQLSERVER\Reporting Services\LogFiles）。

主要的錯誤如下：

1. System.Data.SqlClient.SqlException: 超時時間已到。在操作完成之前超時時間已過或伺服器未響應。

2. 偶爾還會連接池已滿等錯誤。

綜合一下，問題是時而有，大多數時候沒有，那麼我將問題集中到兩個地方一個是數據量過大導致連接超時，另一個是網路、參數等配置問題。

過濾集中情況：

1.採用了遠程資料庫，不是共用數據源（SharePoint），因此排除了更新數據後對數據源的同步問題。（如果是則需要確保每次看之前數據源得到更新）

2.域賬戶許可權問題，雖然是域內訪問，當時許可權沒有問題，因為大多數時候是可以訪問的。（否則需要添加訪問許可權）

3. 遠程伺服器環境，也沒有問題，資料庫允許遠程連接，且硬碟環境沒有問題。（否則會顯示low disk condition within the database）

接下來是我經過綜合分析修改的幾個地方：

1.配置設置是在 RSReportServer.config 文件中指定的參數。

a.計劃內和計劃外回收操作，影響應用程式池的回收。這個在C#部分將來可以詳細討論

<RecycleTime>720</RecycleTime>

<MaxAppDomainUnloadTime>30</MaxAppDomainUnloadTime>這兩個值預設即可。

b.<Add Key="DatabaseQueryTimeout" Value=""/> 查詢超時時間儘量設置大一些，當然在一些環境下不能這麼做比如頻繁查詢的，數據量較小的時候。對於我的報表系統而言，用的比較少且很多大的報表所以設定為30分鐘。

2.修改web.config中的參數

     httpRuntime是配置asp.net http運行時設置，以確定如何處理對asp.net應用程式的請求。
     executionTimeout:表示允許執行請求的最大時間限制，單位為秒
     maxRequestLength：指示 ASP.NET 支持的最大文件上傳大小。該限制可用於防止因用戶將大量文件傳遞到該伺服器而導致的拒絕服務攻擊。指定的大小以 KB 為單位。預設值為 4096 KB (4 MB)。

類似於C#中CommandTimeout 這個參數就是我們的執行時間超時值，如果太小就會引發執行失敗。

3.接下來就是對RS 的參數修改

a.設置站點設置-》常規

其中在RSDB中也可以設置這個值，參數為預設為600or1800。直接選擇不設置。

b.對於數據集的參數設置

首先在開發的時候就可以設置比如timeout時間。一般預設為0.然後這裡我做瞭如下修改

點擊出現問題的報表右鍵，然後選擇管理

註意這個地方是關鍵，對於這種共用數據源的數據集也要設置，選擇不對報表時間設置超時，或者指定超時時間。預設值我推測可能是15or30。這樣在wait時極有可能造成超時。

當然以上只是我的最後得出的推論，還需要註意一下幾點：

1.這期間修改了很多地方比如連接參數修改過connection timeout 參數，maxpool等

2.有一些地方的配置也需要註意，比如遠程連接中儘量採用IP地址作為連接對象，儘量不要使用伺服器縮寫名稱，這樣在DNS匹配的時候經常會影響，尤其是涉及到伺服器遷移的時候會出問題。其次會影響響應速度。有些時候設置需要清洗DNS的匹配。

3.伺服器端的防火牆配置，添加出站入站規則，一般預設埠1433，否則需要制定規則。

4.RS報表或者其他的連接方式

對於.net之類的微軟程式儘量選擇SQLServer 的數據源，這樣速度更快尤其是SSRS已經SSIS，如果非微軟數據源，可採用oledb等，但是註意升級資料庫，使用最新的驅動程式。

總結

       由於這個偶爾斷開的連接問題，讓我斷斷續續地看了好多資料但是真正解決起來才發現小的知識點很多，這裡也不過多展開了。報表這塊由於太占資源必須經常性的檢查優化。這期間監測網路是否暢通，資料庫環境是否出現問題等都是要做好自動化監控的。