SQL Server 設計考量

System Center Operations Manager 需要能夠存取執行 Microsoft SQL Server 之伺服器的執行個體，才能支援操作、資料倉儲和 ACS 稽核資料庫。 當您在管理群組中部署第一部管理伺服器時，需要使用並建立操作和資料倉儲資料庫，同時在管理群組中部署 ACS 收集器時，則會建立 ACS 資料庫。

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

在中型到企業規模分散式部署中，SQL Server 執行個體應該位於專用的獨立伺服器或 SQL Server 高可用性組態中。 不論如何，在您開始安裝第一部管理伺服器或 ACS 收集器之前，SQL Server 必須已經存在並可存取。

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

重要

Operations Manager 不支援平臺即服務 (PaaS) SQL 實例，包括 Azure SQL 受控執行個體 或 Amazon 關係資料庫服務等產品， (AWS RDS) 。 請使用安裝在 Windows 機器上的 SQL Server 實例。 唯一的例外狀況是在 Azure 監視器 SCOM 受控執行個體 內，其會利用 Azure SQL MI，而且無法重新設定。

SQL Server 需求

下列版本的 SQL Server Enterprise 與 Standard Edition 支援現有 System Center Operations Manager 版安裝，以裝載報表伺服器、作業、資料倉儲與 ACS 資料庫：

• SQL Server 2022

• SQL Server 2019 累積更新 8 (CU8) 或更新版本，如這裡所述

  注意

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

• SQL Server 2017 與累計更新，如這裡 \(英文\) 所詳述

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

注意

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

注意

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

您的設計規劃中適用的其他硬體及軟體考量︰

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

如需詳細資訊，請參閱安裝 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 管理群組中的伺服器角色成功進行通訊。

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

* 雖然 TCP 1433 是 Database Engine 預設實例的標準埠，但當您在獨立 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 AlwaysOn 可用性群組或容錯移轉叢集執行個體。

您可以使用現有的 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 AlwaysOn 可用性群組或容錯移轉叢集執行個體。

SQL Server AlwaysOn

SQL Server AlwaysOn 可用性群組支援適用於一組特定使用者資料庫 (可用性資料庫) 的容錯移轉環境。 每一組可用性資料庫均是透過可用性複本來裝載。

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

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

注意

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

多重子網路字串

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>

當使用叢集或 AlwaysOn SQL 執行個體為高可用性時，您應該在管理伺服器上啟用自動復原功能，以避免每當節點之間發生容錯移轉時，Operations Manager 資料存取服務即重新啟動。 如需如何設定的資訊，請參閱下列知識庫文章 System Center 管理服務在 SQL Server 執行個體離線之後停止回應。

最佳化 SQL Server

一般而言，客戶先前的部署體驗顯示效能問題通常是因為高資源使用率 (所造成，也就是處理器或記憶體) 本身 SQL Server;而是與記憶體子系統的設定直接相關。 效能瓶頸通常歸因於針對 SQL Server 資料庫執行個體佈建儲存體時未遵循建議的設定指導方針。 此類範例包括：

• LUN 主軸的配置不足，無法支援 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 容量。 下列部落格文章是由產品群組中的文件伺服器小組成員所撰寫，提供有關如何使用此工具執行壓力測試的詳細指引和建議，以及 使用 PerfMon 擷取結果。 您也可以參閱 Operations Manager 重設大小協助程式 以取得初始指引。

NTFS 配置單位大小

每當在 RAID 裝置上建立磁碟區時，應該在檔案系統 (NTFS) 上執行磁碟區對齊方式 (通常指的是磁區對齊方式)。 若無法這麼做，可能會導致效能大幅降低，而且最常見的是分割區對齊與等量單位界限不一致的結果。 它也可能會導致硬體快取對齊錯誤，進而造成陣列快取的使用率效率不彰。 格式化將用於 SQL Server 數據文件的數據分割時，建議您使用 64 KB 的配置單位大小 (，也就是 65,536 個字節) 數據、記錄和 tempdb。 不過請注意，使用大於 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) 。

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

• 操作系統的 1 GB RAM
• 每個每安裝 4 GB RAM 1 GB 的 RAM (最多 16 GB RAM)
• 每個每安裝 8 GB RAM 的 1 GB RAM (高於 16 GB RAM)

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

請記住，除非您修改這些計算以考慮其他應用程式，否則這些計算假設您想要 SQL Server 能夠使用所有可用的記憶體。 請考慮操作系統、其他應用程式、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 緩衝區管理員頁面生命週期和頁面讀取/秒，以及實體磁碟讀取/秒值。 如果環境記憶體過多，由於快取，頁面生命週期會每秒增加一個值，而不會在工作負載下有任何減少;快取向上增加之後，SQL Server 緩衝區管理員頁面讀取/秒值會很低;而實體磁碟讀取/秒也會維持低。

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

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

最佳化 TempDB

tempdb 資料庫的大小與實際位置可能會影響 Operations Manager 的效能。 例如，如果針對 tempdb 定義的大小太小，則每次您重新啟動 SQL Server 執行個體時，部分系統處理負載可能會隨著自動成長的 tempdb 一起佔用到支援工作負載所需的大小。 若要達到最佳 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 的 Startup 參數中實作追蹤旗標 -T1118，讓追蹤旗標即使在回收 SQL Server 之後仍有效。 在此追蹤旗標之下，SQL Server 會將完整範圍配置給每個資料庫物件，藉此消除 SGAM 頁面的爭用情況。

注意

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

平行處理原則的最大限制

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

Microsoft SQL Server 平行處理原則的最大限制 (MAXDOP) 設定選項可控制在平行計劃中執行查詢所使用的處理器數目。 此選項可決定用於以平行方式執行工作之查詢計劃運算子的運算和執行緒資源。 根據 SQL Server 是設定在對稱多重處理 (SMP) 計算機上、非統一記憶體存取 (NUMA) 計算機，還是啟用超線程的處理器，您必須適當地設定平行處理原則的最大程度選項。

在具有多個微處理器或 CPU 的電腦上執行 SQL Server 時，它會偵測平行處理原則的最佳限制，也就是為針對每個平行計劃執行來執行單一陳述式所採用的處理器數目。 根據預設，此選項的值為 0，這可讓 SQL Server 決定平行處理原則的最大限制。

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

注意

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

• 若伺服器使用的處理器超過 8 個，請使用下列設定︰MAXDOP=8
• 對於使用八個或更少處理器的伺服器，請使用下列組態：MAXDOP=0 到 N

  注意

  在此組態中，N 代表處理器數目。