SQL Server 設計考量

發行項
11/06/2024

System Center Operations Manager 依賴Microsoft SQL Server 來支援其作業、數據倉儲和 ACS 稽核資料庫。這些資料庫很重要，會在管理群組中部署第一部管理伺服器或 ACS 收集器期間建立。

在實驗室環境或 Operations Manager 的小規模部署中，SQL Server 可以共置在管理群組中的第一部管理伺服器上。

在中型到企業級的分散式部署中，SQL Server 實例應該位於專用的獨立伺服器或 SQL Server 高可用性設定中。不論是哪一種情況，SQL Server 都必須已經存在且可供存取，才能開始安裝第一部管理伺服器或 ACS 收集器。

不建議從具有其他應用程序資料庫的 SQL 實例使用 Operations Manager 資料庫，以避免 I/O 和其他硬體資源限制發生任何潛在問題。

重要

Operations Manager 不支援 SQL 平臺即服務（PaaS）實例，包括 Azure SQL 受控執行個體或 Amazon Relational Database Service （AWS RDS）等產品。請使用安裝在 Windows 機器上的 SQL Server 實例。唯一的例外狀況是在 Azure 監視器 SCOM 受控執行個體內，它會使用 Azure SQL MI，且無法重新設定。

SQL Server 需求

支援下列版本的 SQL Server Enterprise 和 Standard Edition，以裝載 Reporting Server、Operational、Data Warehouse 和 ACS 資料庫的現有 System Center Operations Manager 版本：

SQL Server 2019 含最低累積更新 8 （CU8） 或更新版本更新，如下所示
SQL Server 2016 和這裡提供的最新更新

SQL Server 2022 含最低累積更新 11 （CU11） 或更新版本更新，如下所示
SQL Server 2019 含最低累積更新 8 （CU8） 或更新版本更新，如下所示
SQL Server 2017 具有最新的可用更新，如下所示

SQL Server 2017 和累積更新，如這裏詳述
SQL Server 2016 和 Service Pack，如這裡所述

升級 SQL Server 之前，請參閱 2017+ 的升級資訊，以及 SQL 2019 的升級資訊。

下列版本的 SQL Server Enterprise 和 Standard Edition 支援 System Center 2016 - Operations Manager 的全新或現有安裝，以裝載 Reporting Server、Operational、Data Warehouse 和 ACS 資料庫：

SQL Server 2016 和這裡提供的最新更新
SQL Server 2014 和這裡提供的最新更新
SQL Server 2012 和這裡提供的最新更新

SQL Server 驅動程式

OLE DB 和 ODBC SQL Server 驅動程式必須安裝在所有管理伺服器和 Web 控制台伺服器上，因為這些元件會直接與資料庫介面，而且這些驅動程式允許 API 層級存取 SQL。

建議使用加密的 SQL Server 連線;這樣做時，您必須安裝最新版的 SQL 驅動程式：

Microsoft OLE DB Driver 最新版本。
Microsoft ODBC 驅動程式最新版本。

如需設定 SQL 連線加密的詳細資訊，請參閱這裡：設定 SQL Server 資料庫引擎來加密連線

如果未使用加密的 SQL 連線，請使用舊版的 SQL 驅動程式，但不會強制執行加密：

Microsoft ODBC Driver 17.10.6 版。
Microsoft OLE DB Driver 18.7.4 版。

SQL Server 更新

支援 Operations Manager 基礎結構的下列每個 SQL Server 元件都必須位於相同的 SQL Server 主要版本：

裝載任何 Operations Manager 資料庫的 SQL Server 資料庫引擎實例，包括：
- OperationManager
- OperationManagerDW
- SSRS 資料庫 ReportServer 和 ReportServerTempDB
SQL Server Reporting Services （SSRS）實例。

SQL Server 驗證模式

根據預設，SQL 會在混合模式驗證組態中運作。不過，Operations Manager 只會利用 Windows 驗證來與 SQL Server 通訊。如果保留預設，如果沒有任何本機帳戶具有 db_owner 角色，SQL 混合模式驗證設定仍會運作。已知具有角色的 db_owner 本機帳戶會導致 Operations Manager 的問題。

強烈建議在安裝產品之前，先從所有本機帳戶移除 db_owner 角色，並在安裝之後不要將角色新增 db_owner 至任何本機帳戶。

其他考量

其他硬體和軟體考慮適用於您的設計規劃：

建議使用NTFS檔格式的SQL磁碟。
作業和數據倉儲資料庫必須至少有 1 GB 的可用磁碟空間，這會在資料庫建立時強制執行。請記住，在設定之後，資料庫的磁碟使用率會大幅增加，確保在此基底需求之上有足夠的可用磁碟空間。
需要 .NET Framework 4。
Operations Manager 2022 支援 .NET Framework 4.8。
Windows Server Core 不支援報表伺服器。
SQL Server 定序設定必須是其中一個支援的類型，如 SQL Server 定序設定中所述。
裝載任何 Operations Manager 資料庫的所有 SQL Server 資料庫引擎實例都需要 SQL Server 全文搜索。
Operations Manager 資料庫元件支援的 Windows Server 安裝選項（Server Core、伺服器具有桌面體驗的伺服器和 Nano Server）是以 SQL Server 支援哪些安裝選項為基礎。

如需詳細資訊，請參閱 SQL Server 安裝和規劃檔下的硬體和軟體需求一節：規劃 SQL Server 安裝

SQL Server 定序設定

System Center Operations Manager 支持下列 SQL Server 和 Windows 定序。

注意

若要避免比較或複製作業時發生任何相容性問題，建議您針對 SQL 和 Operations Manager DB 使用相同的定序。

SQL Server 定序

SQL_Latin1_General_CP1_CI_AS

Windows 定序

Latin1_General_100_CI_AS
French_CI_AS
French_100_CI_AS
Cyrillic_General_CI_AS
Chinese_PRC_CI_AS
Chinese_Simplified_Pinyin_100_CI_AS
Chinese_Traditional_Stroke_Count_100_CI_AS
Japanese_CI_AS
Japanese_XJIS_100_CI_AS
Traditional_Spanish_CI_AS
Modern_Spanish_100_CI_AS
Latin1_General_CI_AS
Cyrillic_General_100_CI_AS
Korean_100_CI_AS
Czech_100_CI_AS
Hungarian_100_CI_AS
Polish_100_CI_AS
Finnish_Swedish_100_CI_AS

如果您的 SQL Server 實例未使用先前所列的其中一個支援定序進行設定，則執行 Operations Manager 安裝程式的新設定會失敗。不過，就地升級會順利完成。

防火牆設定

Operations Manager 相依於 SQL Server 來裝載其資料庫和報告平臺，以分析和呈現歷程記錄作業數據。管理伺服器、作業和 Web 控制台角色必須能夠成功與 SQL Server 通訊，請務必瞭解通訊路徑和埠，才能正確設定環境。

如果設計使用 SQL Always On 可用性群組的分散式部署，則需要在防火牆安全性策略中包含額外的防火牆組態設定。

下表識別 SQL Server 所需的防火牆埠，以便管理伺服器與資料庫通訊：

案例	連接埠	方向	Operations Manager 角色
裝載 Operations Manager 資料庫的 SQL Server	TCP 1433 *	傳入	管理伺服器和 Web 控制台（適用於 Application Advisor 和 Application Diagnostics）
SQL Server Browser 服務	UDP 1434	傳入	Management 伺服器
SQL Server 專用管理員連線	TCP 1434	傳入	Management 伺服器
SQL Server 所使用的其他埠 - Microsoft遠端過程呼叫（MS RPC） - Windows Management Instrumentation （WMI） - Microsoft 分散式交易協調器（MS DTC）	TCP 135	傳入	Management 伺服器
SQL Server Always On 可用性群組接聽程式	系統管理員設定的埠	傳入	Management 伺服器
裝載 Operations Manager 報表伺服器的 SQL Server Reporting Services	TCP 80 （預設）/443 （SSL）	傳入	管理伺服器和 Operations 控制台

注意

雖然 TCP 1433 是資料庫引擎之預設實例的標準埠，但當您在獨立 SQL Server 上建立具名實例或已部署 SQL Always On 可用性群組時，會定義自定義埠並加以記載以供參考，以便正確設定防火牆，並在安裝期間輸入此資訊。

如需 SQL Server 防火牆需求的詳細概觀，請參閱設定 Windows 防火牆以允許 SQL Server 存取。

容量和記憶體考慮

Operations Manager 資料庫

Operations Manager 資料庫是 SQL Server 資料庫，其中包含 Operations Manager 進行日常監視所需的所有數據。資料庫伺服器的大小調整和設定對於管理群組的整體效能至關重要。 Operations Manager 資料庫使用的最重要資源是記憶體子系統，但 CPU 和 RAM 也很重要。

影響 Operations Manager 資料庫負載的因素包括：

作業數據收集的速率。
- 作業數據收集的速率會受到因素影響，例如匯入的管理元件數目、新增的代理程式數目，以及受監視的計算機類型。例如，與使用多個資料庫監視執行 SQL Server 之伺服器的代理程式相比，監視業務關鍵桌面電腦的代理程式會收集較少的數據。
實例空間變更的速率。
- 相較於撰寫新的作業數據，更新 Operations Manager 資料庫中的現有數據需要大量資源。此外，當實例空間數據有所變更時，管理伺服器必須對資料庫進行更多查詢，才能計算組態和群組變更。當匯入新的管理元件或將新的代理程式新增至管理群組時，實例空間變更的速率會增加。
同時執行的 Operations 控制台和其他 SDK 連線數目也會影響資料庫的負載。
- 每個 Operations 控制台都會從 Operations Manager 資料庫讀取數據。查詢此數據可能會耗用大量的記憶體 I/O 資源、CPU 時間和 RAM。在 [事件檢視]、[狀態檢視]、[警示檢視] 和 [效能數據檢視] 中顯示大量作業數據的 Operations 控制台，通常會造成資料庫的最大負載。

Operations Manager 資料庫是管理群組的單一失敗來源，因此可以使用支援的故障轉移組態進行高可用性，例如 SQL Server Always On 可用性群組或故障轉移叢集實例。

您可以使用現有的 SQL Always-On 安裝程式來設定及升級 Operations Manager 資料庫，而不需要進行任何設定後變更。

在 Operations Manager 資料庫上啟用 SQL Broker

System Center Operations Manager 相依於 SQL Server Service Broker 來實作所有工作作業。如果 SQL Server Service Broker 已停用，所有工作作業都會受到影響。產生的行為可能會根據起始的工作而有所不同。因此，每當在 System Center Operations Manager 中觀察到非預期的行為時，檢查 SQL Server Service Broker 的狀態非常重要。

若要啟用 SQL Server Service Broker，請遵循下列步驟：

執行下列 SQL 查詢來檢查代理程式是否已啟用，如字段中的 1（一個） is_broker_enabled 結果表示：
```
SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
```

如果欄位中顯示 is_broker_enabled 的值是 0 （零），請執行下列 SQL 語句來啟用訊息代理程式：

ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
ALTER DATABASE OperationsManager SET ENABLE_BROKER
ALTER DATABASE OperationsManager SET MULTI_USER

Operations Manager 數據倉儲資料庫

注意

Operations Manager 數據倉儲也稱為「報表數據倉儲」資料庫，或只是某些檔中的「數據倉儲」。

System Center - Operations Manager 會以近乎即時的方式將數據插入數據倉儲中，請務必在此伺服器上有足夠的容量，可支援將數據寫入數據倉儲。如同 Operations Manager 資料庫，數據倉儲上最重要的資源是記憶體 I/O 子系統。在大部分的系統上，數據倉儲上的負載與 Operations Manager 資料庫類似，但可能會有所不同。此外，透過報告將數據倉儲放在數據倉儲上的工作負載，與 Operations 控制台使用方式在 Operations Manager 資料庫上放置的負載不同。

影響數據倉儲負載的因素包括：

作業數據收集的速率。
- 數據倉儲會執行計算並儲存匯總的數據，以及有限的原始數據量，以啟用更有效率的報告。因此，相較於 Operations Manager 資料庫，將作業數據收集到數據倉儲的成本略高。不過，相較於 Operations Manager 資料庫，這項成本會因數據倉儲中探索數據的處理成本降低而抵消。
並行報告使用者或排程的報表產生數目。
- 每個報告使用者都可以在系統上新增大量負載，因為報告經常摘要大量數據。整體容量需求會受到同時執行的報表數目和所執行報表的類型所影響。查詢大型日期範圍或大量物件的報表需要額外的系統資源。

根據這些因素，在調整數據倉儲大小時，有幾個建議做法需要考慮：

選擇適當的儲存子系統。
- 因為數據倉儲是整個數據流透過管理群組不可或缺的一部分，因此為數據倉儲選擇適當的儲存子系統很重要。如同 Operations Manager 資料庫，RAID 0 + 1 通常是最佳選擇。一般而言，數據倉儲的儲存子系統應該類似於 Operations Manager 資料庫的儲存子系統，而適用於 Operations Manager 資料庫的指引也適用於數據倉儲。
請考慮適當放置數據記錄與事務歷史記錄。
- 至於 Operations Manager 資料庫，當您相應增加代理程式數目時，將 SQL 數據和事務歷史記錄區隔通常是適當的選擇。如果 Operations Manager 資料庫和數據倉儲都位於相同的伺服器上，而且您想要分隔數據和事務歷史記錄，您必須將 Operations Manager 資料庫的事務歷史記錄放在數據倉儲的個別實體磁碟區和磁碟主軸上，以接收任何好處。只要磁碟區提供足夠的容量和磁碟 I/O 效能，Operations Manager 資料庫和數據倉儲的數據檔就可以共用相同的實體磁碟區，不會對監視和報告功能造成負面影響。
請考慮將數據倉儲放在與 Operations Manager 資料庫不同的伺服器上。
- 雖然較小的部署通常可以合併相同伺服器上的 Operations Manager 資料庫和數據倉儲，但當您相應增加代理程式數目和傳入作業數據量時，將它們分開是有好處的。當數據倉儲和報表伺服器位於與 Operations Manager 資料庫不同的伺服器上時，您就會體驗到更好的報告效能。

Operations Manager 數據倉儲資料庫是管理群組的單一失敗來源，因此可以使用支援的故障轉移組態進行高可用性，例如 SQL Server Always On 可用性群組或故障轉移叢集實例。

SQL Server Always On

SQL Server Always On 可用性群組支援一組離散使用者資料庫的故障轉移環境（可用性資料庫）。每個可用性資料庫集都裝載在可用性複本上。

使用 System Center 2016 和更新版本 - Operations Manager，SQL Always On 優先於故障轉移叢集，以提供資料庫的高可用性。除了原生模式 Reporting Services 安裝以外的所有資料庫，其使用兩個資料庫來分隔永續性數據記憶體與暫存記憶體需求，都可以裝載在 AlwaysOn 可用性群組中。

若要設定可用性群組，您可以部署 Windows Server 故障轉移叢集（WSFC）叢集來裝載可用性複本，並在叢集節點上啟用 AlwaysOn。接著，您可以將 Operations Manager SQL Server 資料庫新增為可用性資料庫。

深入瞭解 AlwaysOn必要條件。
深入瞭解如何設定 Always On 可用性群組的 WSFC。
深入瞭解如何設定可用性群組。

提示

從 Operations Manager 2022 開始，您可以使用現有的 SQL Always-On 安裝程式來設定及升級 Operations Manager 資料庫，而不需要變更設定後。

深入瞭解 AlwaysOn必要條件。
深入瞭解如何設定 Always On 可用性群組的 WSFC。
深入瞭解如何設定可用性群組。

注意

在參與 SQL Always On 的 SQL Server 節點上部署 Operations Manager 之後，若要啟用 CLR 嚴格安全性，請在每個 Operations Manager 資料庫上執行 SQL 腳本。

Multisubnet 字串

Operations Manager 不支援連接字串關鍵詞（MultiSubnetFailover=True）。由於可用性群組具有接聽程式名稱（稱為 WSFC 叢集管理員中的網路名稱或用戶端存取點），視來自不同子網的多個 IP 位址而定，例如當您部署跨月臺故障轉移組態時，從管理伺服器到可用性群組接聽程式的用戶端連線要求將會達到連線逾時。

在多重子網環境中，使用已部署的可用性群組伺服器節點來解決這項限制的建議方法是：

將可用性群組接聽程式的網路名稱設定為只在 DNS 中註冊單一作用中的 IP 位址。
設定叢集以針對已註冊的 DNS 記錄使用低 TTL 值。

這些設定可讓您在故障轉移至不同子網中的節點時，使用新的IP位址，更快速地復原和解析叢集名稱。

在任何一個 SQL 節點上執行下列 PowerShell 命令，以修改這些設定：

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

如果您使用 Always On 搭配接聽程式名稱，則也應該在接聽程式上進行這些組態變更。如需設定可用性群組接聽程式的詳細資訊，請參閱這裡的檔：設定可用性群組接聽程式 - SQL Server Always On。

下列 PowerShell 命令可以在目前裝載接聽程式的 SQL 節點上執行，以修改其設定：

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

當叢集或 Always On SQL 實例用於高可用性時，您應該在管理伺服器上啟用自動復原功能，以避免每當發生節點之間的故障轉移時，Operations Manager 數據存取服務重新啟動。如需組態資訊，請參閱下列知識庫文章 System Center 管理服務在 SQL Server 實例脫機後停止回應。

優化 SQL Server

支持體驗顯示，效能問題通常不是由高資源使用率（也就是處理器或記憶體）與 SQL Server 本身所造成;相反地，問題與儲存子系統的設定直接相關。效能瓶頸通常歸因於不要遵循針對 SQL Server 資料庫實例布建的記憶體的建議設定指引。這類範例如下：

磁碟軸配置不足，無法支援 Operations Manager 的 IO 需求。
在相同磁碟區上裝載事務歷史記錄和資料庫檔案。這兩個工作負載有不同的 IO 和延遲特性。
TempDB 的設定在放置、重設大小等等方面不正確。
裝載資料庫事務歷史記錄、資料庫檔案和 TempDB 的磁碟分區錯誤。
忽略基本 SQL Server 組態，例如針對資料庫和事務歷史記錄檔使用 AUTOGROW、查詢平行處理原則的 MAXDOP 設定、為每個 CPU 核心建立多個 TempDB 數據檔等等。

記憶體組態是 Operations Manager SQL Server 部署的重要元件之一。資料庫伺服器通常會因為嚴格的資料庫讀取和寫入活動和事務歷史記錄處理而大量系結 I/O。 Operations Manager 的 I/O 行為模式通常是 80% 的寫入和 20% 的讀取。因此，I/O 子系統的設定不正確可能會導致 SQL Server 系統的效能和作業不佳，而且在 Operations Manager 中變得明顯。

請務必先執行IO子系統的輸送量測試，再部署SQL Server，以測試 SQL Server 設計。請確定這些測試能夠以可接受的延遲達到您的 IO 需求。使用 Diskspd 公用程式來評估支援 SQL Server 之記憶體子系統的 I/O 容量。下列部落格文章是由產品群組中的檔伺服器小組成員所撰寫，提供有關如何使用此工具執行壓力測試的詳細指引和建議 - DiskSpd、PowerShell 和記憶體效能：測量本機磁碟和 SMB 檔案共用的 IOPS、輸送量和延遲。

NTFS 配置單位大小

磁碟區對齊通常稱為扇區對齊，每當在RAID裝置上建立磁碟區時，應該在文件系統（NTFS）上執行。若無法這麼做，可能會導致顯著的效能降低，而且通常是分割區單位界限不對齊的結果。它也會導致硬體快取不對齊，導致數位快取使用率效率低下。

格式化用於 SQL Server 數據檔的數據分割時，建議針對數據、記錄和 TempDB 使用 64 KB 的配置單位大小（也就是 65,536 個字節）。不過請注意，使用大於 4 KB 的配置單位大小，會導致無法在磁碟區上使用 NTFS 壓縮。雖然 SQL Server 支援壓縮磁碟區上的唯讀數據，但不建議這麼做。

保留記憶體

注意

本節的大部分信息都來自 Jonathan Kehayias 在他的部落格文章中，我的 SQL Server 實際需要多少記憶體？（sqlskills.com）

為了支援 System Center Operations Manager，或針對此產品以外的其他工作負載，識別正確的物理記憶體和處理器配置給 SQL Server 並不一定容易。產品群組所提供的重設大小計算機會根據工作負載規模提供指引，但其建議是以實驗室環境中執行的測試為基礎，這些測試可能與實際工作負載和設定不一致。

SQL Server 可讓您設定其進程將保留及使用的最小和最大記憶體數量。根據預設，SQL Server 可以根據可用的系統資源動態變更其記憶體需求。最小伺服器記憶體的預設設定為 0，最大伺服器記憶體的預設設定為 2,147,483,647 MB。

如果您未為 最大伺服器記憶體設定適當的值，可能會發生效能和記憶體相關問題。許多因素會影響您需要配置給 SQL Server 多少記憶體，以確保操作系統可以支援在該系統上執行的其他進程，例如 HBA 記憶卡、管理代理程式和防毒實時掃描。如果未設定足夠的記憶體，OS 和 SQL 將會分頁到磁碟。這可能會導致磁碟 I/O 增加、進一步降低效能，並在 Operations Manager 中產生明顯的波紋效果。

建議針對最小伺服器記憶體指定至少 4 GB 的 RAM。這應該針對裝載其中一個 Operations Manager 資料庫的每個 SQL 節點（操作、數據倉儲、ACS）。

針對 最大伺服器記憶體，建議您一開始保留總計：

OS 的 1 GB RAM
每安裝 4 GB RAM 每 4 GB RAM 1 GB（最多 16 GB RAM）
每安裝 8 GB RAM 每一個 8 GB RAM 1 GB （高於 16 GB RAM）

設定這些值之後，請監視 Windows 中的 Memory\Available MBytes 計數器，以判斷您是否可以增加 SQL Server 可用的記憶體。 Windows 會發出可用的物理記憶體在 96 MB 的低執行訊號，因此在理想情況下，計數器不應低於 200-300 MB 左右，以確保您有緩衝區。針對具有 256 GB RAM 或更高版本的伺服器，請確定其執行不會低於 1 GB。

請記住，這些計算假設您想要 SQL Server 能夠使用所有可用的記憶體，除非您修改它們以考慮其他應用程式。請考慮 OS、其他應用程式、SQL Server 線程堆疊和其他多頁配置器的特定記憶體需求。典型的公式是 ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators))，其中線程堆疊的記憶體 = ((max worker threads) (stack size))。 x86 系統的堆疊大小為 512 KB、x64 系統的 2 MB，IA64 系統的堆疊大小為 4 MB，您可以在 sys.dm_os_sys_info 的 max_worker_count 數據行中找到最大背景工作線程的值。

這些考慮也適用於 SQL Server 在虛擬機中執行的記憶體需求。由於 SQL Server 是設計來快取緩衝池中的數據，而且會盡可能使用盡可能多的記憶體，因此很難判斷所需的理想 RAM 數量。減少配置給 SQL Server 實例的記憶體時，您可以到達一個點，讓較低的記憶體配置用於較高的磁碟 I/O 存取。

若要在已過度布建的環境中設定 SQL Server 記憶體，請從監視環境和目前的效能計量開始，包括 SQL Server Buffer Manager 頁面的預期壽命和頁面 reads/sec，以及實體磁碟讀取/秒值。如果環境記憶體過多， 由於快取，頁面壽命 會每秒鐘增加一個值，而不會因為快取而減少;SQL Server Buffer Manager 頁面讀取/秒 值在快取增加後會很低;而實體磁碟 讀取/秒 也會保持低。

了解環境基準之後，您可以將最大伺服器記憶體減少 1 GB，然後查看影響性能計數器的方式（在任何初始快取清除消退之後）。如果計量仍可接受，請再減少 1 GB，然後再監視一次，視需要重複，直到您判斷理想的設定為止。

如需詳細資訊，請參閱伺服器記憶體組態選項。

優化TempDB

TempDB 資料庫的大小和實體位置可能會影響 Operations Manager 的效能。例如，如果針對 TempDB 定義的大小太小，系統處理負載的一部分可能會隨著自動成長 TempDB 而佔用到每次重新啟動 SQL Server 實例時支援工作負載所需的大小。若要達到最佳的 TempDB 效能，建議您在生產環境中為 TempDB 設定下列設定：

將 TempDB 的恢復模式設定為 SIMPLE。
- 此模型會自動回收記錄空間，以保持空間需求較小。
將檔案大小設定為足以容納環境中一般工作負載的值，以預先配置所有 TempDB 檔案的空間。它可防止 TempDB 過於頻繁地擴充，這可能會影響效能。 TempDB 資料庫可以設定為自動成長，但這應該用來增加非計劃性例外狀況的磁碟空間。
視需要建立多個檔案，以將磁碟頻寬最大化。
- 使用多個檔案可減少 TempDB 記憶體爭用，並產生改善的延展性。不過，請勿建立太多檔案，因為它可以降低效能並增加管理額外負荷。
- 一般指導方針為伺服器上每個邏輯處理器建立一個數據檔（考慮任何同質遮罩設定），然後視需要調整檔案數目。
- 基於一般規則，如果邏輯處理器的數目小於或等於 8，則與邏輯處理器使用相同數目的資料檔案。
  - 如果邏輯處理器數目大於 8，請使用 8 個數據檔，然後如果爭用繼續，請將數據檔數目增加為 4 的倍數（最多為邏輯處理器數目），直到爭用縮減為可接受的層級或變更工作負載/程式代碼為止。
  - 如果未減少爭用，您可能必須增加更多數據檔的數目。
讓每個數據檔的大小相同，以達到最佳比例填滿效能。
- 數據檔的大小相等很重要，因為比例填滿演算法是以檔案的大小為基礎。如果使用不相等的大小建立數據檔，比例填滿演算法會嘗試使用最大的檔案進行 GAM 配置，而不是在所有檔案之間分散配置，從而破壞建立多個數據檔的目的。
使用固態硬碟將 TempDB 資料庫放在快速 I/O 子系統上，以獲得最佳效能。
- 如果有許多直接連接的磁碟，請使用磁碟條狀配置。
將 TempDB 資料庫放在不同於用戶資料庫所使用的磁碟上。

若要設定 TempDB，您可以在 Management Studio 中執行下列查詢或修改其屬性。

USE [TempDB]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [TempDB] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'TempDB', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [TempDB] ADD FILE ( NAME = N'TempDB2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TempDB2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

執行 T-SQL 查詢 SELECT * from sys.sysprocesses 來偵測 TempDB 資料庫的頁面配置爭用。在系統數據表輸出中，等候資源可以顯示為「2：1：1」（PFS 頁面）或「2：1：3」（共用全域配置對應頁面）。視爭用程度而定，此設定可能會導致 SQL Server 在短時間內顯得沒有回應。另一種方法是檢查動態管理檢視 [sys.dm_exec_request 或 sys.dm_os_waiting_tasks]。結果顯示這些要求或工作正在等候 TempDB 資源，而且在執行查詢時 sys.sysprocesses ，其值會稍早醒目提示。

如果先前的建議不會大幅減少配置爭用，而且爭用位於 SGAM 頁面上，請在 SQL Server 的啟動參數中實作追蹤旗標，讓追蹤旗-T1118標即使在回收 SQL Server 之後仍有效。在此追蹤旗標下，SQL Server 會將完整範圍配置給每個資料庫物件，藉此消除 SGAM 頁面上的爭用。

注意

此追蹤旗標會影響 SQL Server 實例上的每個資料庫。

平行處理原則的程度上限

提示

如需 SQL Server 小組的最新最佳做法和建議，請參閱這裡的檔：設定最大平行處理原則選項以獲得最佳效能

適用於 Operations Manager 中小型部署的 SQL Server 預設組態適用於大部分需求。不過，當管理群組的工作負載相應增加至企業級案例時（通常是 2,000 個以上的代理程式管理系統和進階監視組態，其中包括具有進階綜合交易的服務等級監視、網路裝置監視、跨平臺等等），則必須將本檔本節所述的 SQL Server 設定優化。先前指引中未討論的其中一個組態選項是 MAXDOP。

Microsoft SQL Server 平行處理原則的最大程度（MAXDOP）組態選項會控制用於平行計劃中查詢執行的處理器數目。此選項會決定用於平行執行工作的查詢計劃運算子的運算和線程資源。根據是否在對稱多重處理（SMP）電腦上設定 SQL Server、非一般記憶體存取（NUMA）電腦或啟用超線程的處理器而定，您必須適當地設定平行處理原則的最大程度選項。

當 SQL Server 在具有多個微控制器或 CPU 的電腦上執行時，它會偵測到平行處理原則的最佳程度，也就是針對每個平行計劃執行所採用的處理器數目。根據預設，此選項的值是 0，可讓 SQL Server 判斷平行處理原則的最大程度。

Operations Manager 中預先定義的預存程式和查詢，因為它與操作、數據倉儲，甚至稽核資料庫沒有包含 MAXDOP 選項，因為安裝期間無法動態查詢向操作系統呈現多少處理器，也不會嘗試硬式編碼此設定的值，這可能會在執行查詢時產生負面影響。

注意

平行處理原則的最大程度組態選項不會限制 SQL Server 使用的處理器數目。若要設定 SQL Server 使用的處理器數目，請使用 affinity mask 組態選項。

針對使用八個以上處理器的伺服器，請使用下列組態：MAXDOP=8
針對使用八個或更少處理器的伺服器，請使用下列組態：MAXDOP=0 到 N

提示

在此組態中， N 表示處理器數目。
針對已設定 NUMA 的伺服器，MAXDOP 不應超過指派給每個 NUMA 節點的 CPU 數目。
針對已啟用超線程的伺服器，MAXDOP 值不應超過實體處理器的數目。
針對已啟用 NUMA 設定和超線程的伺服器，MAXDOP 值不應超過每個 NUMA 節點的實體處理器數目。

您可以藉由查詢 select * from sys.dm_os_tasks來監視平行背景工作角色的數目。

在此範例中，伺服器的硬體組態是具有 24 個核心處理器和 196 GB RAM 的 HP 刀鋒視窗 G6。裝載 Operations Manager 資料庫的實例具有 64 GB 的 MAXMEM 設定。在本節中執行建議的優化之後，效能已改善。不過，查詢平行處理原則瓶頸仍會保存。測試不同的值之後，透過設定 MAXDOP=4 找到最理想的效能。

初始資料庫重設大小

嘗試估計 Operations Manager 資料庫的未來成長，特別是作業和數據倉儲資料庫，在部署後的前幾個月內並不是簡單的練習。雖然 Operations Manager 重設大小協助程式根據產品群組從實驗室測試衍生的公式來估計潛在成長是合理的，但它不會考慮數個因素，這可能會影響短期與長期成長。

大小調整協助程序建議的初始資料庫大小應該配置給預測大小，以減少片段和對應的額外負荷，這可以在作業和數據倉儲資料庫的設定時間指定。如果在安裝期間沒有足夠的儲存空間可用，稍後可以使用 SQL Management Studio 擴充資料庫，然後重新編製索引，以便據此進行重組和優化。此建議也適用於 ACS 資料庫。

主動監視作業和數據倉儲資料庫的成長，應該每天或每周執行一次。這是識別非預期且顯著成長的刺激，並開始進行疑難解答，以判斷因果關係、管理元件工作流程中的錯誤（也就是探索規則、效能或事件收集規則，或監視或警示規則）或其他在發行管理程序測試和品質保證階段未識別之管理元件的其他徵兆。

資料庫自動成長

當保留的資料庫檔案大小滿時，SQL Server 可以自動增加百分比或固定數量的大小。此外，您可以設定資料庫大小上限，以防止填滿磁碟上的所有可用空間。根據預設，Operations Manager 資料庫未設定啟用自動成長;只有數據倉儲和 ACS 資料庫。

只依賴自動成長作為意外成長的應變措施。自動成長導入了處理高度交易式資料庫時應考慮的效能處罰。效能處罰包括：

如果您沒有提供適當的成長增量，可能會發生記錄檔或資料庫的片段。
如果您執行的交易需要比可用更多的記錄空間，且該資料庫的事務歷史記錄會啟用自動成長，則交易完成所需的時間會包含事務歷史記錄因設定數量而成長所需的時間。
如果您執行需要記錄成長的大型交易，其他需要寫入事務歷史記錄的交易也必須等到成長作業完成為止。

如果結合自動成長和 autoshrink 選項，這可能會造成不必要的額外負荷。請確定觸發成長和壓縮作業的臨界值不會造成頻繁的上下大小變更。例如，您可以執行會導致事務歷史記錄在認可時成長 100 MB 的交易;之後的一段時間，autoshrink 會啟動並壓縮事務歷史記錄檔 100 MB。然後，您執行相同的交易，並導致事務歷史記錄再次成長 100 MB。在該範例中，您會建立不必要的額外負荷，並可能建立記錄檔的片段，這兩者都可能會對效能造成負面影響。

請仔細設定這兩個設定。特定設定確實取決於您的環境。一般建議是將資料庫大小增加固定數量，以減少磁碟分散。例如，請參閱下圖，其中資料庫設定為每次需要自動成長時增加 1,024 MB。

叢集故障轉移原則

Windows Server 故障轉移叢集是高可用性平臺，會持續監視叢集中節點的網路連線和健康情況。如果無法透過網路連線到節點，則會採取復原動作來復原，並在叢集中的另一個節點上讓應用程式和服務上線。默認設定已針對伺服器完全遺失的失敗進行優化，這被視為「硬式」失敗。這些是無法復原的失敗案例，例如非故障的硬體或電源失敗。在這些情況下，伺服器會遺失，目標是故障轉移叢集快速偵測伺服器遺失，並在叢集中的另一部伺服器上快速復原。若要從硬式失敗中快速復原，叢集健康情況監視的預設設定相當積極。不過，它們完全可設定，以允許各種案例的彈性。

這些預設設定可為大多數客戶提供最佳行為;不過，由於叢集從英吋延伸至可能相隔英里，因此叢集可能會暴露在節點之間的更多網路元件，而且可能不可靠。另一個因素是，商品伺服器的質量不斷增加，加上透過備援元件增強的復原能力（例如雙電源供應器、NIC 小組和多路徑 I/O），非重複硬體故障數目可能相當罕見。因為硬式失敗可能較不頻繁，某些客戶可能會想要調整叢集以進行暫時性失敗，因為叢集更能彈性地復原節點之間的短暫網路失敗。藉由增加默認失敗閾值，您可以降低持續短時間的簡短網路問題的敏感度。

請務必瞭解這裡沒有正確的答案，且優化設定可能會因您的特定商務需求和服務等級協定而有所不同。

虛擬化 SQL Server

基於效能考慮，在虛擬環境中，建議您將操作資料庫和數據倉儲資料庫儲存在直接鏈接的記憶體上，而不是儲存在虛擬磁碟上。您可以使用針對 Operations Manager 2012 發行的 Operations Manager 大小協助程式公用程式，估計所需的 IOPS 和壓力測試數據磁碟以驗證。記憶體效能可以使用 DiskSpd 公用程式進行測試。另請參閱 Operations Manager 虛擬化支援，以取得虛擬化 Operations Manager 環境的其他指引。

AlwaysOn 和恢復模式

雖然不是嚴格的優化，但關於 AlwaysOn 可用性群組的重要考慮是，根據設計，此功能需要在「完整」恢復模式下設定資料庫。也就是說，在完整備份完成或只有事務歷史記錄之前，永遠不會捨棄事務歷史記錄。因此，備份策略不是選擇性的，而是 Operations Manager 資料庫 AlwaysOn 設計的必要部分。否則，隨著時間，包含事務歷史記錄的磁碟會填滿。

備份策略必須考慮到環境的詳細數據。下表提供一般備份排程。

備份類型	排程
僅限事務歷史記錄	每1小時
完整	每周，星期天上午 3：00

優化 SQL Server Reporting Services

Reporting Services 實例可作為存取數據倉儲資料庫中數據的 Proxy。它會根據儲存在管理元件內的範本產生和顯示報告。

Operations Manager 報表角色無法與舊版的報表角色並存安裝，且只能以原生模式安裝（不支援 SharePoint 整合模式）。

在 Reporting Services 的幕後，有一個 SQL Server 資料庫實例裝載 ReportServer 和 ReportServerTempDB 資料庫。適用於此實例效能微調的一般建議。

注意

從 SQL Server Reporting Services （SSRS） 2017 14.0.600.1274 版和更新版本，預設安全性設定不允許資源延伸模組上傳。這會導致 Operations Manager 在部署報表元件期間發生 ResourceFileFormatNotAllowedException 例外狀況。

修正方法：

開啟 [SQL Management Studio] 。
聯機到 Reporting Services 實例。
在 [物件總管] 視窗中，以滑鼠右鍵按下伺服器實例。
選取 [屬性]。
選取 左側提要欄位上的 [進階 ]。
將新增*.*至 AllowedResourceExtensionsForUpload 的清單。

或者，您可以將 Operations Manager 報告延伸模組的完整清單新增至 SSRS 中的允許清單 。此處的「解決方案 2」將說明此列表： Operations Manager 報告無法部署

下一步

若要瞭解如何設定在防火牆後方裝載（Reporting）數據倉儲，請參閱跨防火牆連接（Reporting）數據倉儲。

共用方式為