本主题包含有关在 SQL Server 2014 中将 Reporting Services 配置为使用 Always On 可用性组（AG）的信息。 使用 Reporting Services 和 Always On 可用性组的三种方案分别是用于报表数据源的数据库、报表服务器数据库和报表设计。 这三种方案支持的功能和所需的配置各不相同。
使用 Always On 可用性组与 Reporting Services 数据源结合的一个关键好处是，可以将可读的辅助副本用作报告数据源，同时，这些辅助副本为主数据库提供故障转移功能。
有关 AlwaysOn 可用性组的一般信息，请参阅 SQL Server 2012 的 AlwaysOn 常见问题解答（https://msdn.microsoft.com/sqlserver/gg508768)）。
使用 Reporting Services 和 AlwaysOn 可用性组的要求
若要将 AlwaysOn 可用性组与 SQL Server 2014 Reporting Services 配合使用，需要下载并安装适用于 .Net 3.5 SP1 的修补程序。 该修补程序添加对 SQL Client for AG 功能的支持以及对连接字符串属性 ApplicationIntent 和 MultiSubnetFailover的支持。 如果未在承载报表服务器的每台计算机上安装修补程序，则尝试预览报表的用户将看到如下所示的错误消息，错误消息将写入报表服务器跟踪日志：
错误消息： “关键字不受支持的 "applicationintent"”
如果在 Reporting Services 连接字符串中包含某个 AlwaysOn 可用性组属性，但服务器无法识别该属性，则会出现该消息。 当您在 Reporting Services 用户界面中单击“测试连接”按钮时，以及在报表服务器上启用远程错误的情况下预览报表时，将显示已记录的错误消息。
有关所需修补程序的详细信息，请参阅 KB 2654347A 修补程序引入了对从 SQL Server 2012 到 .NET Framework 3.5 SP1 的 AlwaysOn 功能的支持。
有关其他 AlwaysOn 可用性组要求的信息，请参阅 AlwaysOn 可用性组（SQL Server）的先决条件、限制和建议。
注释
不支持 Reporting Services 配置文件（如 RSreportserver.config）作为 Always On 可用性组功能的一部分。 如果手动更改某一报表服务器上的配置文件，将需要手动更新副本。
报表数据源和可用性组
基于 AlwaysOn 可用性组的 Reporting Services 数据源的行为可能因管理员配置 AG 环境的方式而异。
若要对报表数据源使用 Always On 可用性组，需要配置报表数据源连接字符串以使用可用性组 侦听器 DNS 名称。 支持以下数据源：
使用 SQL Native Client 的 ODBC 数据源。
SQL 客户端，.Net 修补程序已经应用于报表服务器。
连接字符串还可以包含新的 AlwaysOn 连接属性，这些属性将报表查询请求配置为使用辅助副本进行只读报告。 对报告请求使用次要副本可以减少读写主副本上的负载。 下图显示包含三个副本 AG 配置的示例，其中 Reporting Services 数据源连接字符串已使用 ApplicationIntent=ReadOnly 配置。 在此示例中，报表查询请求将发送到次要副本，而不是主要副本。
以下是示例连接字符串，其中 [AvailabilityGroupListenerName] 为创建副本时配置的 侦听器 DNS 名称 ：
Data Source=[AvailabilityGroupListenerName];Initial Catalog = AdventureWorks2008R2; ApplicationIntent=ReadOnly
Reporting Services 用户界面中的 “测试连接 ”按钮将验证是否可以建立连接，但不会验证 AG 配置。 例如，如果将 ApplicationIntent 包含在不属于 AG 的服务器连接字符串中，则会忽略额外的参数，并且 “测试连接 ”按钮将仅验证可以建立到指定服务器的连接。
创建和发布报表的方式将决定您在何处编辑连接字符串：
本机模式： 对已发布到本机模式报表服务器的共享数据源和报表使用报表管理器。
SharePoint 模式： 对于已发布到 SharePoint 服务器的报表，使用文档库内的 SharePoint 配置页。
报表设计： 当创建新报表时，可使用 SQL Server 2012 的 SQL Server 报表生成器或 SQL Server 数据工具（SSDT）。 请参阅本主题中的“报表设计”部分或详细信息。
其他资源：
有关可用连接字符串属性的详细信息，请参阅 Using Connection String Keywords with SQL Server Native Client。
有关可用性组侦听器的详细信息，请参阅创建或配置可用性组侦听器 (SQL Server)。
注意事项： 在从主要副本接收数据更改时，次要副本一般会有延迟。 以下因素可能影响主副本和辅助副本之间的更新滞后时间：
辅助副本数目。 向配置中每增加一个辅助副本，延迟时间将增加。
地理位置以及主副本和辅助副本之间的距离。 例如，辅助副本位于单独的数据中心与它们位于与主副本相同的大楼中相比，前者的延迟时间通常更长。
每个副本的可用性模式的配置。 可用性模式确定主副本是否在辅助副本将事务写入磁盘之前，等待提交数据库上的事务。 有关详细信息，请参阅 AlwaysOn 可用性组概述（SQL Server）的“可用性模式”部分。
将只读辅助数据库用作 Reporting Services 数据源时，请务必确保数据更新延迟满足报表用户的需求。
报表设计和可用性组
在 SQL Server Report Builder for SQL Server 2012 中设计报表或 SQL Server Data Tools （SSDT）中的报表项目时，用户可以配置报表数据源连接字符串以包含 AlwaysOn 可用性组提供的新连接属性。 对连接属性的支持取决于用户在何处预览报表。
本地预览版： SQL Server Report Builder for SQL Server 2012 和 SQL Server Data Tools （SSDT） 使用 .Net framework 4.0 并支持 AlwaysOn 可用性组连接字符串属性。
远程或服务器模式预览： 如果将报表发布到报表服务器或使用 SQL Server Report Builder for SQL Server 2012 中的预览版，则会看到类似于以下内容的错误，表明你正在针对报表服务器预览报表，并且尚未在报表服务器上安装适用于 AlwaysOn 可用性组的 .Net Framework 3.5 SP1 修补程序。
错误消息： “关键字不受支持的 "applicationintent"”
报表服务器数据库和可用性组
Reporting Services 为将 AlwaysOn 可用性组与报表服务器数据库配合使用提供了有限的支持。 可以在 AG 中将报表服务器数据库配置为副本的一部分;但是，发生故障转移时，Reporting Services 不会自动对报表服务器数据库使用不同的副本。
需要使用手动操作或自定义自动化脚本来完成故障转移和恢复。 在完成这些操作之前，Always On 可用性组故障转移后，报表服务器的某些功能可能无法正常工作。
注释
规划报表服务器数据库的故障转移和灾难恢复时，建议您始终备份报表服务器加密密钥的副本。
SharePoint 模式和本机模式之间的区别
本部分总结了 SharePoint 模式与本机模式报表服务器如何与 AlwaysOn 可用性组交互之间的差异。
SharePoint 报表服务器将为创建的每个 Reporting Services 服务应用程序创建 3 个数据库。 创建服务应用程序时，SharePoint 模式下与报表服务器数据库的连接在 SharePoint 管理中心中配置。 这些数据库的默认名称包含与服务应用程序相关联的 GUID。 以下是 SharePoint 模式报表服务器的示例数据库名称：
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting
本机模式报表服务器使用 2 个数据库。 以下是本机模式报表服务器的示例数据库名称：
ReportServer
ReportServerTempDB
本机模式不支持或使用警报数据库和相关功能。 在 Reporting Services 配置管理器中配置本机模式的报表服务器。 对于 SharePoint 模式，请将服务应用程序数据库名称配置为作为 SharePoint 配置的一部分创建的“客户端访问点”的名称。 有关使用 AlwaysOn 可用性组配置 SharePoint 的详细信息，请参阅 配置和管理 SharePoint Server 的 SQL Server 可用性组（https://go.microsoft.com/fwlink/?LinkId=245165)）。
注释
SharePoint 模式的报表服务器使用 Reporting Services 服务应用程序数据库和 SharePoint 内容数据库之间的同步过程。 将报表服务器数据库和内容数据库一起维护很重要。 您应考虑在同一可用性组中配置它们以便它们作为一个整体进行故障转移和恢复。 请考虑以下方案：
- 您还原或故障转移到一个内容数据库副本，该数据库未收到与报表服务器数据库所收到内容相同的最近更新。
- Reporting Services 同步过程将检测内容数据库中项列表与报表服务器数据库中项列表的差异。
- 同步过程将删除或更新内容数据库中的项。
为可用性组准备报表服务器数据库
以下是准备报表服务器数据库并将其添加到 AlwaysOn 可用性组的基本步骤：
创建可用性组并配置“侦听器 DNS 名称” 。
主要副本： 将报表服务器数据库配置为单个可用性组的一部分，并创建包含所有报表服务器数据库的主要副本。
次要副本： 创建一个或多个次要副本。 将数据库从主副本复制到辅助副本的常用方法为使用“RESTORE WITH NORECOVERY”将数据库恢复到每个辅助副本。 有关创建辅助副本和验证数据同步是否正常工作的详细信息，请参阅 AlwaysOn 辅助数据库（SQL Server）上的启动数据移动。
报表服务器凭据： 需要在针对主要副本创建的次要副本上，创建相应的报表服务器凭据。 确切的步骤取决于你在 Reporting Services 环境中使用的身份验证类型;Window Reporting Services 服务帐户、Windows 用户帐户或 SQL Server 身份验证。 有关详细信息，请参阅配置报表服务器数据库连接（SSRS 配置管理器）
更新数据库连接以使用 Lister DNS 名称。 对于本机模式的报表服务器，在 Reporting Services 配置管理器中更改 “报表服务器数据库名称”。 对于 SharePoint 模式，为 Reporting Services 服务应用程序更改“数据库服务器名称”。
完成报表服务器数据库的灾难恢复所需的步骤
在 AlwaysOn 可用性组故障转移到次要副本后，需要完成以下步骤：
停止 SQL 代理服务实例，该实例由托管 Reporting Services 数据库的主数据库引擎使用。
在作为新主副本的计算机上启动 SQL 代理服务。
停止报表服务器服务。
如果报表服务器处于本机模式，则使用 Reporting Services 配置管理器停止报表服务器的 Windows 服务器。
如果将报表服务器配置为 SharePoint 模式，请在 SharePoint 管理中心中停止 Reporting Services 共享服务。
启动报表服务器服务或 Reporting Services SharePoint 服务。
验证报表可以针对新主副本运行。
发生故障转移时的报表服务器行为
当报表服务器数据库发生故障转移且您已更新该报表服务器环境以使用新主副本时，故障转移和恢复过程中会出现一些操作问题。 这些问题的影响将因故障转移时的 Reporting Services 负载以及 AlwaysOn 可用性组故障转移到次要副本所花费的时间长度以及报表服务器管理员更新报告环境以使用新的主副本所需的时间而异。
由于重试逻辑和报表服务器无法在故障转移期间将预定工作标记为“已完成”，可能多次执行后台处理。
不会执行通常在故障转移期间触发的后台处理，因为 SQL Server 代理将无法将数据写入报表服务器数据库，并且此数据不会同步到新的主副本。
数据库故障转移完成后和报表服务器服务重新启动后，将自动重新创建 SQL Server 代理作业。 在重新创建 SQL 代理作业之前，不会处理与 SQL Server 代理作业关联的任何后台执行。 这包括报告服务订阅、计划和快照。
另请参阅
SQL Server Native Client支持高可用性，灾难恢复AlwaysOn可用性组（SQL Server）入门指南：AlwaysOn可用性组（SQL Server）使用连接字符串关键词与SQL Server Native ClientSQL Server Native Client支持高可用性，灾难恢复关于客户端连接可访问性副本的说明（SQL Server）