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 Relational Database Service (AWS RDS) 等产品。 请使用安装在 Windows 计算机上的 SQL Server 实例。 唯一的例外是 Azure Monitor SCOM 托管实例，它利用 Azure SQL MI，不可重新配置。

SQL Server 要求

以下版本的 SQL Server Enterprise Edition 和 SQL Server 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 全文搜索。
• Operations Manager 数据库组件支持的 Windows Server 2016 安装选项（服务器核心、具有桌面体验的服务器和 Nano 服务器）以 SQL Server 支持的 Windows Server 的安装选项为基础。

备注

System Center Operations Manager Reporting 不能与以前版本的 Reporting 角色并行安装，并且 必须 仅 (不支持 SharePoint 集成模式) 以本机模式安装。

在设计规划中还有其他硬件和软件注意事项：

• 我们建议在计算机上使用 NTFS 文件格式运行 SQL Server。
• 必须至少有 1024 MB 的可用磁盘空间用于操作和数据仓库数据库。 它在创建数据库时强制实施，在设置后可能会显著增长。
• 需要 .NET Framework 4。
• 从 Operations Manager 2022 起，支持 .NET Framework 4.8。
• Windows Server Core 不支持 Reporting Server。

有关详细信息，请参阅安装 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 和应用程序诊断）
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 Reporting Server 的 SQL Server Reporting Services	TCP 80（默认）/443 (SSL)	入站	管理服务器和操作控制台

* 尽管 TCP 1433 是数据库引擎默认实例的标准端口，如果在独立的 SQL Server 上创建命名的实例或已部署 SQL Always On 可用性组，则会定义自定义端口并进行记录以供参考，以便在安装过程中正确配置防火墙并输入此信息。

有关 SQL Server 的防火墙要求的详细概述，请参阅配置 Windows 防火墙以允许 SQL Server 访问。

容量和存储注意事项

Operations Manager 数据库

Operations Manager 数据库是包含 Operations Manager 日常监视所需的所有数据的 SQL Server 数据库。 数据库服务器的大小调整和配置对于管理组的整体性能至关重要。 Operations Manager 数据库使用的最重要的资源是存储子系统，但 CPU 和 RAM 同样非常重要。

影响 Operations Manager 数据库上负载的因素包括：

• 操作数据集合的速率。 操作数据包含所有事件、警报、状态更改和由代理收集的性能数据。 Operations Manager 数据库使用的大部分资源在进入系统时用于将此数据写入到磁盘。 随着导入其他管理包和安装其他代理，收集的操作数据速率往往会增加。 代理监视的计算机类型也是在确定操作数据收集的总速率时使用的一个重要因素。 例如，监视关键业务的台式计算机的代理预期收集的数据可能会比监控运行具有大量数据库的 SQL Server 实例的服务器的代理要少。
• 实例空间更改的速率。 更新 Operations Manager 数据库中的此数据相对于写入新操作数据的成本要高。 此外，当实例空间数据更改时，管理服务器对 Operations Manager 数据库进行其他查询，以计算配置和组更改。 将其他管理包导入到管理组时，实例空间的更改速率会提高。 将新代理添加到管理组也会暂时提高实例空间的更改速率。
• 操作控制台数和同时运行的其他 SDK 连接数。 每个操作控制台从 Operations Manager 数据库读取数据。 查询此数据会可能消耗很大的存储 I/O 资源、CPU 时间和 RAM。 在事件视图、状态视图、警报视图和性能数据视图中显示大量操作数据的操作控制台有可能导致数据库上的最大负载。

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 中观察到任务发生意外行为时，检查 Service Broker SQL Server 的状态非常重要。

若要启用 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 Manager 数据库中的负载。

影响报表数据仓库上的负载的因素包括：

• 操作数据集合的速率。 为了进行更高效的报告，报表数据仓库还会计算并存储除有限原始数据以外的聚合数据。 执行这种额外的工作意味着，对报表数据仓库的操作数据收集可能比对 Operations Manager 数据库的成本要稍高一些。 通常，通过报表数据仓库与 Operations Manager 数据库处理发现数据可降低成本，以平衡此附加成本。
• 并发报表用户或计划的报表生成数。 因为报表通常汇总大量数据，每个报表用户都可以在系统上添加大量负载。 同时运行的报表份数和正在运行的报表类型将影响整体容量需求。 通常情况下，查询较大日期范围的报表或大量的对象需要更多系统资源。

根据这些因素，调整报表数据仓库大小时，要考虑几个推荐做法：

• 选择适当的存储子系统。 因为报表数据仓库是管理组中总体数据流的组成部分，为报表数据仓库选择适当的存储子系统非常重要。 和 Operations Manager 数据库一样，RAID 0 + 1 通常是最佳选择。 一般情况下，报表数据仓库的存储子系统应类似于 Operations Manager 数据库的存储子系统，并且适用于 Operations Manager 数据库的指南也适用于报表数据仓库。
• 请考虑数据日志与事务日志的适当位置。 对于 Operations Manager 数据库，在扩展代理的数量时，分隔 SQL 数据日志和事务日志通常是一个适当的选择。 如果 Operations Manager 数据库和报表数据仓库位于同一台服务器上，而你想要单独的数据日志和事务日志，则必须将 Operations Manager 数据库的事务日志置于从报表数据仓库独立出来的物理卷和磁盘心轴上，以获得其优势。 Operations Manager 数据库和报表数据仓库的数据文件可以共享相同的物理卷，前提是该卷提供足够的容量且磁盘 I/O 性能不会对监视和报告功能产生负面影响。
• 考虑将报表数据仓库置于 Operations Manager 数据库中的单独服务器上。 尽管规模较小的部署通常可以在同一服务器上合并 Operations Manager 数据库和报表数据仓库，但在纵向扩展代理数和传入操作数据量时，最好将其分开。 报表数据仓库和报表服务器在与 Operations Manager 数据库独立的服务器上时，你可以体验更好的报告性能。

Operations Manager 数据仓库数据库是管理组的单一故障源，因此它可以使用受支持的故障转移配置变得高度可用，如 SQL Server AlwaysOn 可用性组或故障转移群集实例。

SQL Server AlwaysOn

SQL Server AlwaysOn 可用性组针对一组离散的用户数据库（可用性数据库）支持故障转移环境。 每组可用性数据库由可用性副本承载。

在 System Center 2016 和更高版本 - Operations Manager 中，SQL AlwaysOn 可优于故障转移群集来为数据库提供高可用性。 所有数据库都可以都托管在 AlwaysOn 可用性组中，除了使用两个数据库将永久性数据存储与临时存储要求分开的本机模式 Reporting Services 安装以外。

在 Operations Manager 2022 中，可以使用现有的 SQL Always-On 设置来设置和升级 Operations Manager 数据库，而无需进行任何后期配置更改。

若要设置可用性组，需要部署 Windows Server 故障转移群集 (WSFC) 群集来托管可用性副本 (replica) ，并在群集节点上启用Always On。 然后可将 Operations Manager SQL Server 数据库添加为可用性数据库。

• 详细了解Always On先决条件。
• 详细了解如何为Always On可用性组设置 WSFC。
• 详细了解 如何设置可用性组。

注意

在参与 SQL Always On 的 SQL Server 节点上部署 Operations Manager 之后，若要启用 CLR 严格安全性，请对每个 Operations Manager 数据库运行 SQL 脚本。

多子网字符串

Operations Manager 不支持 multiSubnetFailover=True) (连接字符串关键字。 由于可用性组具有取决于不同子网中的多个 IP 地址的侦听程序名称（在 WSFC 客户端群集中被称为网络名称或客户端接入点），因此在跨站点故障转移配置中进行部署时，从管理服务器到可用性组侦听程序的客户端连接请求将遇到连接超时。

在多子网环境中在可用性组中部署服务器节点时，若要绕过此限制，建议的方法是执行以下操作：

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 Data Access 服务会重启。 有关如何配置此功能的信息，请参阅以下知识库文章：在 SQL Server 的某个实例处于脱机状态后，System Center Management 服务会停止响应。

优化 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 中非常明显。

在部署SQL Server之前，通过执行 IO 子系统的吞吐量测试来测试SQL Server设计非常重要。 确保这些测试能够以可接受的延迟满足 IO 要求。 使用 Diskspd 实用工具评估支持 SQL Server 的存储子系统 I/O 容量。 以下博客文章由产品组中文件服务器团队的成员创作，提供了有关如何使用此工具执行压力测试的详细指导和建议，以及一些 PowerShell 代码，并使用 PerfMon 捕获结果。 也可以参考 Operations Manager Sizing Helper 获取初步指导。

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 卡、管理代理和防病毒实时扫描。 如果没有设置足够的内存，操作系统和 SQL 将分页到磁盘。 这会导致磁盘 I/O 增加，进一步降低性能，进而产生连锁反应，这种影响在 Operations Manager 中尤为明显。

建议为“最小服务器内存”指定至少 4 GB 的 RAM。 应为承载 Operations Manager 数据库之一（操作、数据仓库、ACS）的每个 SQL 节点进行此设置。

对于“最大服务器内存”，我们建议你最初总共预留：

• 为操作系统预留 1 GB 的 RAM
• 每安装 4 GB RAM 1 GB RAM (最多 16 GB RAM)
• 每个安装的 8-GB RAM (超过 16 GB RAM)

设置完这些值后，在 Windows 中监视 Memory\Available MBytes 计数器，确定是否可以增加 SQL Server 的可用内存。 Windows 指示可用物理内存在 96 MB 处运行不足，因此理想情况下计数器的运行不应低于大约 200-300 MB，以确保你有缓冲区。 对于 RAM 为 256 GB 或更高的服务器，可能需要确保其运行不超过 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、x64 和 IA64 系统对应的堆栈大小分别为 512 KB、2 MB 和 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 的“页生存期”和“页读取数/秒”以及物理磁盘的“磁盘读取数/秒”值。 如果环境中有多余的内存，“页生存期”将以每秒 1 GB 的值增加，由于缓存的原因，该值在工作负荷下不会有任何减少；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) 计算机，还是启用超线程的处理器，必须相应地配置最大并行度选项。

当在具备多个微处理器或 CPU 的计算机上运行 SQL Server 时，它将检测最佳并行度，即用于每个并行计划执行的运行单个语句的处理器数。 默认情况下，此选项的值为 0，它允许 SQL Server 确定最大并行度。

Operations Manager 中预定义的存储过程和查询（因为它与操作、数据仓库甚至审核数据库相关）不包含 MAXDOP 选项，因为安装期间无法动态查询向操作系统提供的处理器数量，也不会尝试对此设置的值进行硬编码，在执行查询时可能会产生负面影响。

注意

最大并行度配置选项不会限制SQL Server使用的处理器数。 若要配置 SQL Server 使用的处理器数，请使用关联掩码配置选项。

• 对于使用 8 个以上处理器的服务器，请使用以下配置：MAXDOP = 8
• 对于使用 8 个或更少处理器的服务器，请使用以下配置：MAXDOP=0 到 N

  注意

  在此配置中，N 表示处理器数。