Reporting Services 與 AlwaysOn 可用性群組 (SQL Server)

  • 發行項

適用於：SQL Server

此文章包含如何設定 Reporting Services 以在 SQL Server 中使用 Always On 可用性群組 (AG) 的相關資訊。 使用 Reporting Services 與 Always On 可用性群組的三種案例包括報表資料來源的資料庫、報表伺服器資料庫以及報表設計。 這三種案例的支援功能和必要組態有所不同。

搭配 Reporting Services 資料來源使用 Always On 可用性群組的主要優點是能夠使用可讀取次要複本作為報表資料來源，同時次要複本可針對主要資料庫提供容錯移轉。

如需有關 Always On 可用性群組的一般資訊，請參閱 SQL Server 2012 的 Always On 常見問題集 (../../../sql-server/index.yml)。

使用 Reporting Services 和 AlwaysOn 可用性群組的需求

SQL Server Reporting Services 與 Power BI 報表伺服器會使用 .NET Framework 4.0，並支援 Always On 可用性群組連接字串屬性以便搭配資料來源使用。

若要搭配 Reporting Services 2014 與更舊版本使用 Always On 可用性群組，您需要下載並安裝 .NET 3.5 SP1 的 Hotfix。 此 Hotfix 會加入 SQL 用戶端對於 AG 功能的支援，以及連接字串屬性 ApplicationIntent 和 MultiSubnetFailover的支援。 如果裝載報表伺服器的每部電腦沒有安裝此 Hotfix，則嘗試預覽報表的使用者將會看見類似下面的錯誤訊息，而且該錯誤訊息將寫入報表伺服器追蹤記錄：

錯誤訊息： 「不支援關鍵字 'applicationintent'」

當您在 Reporting Services 連接字串中加入其中一個 Always On 可用性群組屬性，但是伺服器無法辨識該屬性時，就會出現此訊息。 如果報表伺服器已啟用遠端錯誤，當您在 Reporting Services 使用者介面中選取「測試連線」按鈕以及在預覽報表時，就會看到上述錯誤訊息。

如需有關必要 Hotfix 的詳細資訊，請參閱 KB 2654347A hotfix introduces support for the AlwaysOn features from SQL Server 2012 to the .NET Framework 3.5 SP1 (KB 2654347A Hotfix 從 SQL Server 2012 將 AlwaysOn 功能支援引進 .NET Framework 3.5 SP1 中)。

如需其他 Always On 可用性群組需求的相關資訊，請參閱 Always On 可用性群組的必要條件、限制和建議 (SQL Server) (部分機器翻譯)。

注意

Always On 可用性群組功能不支援 Reporting Services 設定檔，例如 RSreportserver.config。 如果您對其中一個報表伺服器的組態檔進行手動變更，就必須手動更新複本。

報表資料來源和可用性群組

以 Always On 可用性群組為基礎之 Reporting Services 資料來源的行為可能會因為系統管理員設定 AG 環境的方式而有所不同。

若要針對報表資料來源使用 Always On 可用性群組，您必須將報表資料來源連接字串設定為使用可用性群組的「接聽程式 DNS 名稱」。 支援的資料來源如下：

  • 使用 SQL Native Client 的 ODBC 資料來源。

  • SQL 用戶端 (已將 .NET Hotfix 套用至報表伺服器)。

連接字串也可以包含新的 AlwaysOn 連接屬性，以便將報表查詢要求設定為使用唯讀報表的次要複本。 將次要複本用於報表要求可降低讀寫主要複本的負載。 下圖是三個複本 AG 設定的範例，其中 Reporting Services 資料來源連接字串已經使用 ApplicationIntent=ReadOnly 進行設定。 在此範例中，報表查詢要求會傳送至次要複本而非主要複本。

下面是連接字串範例，其中 [AvailabilityGroupListenerName] 是建立複本時所設定的 Listener DNS Name ：

Data Source=[AvailabilityGroupListenerName];Initial Catalog = AdventureWorks2022; ApplicationIntent=ReadOnly

Reporting Services 使用者介面中的測試連線按鈕將會驗證是否能夠建立連線，但是不會驗證 AG 設定。 例如，如果您在不屬於 AG 一部分之伺服器的連接字串中加入 ApplicationIntent，系統就會忽略額外的參數，而且測試連線按鈕只會驗證是否能夠建立指定之伺服器的連接。

報表的建立和發行方式將會決定您可以編輯連接字串的位置：

  • 原生模式：針對已經發佈至原生模式報表伺服器的共用資料來源與報表，請使用入口網站。

  • SharePoint 模式： 您可以針對已經發行至 SharePoint 伺服器的報表使用文件庫中的 SharePoint 設定頁面。

  • 報表設計：建立新報表時的報表產生器或 SQL Server Data Tools (SSDT)。 如需詳細資訊，請參閱本文章的「報表設計」一節。

其他資源：

考量因素： 接收來自主要複本的資料變更時，次要複本通常會發生延遲。 下列因素可能會影響主要與次要複本之間的更新延遲：

  • 次要複本的數目。 延遲會隨著加入至組態的每個次要複本而增加。

  • 主要與次要複本之間的地理位置和距離。 例如，如果次要複本與主要複本位於不同的資料中心，其延遲通常會比次要複本與主要複本位於相同建築物的延遲要長。

  • 每個複本之可用性模式的組態。 可用性模式會決定在次要複本將交易寫入磁碟之前，主要複本是否要等候認可資料庫上的交易。 如需詳細資訊，請參閱 Always On 可用性群組概觀 (SQL Server) (部分機器翻譯) 中的＜可用性模式＞一節。

使用唯讀次要複本作為 Reporting Services 資料來源時，請務必確定資料更新延遲符合報表使用者的需求。

報表設計和可用性群組

在報表產生器中設計報表或在 SQL Server Data Tools (SSDT) 中設計報表專案時，使用者可以將報表資料來源連接字串設定為包含 Always On 可用性群組所提供的新連接屬性。 新連接屬性的支援主要取決於使用者預覽報表的位置。

  • 本機預覽：報表產生器與 SQL Server Data Tools (SSDT) 使用 .NET Framework 4.0，並支援 Always On 可用性群組連接字串屬性。

  • 遠端或伺服器模式預覽：如果將報表發佈至報表伺服器或在報表伺服器中使用預覽功能之後，您看到類似下面的錯誤，就表示您正在根據報表伺服器預覽報表，而且報表伺服器尚未針對 Always On 可用性群組安裝 .NET Framework 3.5 SP1 Hotfix。

錯誤訊息： 「不支援關鍵字 'applicationintent'」

報表伺服器資料庫和可用性群組

Reporting Services 與 Power BI 報表伺服器針對搭配報表伺服器資料庫使用 Always On 可用性群組，提供有限的支援。 您可以在 AG 中將報表伺服器資料庫設定為複本的一部分，但在容錯移轉時，Reporting Services 不會自動針對報表伺服器資料庫使用不同的複本。 不支援搭配報表伺服器資料庫使用 MultiSubnetFailover。

您必須使用手動操作或自訂自動化指令碼，才能完成容錯移轉和復原。 完成這些動作之前，報表伺服器的某些功能在 Always On 可用性群組容錯移轉之後可能無法正確運作。

注意

針對報表伺服器資料庫規劃容錯移轉和災害復原時，建議您一定要備份報表伺服器加密金鑰的複本。

SharePoint 原生模式之間的差異

此節將摘要說明 SharePoint 模式及原生模式報表伺服器與 Always On 可用性群組互動方式的差異。

SharePoint 報表伺服器會針對您所建立的每個 Reporting Services 服務應用程式，建立 3 個資料庫。 當您建立服務應用程式時，會在 SharePoint 管理中心內設定 SharePoint 模式報表伺服器資料庫的連接。 資料庫的預設名稱包含關聯到服務應用程式的 GUID。 以下是 SharePoint 模式報表伺服器的範例資料庫名稱：

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6TempDB

  • ReportingService_85c08ac3c8e64d3cb400ad06ed5da5d6_Alerting

原生模式報表伺服器會使用 2 個資料庫。 以下是原生模式報表伺服器的範例資料庫名稱：

  • ReportServer

  • ReportServerTempDB

原生模式不支援或使用警示資料庫及相關功能。 您可以在 Reporting Services 組態管理員中設定原生模式報表伺服器。 若為 SharePoint 模式，您可以將服務應用程式資料庫名稱設定為 SharePoint 設定期間所建立的「用戶端存取點」名稱。 如需有關搭配 Always On 可用性群組設定 SharePoint 的詳細資訊，請參閱設定和管理 SharePoint Server 的 SQL Server 可用性群組 (/previous-versions/office/sharepoint-server-2010/hh913923(v=office.14)) (英文)。

注意

SharePoint 模式報表伺服器會在 Reporting Services 服務應用程式資料庫與 SharePoint 內容資料庫之間使用同步處理流程。 請務必一起維護報表伺服器資料庫和內容資料庫。 您應該考慮將它們設定在相同的可用性群組中，以便一起容錯移轉和復原。 請考慮下列案例：

  • 您還原或容錯移轉至內容資料庫的複本，但是該資料庫尚未收到報表伺服器資料庫已經收到的相同近期更新。
  • Reporting Services 同步處理流程將會偵測到內容資料庫與報表伺服器資料庫的項目清單之間存在差異。
  • 同步處理程序將會刪除或更新內容資料庫中的項目。

針對可用性群組準備報表伺服器資料庫

以下是準備將報表伺服器資料庫新增至 Always On 可用性群組的基本步驟：

  • 建立您的可用性群組並且設定 「接聽程式 DNS 名稱」 (Listener DNS Name)。

  • 主要複本： 將報表伺服器資料庫設定為單一可用性群組的一部分，並且建立包含所有報表伺服器資料庫的主要複本。

  • 次要複本： 建立一或多個次要複本。 將資料庫從主要複本複製到次要複本的常見方法是使用 'RESTORE WITH NORECOVERY'，將資料庫還原至每個次要複本。 如需建立次要複本以及驗證資料同步處理是否運作的詳細資訊，請參閱於 AlwaysOn 次要資料庫啟動資料移動 (SQL Server) (部分機器翻譯)。

  • 報表伺服器認證： 您必須在次要與主要複本上建立適當的報表伺服器認證。 確切步驟主要取決於您在 Reporting Services 環境中使用的驗證類型：Windows Reporting Services 服務帳戶、Windows 使用者帳戶或 SQL Server 驗證。 如需詳細資訊，請參閱設定報表伺服器資料庫連接 (SSRS 組態管理員) (部分機器翻譯)

  • 將資料庫連接更新為使用接聽程式 DNS 名稱。 針對原生模式報表伺服器，請在 Reporting Services 組態管理員中變更 [報表伺服器資料庫名稱]。 針對 SharePoint 模式，請為 Reporting Services 服務應用程式變更 [資料庫伺服器名稱]。

完成報表伺服器資料庫之災害復原的步驟

您必須在 Always On 可用性群組容錯移轉至次要複本之後完成下列步驟：

  1. 停止裝載 Reporting Services 資料庫之主要資料庫引擎所使用的 SQL Agent 服務執行個體。

  2. 在成為新主要複本的電腦上啟動 SQL 代理程式服務。

  3. 停止報表伺服器服務。

    如果報表伺服器處於原生模式，請使用 Reporting Services 組態管理員停止報表伺服器 Windows 伺服器。

    如果報表伺服器設定為 SharePoint 模式，請在 SharePoint 管理中心內停止 Reporting Services 共用服務。

  4. 啟動報表伺服器服務或 Reporting Services SharePoint 服務。

  5. 確認報表可以根據新的主要複本執行。

進行容錯移轉時的報表伺服器行為

當報表伺服器資料庫容錯移轉，而且您已經將報表伺服器環境更新為使用新的主要複本時，容錯移轉和復原程序會產生一些作業問題。 這些問題的影響會因下列條件而異：容錯移轉時的 Reporting Services 負載、Always On 可用性群組容錯移轉至次要複本所需的時間長度，以及報表伺服器管理員將報表環境更新為使用新主要複本所需的時間長度。

  • 由於重試邏輯以及報表伺服器無法在容錯移轉期間將排程的工作標記為已完成，因此背景處理的執行可能會發生一次以上。

  • 通常已經觸發要在容錯移轉期間執行的背景處理執行將不會發生，因為 SQL Server Agent 無法將資料寫入報表伺服器資料庫中，而且這項資料不會同步處理至新的主要複本。

  • 在資料庫容錯移轉完成而且報表伺服器服務重新啟動之後，系統將會自動重新建立 SQL Server Agent 作業。 在建立 SQL 代理程式作業之前，系統將不會處理任何與 SQL Server Agent 作業相關聯的背景執行。 這包括 Reporting Services 訂用帳戶、排程，以及快照。

另請參閱