本主題包含設定 Reporting Services 以在 SQL Server 2014 中使用 AlwaysOn 可用性群組 （AG） 的相關信息。 使用 Reporting Services 和 Always On 可用性群組的三個案例是報表數據源、報表伺服器資料庫和報表設計的資料庫。 這三種案例支援的功能和必要設定不同。
搭配 Reporting Services 數據源使用 AlwaysOn 可用性群組的主要優點是利用可讀取的次要複本作為報告數據源，同時次要複本會為主資料庫提供故障轉移。
如需 AlwaysOn 可用性群組的一般資訊，請參閱 SQL Server 2012 的 AlwaysOn 常見問題 （https://msdn.microsoft.com/sqlserver/gg508768)。
使用 Reporting Services 和 AlwaysOn 可用性群組的要求
若要搭配 SQL Server 2014 Reporting Services 使用 AlwaysOn 可用性群組，您必須下載並安裝適用於 .Net 3.5 SP1 的 Hotfix。 修補程式為 SQL Client 新增對 AG 功能與連接字串屬性 ApplicationIntent 和 MultiSubnetFailover 的支援。 如果主控報表伺服器的每部計算機上未安裝 Hotfix，則嘗試預覽報表的使用者會看到類似下列的錯誤訊息，並將錯誤訊息寫入報表伺服器追蹤記錄檔：
錯誤資訊： “關鍵詞不支援 'applicationintent'”
當您在 Reporting Services 連接字串中包含其中一個 Always On 可用性群組屬性，但伺服器無法辨識 屬性時，就會發生此訊息。 當您按下 Reporting Services 使用者介面中的 [測試連線] 按鈕，並在報表伺服器上啟用遠端錯誤時預覽報表時，就會看到已注意到的錯誤訊息。
如需了解必要的 Hotfix 詳情，請參閱 KB 2654347A Hotfix 為 .NET Framework 3.5 SP1 添加來自 SQL Server 2012 的 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 連接屬性，這些屬性會將報表查詢要求設定為使用次要複本進行只讀報告。 使用次要副本進行報告請求，將可減少讀寫型主要副本的負載。 下圖是使用ApplicationIntent=ReadOnly 設定 Reporting Services 數據源連接字串的三個複本 AG 組態範例。 在此範例中，報表查詢要求會傳送至次要複本，而不是主要複本。
以下是範例連接字串，其中 [AvailabilityGroupListenerName] 是建立複本時所設定的 接聽程式 DNS 名稱 ：
Data Source=[AvailabilityGroupListenerName];Initial Catalog = AdventureWorks2008R2; ApplicationIntent=ReadOnly
Reporting Services 使用者介面中的 [ 測試連線 ] 按鈕會驗證是否可以建立連線，但不會驗證 AG 組態。 例如，如果您在不屬於 AG 之伺服器的連接字串中包含 ApplicationIntent，則會忽略額外的參數，而且 [ 測試連接 ] 按鈕只會驗證可以建立與指定伺服器的連線。
視報表的建立方式和發佈方式而定，將決定您編輯連接字串的位置：
原生模式： 針對已發行至原生模式報表伺服器的共享數據源和報表使用報表管理員。
SharePoint 模式： 針對已發行至 SharePoint 伺服器的報表，使用文檔庫中的 SharePoint 組態頁面。
報表設計： SQL Server 報表產生器適用於 SQL Server 2012 或 SQL Server Data Tools (SSDT)，當您建立新報表時使用。 請參閱本主題中的「報告設計」一節以獲取更多資訊。
其他資源：
如需可用連接字串屬性的詳細資訊，請參閱 搭配 SQL Server Native Client 使用連接字串關鍵詞。
如需可用性群組接聽程式的詳細資訊，請參閱建立或設定可用性群組接聽程式（SQL Server）。
考慮事項： 次要副本通常會有從主要副本接收資料變更的延遲。 下列因素可能會影響主要和次要複本之間的更新延遲：
次要複本的數目。 延遲會隨著每個新增至組態的次要複本而增加。
主要和次要複本之間的地理位置和距離。 例如，如果次要複本位於不同的數據中心，而不是與主要複本在同一建築物中，則延遲通常會較大。
設定每個復本的可用性模式。 可用性模式會決定主要復本是否等候認可資料庫上的交易，直到次要複本將交易寫入磁碟為止。 如需詳細資訊，請參閱 AlwaysOn 可用性群組概觀（SQL Server）中的「可用性模式」一節。
使用唯讀的從屬副本做為 Reporting Services 資料來源時，請務必確保資料更新延遲能符合報表使用者的需求。
報表設計和可用性群組
在 SQL Server Report Builder for SQL Server 2012 或 SQL Server Data Tools （SSDT） 中設計報表時，用戶可以設定報表數據源連接字串，以包含 Always On 可用性群組所提供的新連接屬性。 新連接屬性的支援取決於用戶預覽報表的位置。
本機預覽： SQL Server 2012 和 SQL Server Data Tools 的 SQL Server 報表產生器 （SSDT） 會使用 .Net Framework 4.0，並支援 AlwaysOn 可用性群組連接字串屬性。
遠端或伺服器模式預覽： 如果在 SQL Server 2012 的 SQL Server 報表產生器中發行報表或使用預覽之後，您會看到類似下列的錯誤，表示您正在針對報表伺服器預覽報表，而且尚未在報表伺服器上安裝適用於 Always On 可用性群組的 .Net Framework 3.5 SP1 Hotfix。
錯誤資訊： “關鍵詞不支援 'applicationintent'”
報表伺服器資料庫和可用性群組
Reporting Services 針對搭配報表伺服器資料庫使用 AlwaysOn 可用性群組提供有限的支援。 報表伺服器資料庫可以在 AG 中設定為複本的一部分;不過，當故障轉移發生時，Reporting Services 不會自動為報表伺服器資料庫使用不同的複本。
手動動作或自定義自動化腳本必須用來完成故障轉移和復原。 在完成這些動作之前，報表伺服器的某些功能可能無法在 AlwaysOn 可用性群組故障轉移之後正確運作。
備註
規劃報表伺服器資料庫的故障轉移和災害復原時，建議您一律備份報表伺服器加密密鑰的複本。
SharePoint 原生模式之間的差異
本節摘要說明 SharePoint 模式與原生模式報表伺服器如何與 AlwaysOn 可用性群組互動之間的差異。
SharePoint 報表伺服器會為每個您所建立的 Reporting Services 服務應用程式建立 3 個資料庫。 當您建立服務應用程式時，SharePoint 管理中心會設定 SharePoint 模式中報表伺服器資料庫的連線。 資料庫的預設名稱包含與服務應用程式相關聯的 GUID。 以下是 SharePoint 模式報表伺服器的資料庫名稱範例：
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB
ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting
原生模式報表伺服器使用 2 個資料庫。 以下是原生模式報表伺服器的資料庫名稱範例：
報告伺服器
ReportServerTempDB
原生模式不支援或使用警示資料庫和相關功能。 您可以在 Reporting Services 組態管理員中設定原生模式報表伺服器。 針對 SharePoint 模式，您可以將服務應用程式資料庫名稱設定為您在 SharePoint 設定中建立的「用戶端存取點」名稱。 如需使用 Always On 可用性群組設定 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可用性群組故障轉移至次要複本之後，必須完成下列步驟：
停止主資料庫引擎裝載 Reporting Services 資料庫所使用的 SQL Agent 服務的實例。
在新的主要復本計算機上啟動 SQL Agent 服務。
停止報表伺服器服務。
如果報表伺服器處於原生模式，請使用 Reporting Services 組態管理員停止報表伺服器 Windows 伺服器。
如果報表伺服器已設定為 SharePoint 模式，請停止 SharePoint 管理中心的 Reporting Services 共用服務。
啟動報表伺服器服務或 Reporting Services SharePoint 服務。
確認報表可以針對新的主副本執行。
發生故障轉移時的報表伺服器行為
當報表伺服器資料庫發生故障轉移，而您已更新報表伺服器環境以使用新的主要複本時，故障轉移和復原過程會引發一些操作問題。 這些問題的影響會因故障轉移時報告服務的負載不同而有所變化。此外，Always On 可用性群組故障轉移至次要復本所需的時間，以及報表伺服器系統管理員更新報告環境以使用新的主要複本所需的時間，也會影響這些問題的影響程度。
背景處理的執行可能會多次發生，因為重試邏輯和報表伺服器無法在故障轉移期間將排程的工作標示為已完成。
通常會被觸發在故障轉移期間運行的背景處理將不會進行，因為 SQL Server Agent 將無法將資料寫入報表伺服器資料庫，且此資料不會同步到新的主要複本。
資料庫故障轉移完成之後，以及在報表伺服器服務重新啟動之後，SQL Server Agent 作業會自動重新建立。 在重新建立 SQL 代理程式作業之前，將不會處理任何與 SQL Server Agent 作業相關聯的背景執行。 這包括 Reporting Services 訂用帳戶、排程和快照。
另請參閱
SQL Server Native Client 支援高可用性、災害復原AlwaysOn 可用性群組 (SQL Server) 的入門使用連接字串關鍵字搭配 SQL Server Native Client使用連接字串關鍵字搭配 SQL Server Native ClientSQL Server Native Client 支援高可用性、災害復原關於用戶端連線存取可用性複本 (SQL Server)