共用方式為

SQL Server 設計考量

  • 發行項

System Center Operations Manager 需要存取執行 Microsoft SQL Server 的伺服器實例，以支援作業、數據倉儲和 ACS 稽核資料庫。 當您在管理群組中部署第一部管理伺服器時，需要操作和數據倉儲資料庫，而當您在管理群組中部署 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 關係資料庫服務（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） 或更新版本，如這裡所述

    注意

    • Operations Manager 2019 支援具有 CU8 或更新版本的 SQL 2019;不過，它不支援 SQL 2019 RTM。
    • 使用 ODBC 17.3 或 17.10.6 和 MSOLEDBSQL 18.2 或 18.7.2。

  • SQL Server 2022

  • SQL Server 2019 含累積更新 8 （CU8） 或更新版本，如這裡所述

    注意

    • Operations Manager 2022 支援具有 CU8 或更新版本的 SQL 2019;不過，它不支援 SQL 2019 RTM。
    • 使用 ODBC 17.3 或 17.10.6 和 MSOLEDBSQL 18.2 或 18.7.2。
  • SQL Server 2017 和累積更新，如這裏詳述
  • SQL Server 2016 和 Service Pack，如這裡所述
  • SQL Server 2017 和累積更新，如這裏詳述

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

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

  • SQL Server 2016 和 Service Pack，如這裡所述
  • SQL Server 2014 和 Service Pack，如這裡所述
  • SQL Server 2012 和 Service Pack，如這裡詳述

注意

  • 支援 SCOM 基礎結構的下列每個 SQL Server 元件都必須位於相同的 SQL Server 主要版本：
    • 裝載任何 SCOM 資料庫的 SQL Server 資料庫引擎實例（也就是 OperationManager、OperationManagerDW 和 SSRS 資料庫 ReportServer 和 ReportServerTempDB）。
    • SQL Server Reporting Services （SSRS） 實例。
  • SQL Server 定序設定必須是下列 SQL Server 定序設定一節中所述的其中一種支持類型。
  • 裝載任何 SCOM 資料庫的所有 SQL Server 資料庫引擎實例都需要 SQL Server 全文搜尋。
  • Operations Manager 資料庫元件支援的 Windows Server 2016 安裝選項（Server Core、桌面體驗伺服器和 Nano Server）是以 SQL Server 支援的 Windows Server 安裝選項為基礎。

注意

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

設計規劃中會套用其他硬體和軟體考慮：

  • 建議您在具有NTFS檔案格式的電腦上執行SS檔格式的電腦上執行 SQL Server。
  • 作業和數據倉儲資料庫必須至少有 1024 MB 的可用磁碟空間。 它會在資料庫建立時強制執行，而且在設定之後可能會大幅成長。
  • 需要 .NET Framework 4。
  • Operations Manager 2022 支援 .NET Framework 4.8。
  • Windows Server Core 不支援報表伺服器。

如需詳細資訊，請參閱安裝 SQL Server 2014 或 2016 的硬體和軟體需求。

如需詳細資訊，請參閱安裝 SQL Server 的硬體與軟體需求。

注意

雖然 Operations Manager 只會在安裝期間使用 Windows 驗證，但如果沒有本機帳戶具有db_owner角色，SQL 混合模式驗證設定仍會運作。 已知具有db_owner角色的本機帳戶會導致 System Center Operations Manager 的問題。 在安裝產品之前，請先從所有本機帳戶中移除db_owner角色，在安裝之後不要將db_owner角色新增至任何本機帳戶。

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 可用性群組為 Operations Manager 資料庫提供故障轉移功能的分散式部署，則需要在防火牆安全性策略中包含其他防火牆組態設定。

下表可協助您識別 SQL Server 所需的防火牆埠，這些埠必須至少允許，才能讓 Operations Manager 管理群組中的伺服器角色順利通訊。

案例 連接埠 方向 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 資料庫負載的因素包括：

  • 作業數據收集的速率。 作業數據是由代理程式收集的所有事件、警示、狀態變更和效能數據所組成。 Operations Manager 資料庫所使用的大部分資源都會用來將此數據寫入磁碟，因為它進入系統。 收集的作業數據速率通常會隨著其他管理元件匯入和新增其他代理程式而增加。 代理程式正在監視的計算機類型也是判斷作業數據收集整體速率時所使用的重要因素。 例如，監視業務關鍵桌面計算機的代理程序應該會比監視具有大量資料庫之 SQL Server 實例的伺服器監視伺服器的代理程式收集較少的數據。
  • 實例空間變更的速率。 相較於撰寫新的作業數據，在 Operations Manager 資料庫中更新此數據的成本很高。 此外，當實例空間數據變更時，管理伺服器會對 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，請遵循下列步驟：

  1. 執行下列 SQL 查詢：

    SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'

  2. 如果欄位中顯示 is_broker_enabled 的值是 1 （一個），請略過此步驟。 否則，請執行下列 SQL 查詢：

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

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 資料庫新增為可用性資料庫。

SQL Server Always On

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

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

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

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

注意

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

Multisubnet 字串

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

當您在多重子網環境中的可用性群組中部署伺服器節點時，建議解決這項限制的建議方法是執行下列動作：

  1. 將可用性群組接聽程式的網路名稱設定為只在 DNS 中註冊單一作用中的 IP 位址。
  2. 設定叢集以針對已註冊的 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

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

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 容量。 下列部落格文章由產品群組中的文件伺服器小組成員所撰寫，提供有關如何搭配某些 PowerShell 程式代碼執行壓力測試，以及使用 PerfMon 擷取結果的詳細指引和建議。 您也可以參考 Operations Manager 重設大小協助程式 以取得初始指引。

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 實例上的每個資料庫。

平行處理原則的程度上限

適用於 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 中預先定義的預存程式和查詢，因為它與操作、數據倉儲，甚至稽核資料庫無關，因為安裝期間沒有辦法動態查詢操作系統呈現多少處理器，也不會嘗試硬式編碼此設定的值，這可能會在執行查詢時產生負面影響。

注意

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

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

    注意

    在此設定中，N 代表處理器數目。