SQL Server 2008中报表服务功能浅介

　　报表服务是SQL Server Express Edition中一个重要功能，利用它可以辨别和解决影响SQL Server Express Edition报表服务功能和性能问题，从而可以实现报故障排除的效果。

　　对于大多数应用者来说报表服务是依赖于广泛的服务和软件组件，所以当其在辨别某个问题的根本原因(并提供一个解决方案)时将主要依赖于环境、交互的错误信息、日志或追踪文件的内容所提供的线索。通常情况下都是通过以下的方法来实现故障排除：

    ?评估主机操作系统的整个健壮性；

　  ?检查Internet Information Services、ASP.NET以及Reporting Services Web Services的配置和性能；

　　?检查SQL Server 实例和报表服务数据库的可操作性(这可能包括报表所依赖的数据源的优化)；

　　?改正报表服务器和报表管理器特定的配置错误或失败之处；

　　?Windows Event Logs 

    虽然你可以在系统日志中找到一些报表服务相关的项目(因为SQL Server报表服务功能是作为一个操作系统服务来使用的)，我们感兴趣的内容还是主要在应用程序日志中。可以根据它们显示为Report Server Windows Service或Report Manager的Source参数来分辨。一些更相关的事件包括报表服务器和报表管理器开启和关闭错误、配置变更(例如那些反映对RSReportServer.config文件所做的修改)、安全事件(潜在的对服务攻击的拒绝)和活动(与加密密钥相关的问题)事件、以及性能或日志记录问题(例如创建性能计算器或写到跟踪日志失败)。

　　?Reporting Services Trace Logs

    如果从应用程序事件日志中得不到任何结论，那么参照这些文件考虑更详细。它们位于Program Files\Microsoft SQL Server\InstanceName\LogFiles文件夹下(InstanceName是存放报表服务数据库的SQL Server Express Edition实例)，它们的名称是以合并它们的创建日期和时间的规范来命名的，它们包含关于Report Sever Windows服务工作器(ReportServerService_timestamp.log)和管理(ReportServerService_main_timestamp.log)线程的数据，以及跟踪由它的Web service(ReportServer_timestamp.log)和报表管理器(ReportServerWebApp_timestamp.log)所触发的单个事件。

    尽管有一个内置机制促进对它们的增长进行控制(强制一天至少创建一次新日志，限制它们小于32MB，并自动删除14天以前的旧日志)，但是对于报表服务相对较为活跃的情况你可能会遇到磁盘空间问题。为了避免这些，考虑调整日志的最大规模和它们的保留时间，或者降低日志记录的级别，通过修改被各个报表服务组件所使用的下面的配置文件中指定给DefaultTraceSwitch参数的值(0完全关闭跟踪，1记录异常和重启，2跟踪异常、重启和警告，3包括其它的状态信息，4代表详细模式，这只限于在排除故障期间临时使用)：

　　Report Server Windows service ? 在Microsoft SQL server\MSSQL.x\Reporting Services\Report Server\bin文件夹下的ReportingServicesService.exe。

　　Report Server Web service ? 在Microsoft SQL server\MSSQL.x\Reporting Services\Report Server\ReportServer文件夹下的Web.config。

　　Report Manager ? 在Microsoft SQL server\MSSQL.x\Reporting Services\Report Server\ReportManager 文件夹下的Web.config。

　　MSSQL.x代表本地SQL Server Express Edition Reporting Services实例。你也可以调整RSTrace参数的Components的值的设置，它决定了要跟踪的各个组件，以及它们相应的跟踪级别。

　　?Report Server Execution Log

    每次报表执行都被记录在Report Server 数据库中的dbo.ExecutionLog表中。在那里所存储的数据包括报表标识符、启动它的用户名、渲染格式(例如HTML、PDF或Excel)、参数、启动和结束时间、状态(成功或失败，带有相应的错误代码)、以及性能相关的统计(例如数据获取的时间、处理和渲染或总字节数和记录数)。虽然微软提供了示例Execution Log报表，但是它们的功能依赖于一个Integration Services包，而SQL Server 2005 Express Edition不支持它，所以如果你想查看它们的内容，你需要开发你自己定制的机制来以友好的格式展示它。

    记住，日志默认情况下每60天清理一次，虽然这个值可以通过使用SQL Server Reporting Services Site Settings页面上的Remove log entries older than this number of days文本框来修改。如果需要的话，还可以关闭报表执行日志记录，通过取消同一位置的Enable report execution logging复选框的勾选。

　　?IIS Server Logs和 Failed Request Tracing

    虽然不是专用于报表服务的，但是由存放报表服务虚拟目录的Internet Information Services站点所生成的日志记录的项可以指出连接性或应用程序池相关的错误。配置过程根据IIS的版本而有所不同。对于IIS5和6(运行于Windows XP或Windows Server 2003操作系统)，这是通过报表服务站点的Properties 对话框中Web Site标签页上的Enable Logging复选框来完成的，在这里你可以指定Active log format以及General Properties(例如New Log Time Period 或 Log file directory)和Extended Properties(具体确定你想记录哪些数据)。使用Vista和 IIS 7的话，你首先需要通过Turn Windows features on or off控制面板applet(从这里导向World Wide Web Services节点的Health Diagnostics子节点)使想要的日志记录和跟踪选项可用。当这个步骤完成时，在Internet Information Services (IIS) Manager中在Web site级别添加Failed Request Tracing Rules。

　　?Setup Logs

    在SQL Server安装程序的每次调用过程中创建的，存储在Program Files\Microsoft SQL Server\90\Setup Bootstrap\LOG目录下。Summary.txt存在于它的根目录下，提供关于每一个SQL Server 2005 Express Edition本地安装的产品(例如支持文件、SQL Server Native Client、SQL Server Management Studio Express或Reporting Services)的基本概况(名称和版本、安装结果、以及一个相应的、产品特定的日志文件名称)。如果失败了，你可以检查参考文件(它的名称是以SQLSetupxxxx_hostname_productname.log的形式，xxxx是一个连续的整数，它是被自动分配给每个新安装的，hostname表示本地计算机的名称，productname是被安装的产品名称，例如对于Reporting Services它的productname就是RS)。

　　?Windows Performance Logs

    当在数据获取以及报表生成或渲染过程中遇到抛出的错误时，你应该检查Reporting Services所依赖的各个组件的执行。这些一般包括操作系统资源(例如内存或处理器使用级别、磁盘分页、读和写队列的长度)、IIS和 ASP.NET、以及SQL Server和Reporting Services特定的计数器。(但是注意，这个延迟也可能是由于查询的组织形式不好，或是数据库级别的错误配置，例如非最优的索引)。辨别这种问题的发生需要使用(取决于操作系统)系统和性能监控器(或更多情况下是Task Manager)、计数器和跟踪日志或数据收集器，以及SQL Server特定的执行故障排除工具。