通过

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 Monitor SCOM 托管实例，它利用 Azure SQL MI，并且不可重新配置。

SQL Server 要求

现有 System Center Operations Manager 版本用于托管报表服务器、操作、数据仓库和 ACS 数据库的现有安装，支持以下版本的 SQL Server Enterprise 和 标准版：

  • SQL Server 2019（累积更新 8）或更高版本，详见 此处

    注意

    • 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）或更高版本，详见 此处

    注意

    • 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 的升级信息。

System Center 2016 - Operations Manager 的新安装或现有安装支持以下版本的 SQL Server Enterprise & 标准版，用于托管报表服务器、操作、数据仓库和 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 安装选项（服务器核心、具有桌面体验的服务器和 Nano 服务器）以 SQL Server 支持的 Windows Server 的安装选项为基础。

注意

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

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

  • 建议在采用 NTFS 文件格式的计算机上运行 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 AlwaysOn 可用性组为 Operations Manager 数据库提供故障转移功能的分布式部署，则需要在防火墙安全策略中包含其他防火墙配置设置。

下表可帮助你确定需要至少允许的 SQL Server 所需的防火墙端口，以便 Operations Manager 管理组中的服务器角色能够成功通信。

场景 端口 方向 Operations Manager 角色
托管 Operations Manager 数据库的 SQL Server TCP 1433 * 入站 管理服务器和 Web 控制台（适用于应用程序顾问和应用程序诊断）
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 AlwaysOn 可用性组侦听器 管理员配置的端口 入站 Management 服务器
托管 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 数据库是一个 SQL Server 数据库，其中包含 Operations Manager 日常监视所需的所有数据。 调整数据库服务器的大小和配置对于管理组的整体性能至关重要。 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 中的任务周围观察到意外行为时，检查 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 Console 使用情况在 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 Always On 可用性组支持针对一组离散用户数据库（可用性数据库）的故障转移环境。 每组可用性数据库都由一个“可用性副本”托管。

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

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

SQL Server AlwaysOn

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>

当群集或 AlwaysOn SQL 实例用于高可用性时，应在管理服务器上启用自动恢复功能，以避免在节点之间发生故障转移时重启 Operations Manager 数据访问服务。 有关如何配置此功能的信息，请参阅以下知识库文章 ：System Center Management 服务在 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 中变得明显。

在部署 SQL Server 之前，通过对 IO 子系统执行吞吐量测试来测试 SQL Server 设计非常重要。 确保这些测试能够以可接受的延迟实现 IO 要求。 使用 Diskspd 实用工具评估支持 SQL Server 的存储子系统的 I/O 容量。 以下博客文章由产品组中文件服务器团队的成员创作，提供有关如何使用此工具执行压力测试的详细指导和建议，以及 如何使用 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）

并不总是很容易识别正确的物理内存量和处理器，以便为 SQL Server 分配以支持 System Center Operations Manager（或此产品之外的其他工作负荷）。 产品组提供的大小调整计算器基于工作负荷规模提供指导，但其建议基于实验室环境中执行的测试，这些测试可能与实际工作负荷和配置不一致。

SQL Server 允许 配置其进程将保留和使用的最低内存量和最大内存 量。 默认情况下，SQL Server 可以根据可用的系统资源动态更改其内存要求。 最小服务器内存的默认设置为 0，最大服务器内存的默认设置为 2,147,483,647 MB。

如果未为 最大服务器内存设置适当的值，则可能会出现与性能和内存相关的问题。 许多因素会影响分配给 SQL Server 所需的内存量，以确保操作系统可以支持在该系统上运行的其他进程，例如 HBA 卡、管理代理和防病毒实时扫描。 如果未设置足够的内存，OS 和 SQL 将分页到磁盘。 这可能会导致磁盘 I/O 增加、进一步降低性能，并产生连锁反应，在 Operations Manager 中变得明显。

建议至少为 最小服务器内存指定 4 GB RAM。 这应该针对托管其中一个 Operations Manager 数据库（操作、数据仓库、ACS）的每个 SQL 节点执行此操作。

对于 最大服务器内存，建议最初保留总计：

  • OS 的 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 能够使用所有可用内存，除非修改它们以考虑其他应用程序。 请考虑 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 系统，可以在 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 定义的大小太小，则系统处理负载的一部分可能会占用自动增长 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 中预定义的存储过程和查询，因为它与操作、数据仓库甚至审核数据库都不包含 MAXDOP 选项，因为安装过程中无法动态查询向操作系统呈现多少个处理器，也不会尝试对此设置的值进行硬编码，这可能会在执行查询时产生负面影响。

注意

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

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

    注意

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