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#部分将来可以详细讨论

720

30这两个值默认即可。

SSRS报表连接超时的问题_第1张图片

b. 查询超时时间尽量设置大一些,当然在一些环境下不能这么做比如频繁查询的,数据量较小的时候。对于我的报表系统而言,用的比较少且很多大的报表所以设定为30分钟。

SSRS报表连接超时的问题_第2张图片

2.修改web.config中的参数

SSRS报表连接超时的问题_第3张图片 

     httpRuntime是配置asp.net http运行时设置,以确定如何处理对asp.net应用程序的请求。 
     executionTimeout:表示允许执行请求的最大时间限制,单位为秒 
     maxRequestLength:指示 ASP.NET 支持的最大文件上载大小。该限制可用于防止因用户将大量文件传递到该服务器而导致的拒绝服务攻击。指定的大小以 KB 为单位。默认值为 4096 KB (4 MB)。

类似于C#中CommandTimeout 这个参数就是我们的执行时间超时值,如果太小就会引发执行失败。

3.接下来就是对RS 的参数修改

a.设置站点设置-》常规

SSRS报表连接超时的问题_第4张图片

其中在RSDB中也可以设置这个值,参数为默认为600or1800。直接选择不设置。

b.对于数据集的参数设置

首先在开发的时候就可以设置比如timeout时间。一般默认为0.然后这里我做了如下修改

SSRS报表连接超时的问题_第5张图片 点击出现问题的报表右键,然后选择管理

SSRS报表连接超时的问题_第6张图片

注意这个地方是关键,对于这种共享数据源的数据集也要设置,选择不对报表时间设置超时,或者指定超时时间。默认值我推测可能是15or30。这样在wait时极有可能造成超时。

当然以上只是我的最后得出的推论,还需要注意一下几点:

1.这期间修改了很多地方比如连接参数修改过connection timeout 参数,maxpool等

2.有一些地方的配置也需要注意,比如远程连接中尽量采用IP地址作为连接对象,尽量不要使用服务器缩写名称,这样在DNS匹配的时候经常会影响,尤其是涉及到服务器迁移的时候会出问题。其次会影响响应速度。有些时候设置需要清洗DNS的匹配。

3.服务器端的防火墙配置,添加出站入站规则,一般默认端口1433,否则需要制定规则。

4.RS报表或者其他的连接方式

image

对于.net之类的微软程序尽量选择SQLServer 的数据源,这样速度更快尤其是SSRS已经SSIS,如果非微软数据源,可采用oledb等,但是注意升级数据库,使用最新的驱动程序。

 

总结

       由于这个偶尔断开的连接问题,让我断断续续地看了好多资料但是真正解决起来才发现小的知识点很多,这里也不过多展开了。报表这块由于太占资源必须经常性的检查优化。这期间监测网络是否畅通,数据库环境是否出现问题等都是要做好自动化监控的。

你可能感兴趣的:(MSSql2005及新版本)