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 关系数据库服务（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（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 的升级信息。

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

SQL Server 2016 和此处提供的最新更新
SQL Server 2014 和此处提供的最新更新
SQL Server 2012 和此处提供的最新更新

SQL Server 驱动程序

需要在所有管理服务器和 Web 控制台服务器上安装 OLE DB 和 ODBC SQL Server 驱动程序，因为这些组件直接与数据库接口，并且这些驱动程序允许 API 级别访问 SQL。

建议使用加密的 SQL Server 连接;执行此操作时，需要安装最新版本的 SQL 驱动程序：

Microsoft OLE DB 驱动程序最新版本。
Microsoft ODBC 驱动程序最新版本。

有关配置 SQL 连接加密的详细信息，可在此处找到：配置 SQL Server 数据库引擎以加密连接

如果未使用加密的 SQL 连接，请使用以前版本的不强制加密的 SQL 驱动程序：

Microsoft ODBC 驱动程序版本 17.10.6。
Microsoft OLE DB 驱动程序版本 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、Server With Desktop Experience 和 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 AlwaysOn 可用性组的分布式部署，则需要在防火墙安全策略中包含额外的防火墙配置设置。

下表标识 SQL Server 所需的防火墙端口，以便管理服务器与数据库通信：

场景	端口	方向	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 数据库负载的因素包括：

操作数据收集率。
- 操作数据收集速率受因素影响，例如导入的管理包数、添加的代理数和所监视的计算机的类型。例如，与监视具有多个数据库的 SQL Server 的服务器运行的代理相比，监视业务关键型台式计算机的代理收集的数据更少。
实例空间更改率。
- 与写入新的操作数据相比，更新 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，请执行以下步骤：

运行以下 SQL 查询，检查是否已启用中转站，该字段中的结果为 1（1is_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 AlwaysOn 可用性组或故障转移群集实例）实现高可用性。

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 先决条件。
详细了解如何为 AlwaysOn 可用性组设置 WSFC。
详细了解如何设置可用性组。

提示

从 Operations Manager 2022 开始，可以使用现有的 SQL Always-On 安装程序设置和升级 Operations Manager 数据库，而无需进行任何配置更改。

详细了解 AlwaysOn 先决条件。
详细了解如何为 AlwaysOn 可用性组设置 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。

可以在当前托管侦听器的 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 容量。以下博客文章由产品组中文件服务器团队的成员创作，提供了有关如何使用此工具执行压力测试的详细指导和建议 - DiskSpd、PowerShell 和存储性能：测量本地磁盘和 SMB 文件共享的 IOP、吞吐量和延迟。

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 定义的大小太小，则每次重启 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 的启动参数中实现跟踪标志，以便跟踪标志-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 使用的处理器数，请使用关联掩码配置选项。

对于使用 8 个以上的处理器的服务器，请使用以下配置：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 数据库的实例的 MAXMEM 设置为 64 GB。执行本部分中建议的优化后，性能得到了改进。但是，查询并行度瓶颈仍然存在。测试不同的值后，通过设置 MAXDOP=4 找到最佳性能。

初始数据库大小调整

尝试在部署后的头几个月内估计 Operations Manager 数据库（特别是运营数据库和数据仓库数据库）的未来增长并不是一个简单的练习。虽然 Operations Manager 大小调整帮助程序根据产品组在实验室中测试派生的公式估算潜在增长是合理的，但它不考虑几个因素，这可能会影响短期内的增长与长期的增长。

根据大小调整帮助程序的建议，初始数据库大小应分配给预测大小，以减少碎片和相应的开销，这些开销可以在操作数据库和数据仓库数据库的设置时指定。如果在设置期间没有足够的存储空间可用，则可以稍后使用 SQL Management Studio 扩展数据库，然后重新编制索引以相应地进行碎片整理和优化。此建议也适用于 ACS 数据库。

应在每日或每周周期内主动监视操作和数据仓库数据库的增长情况。这需要识别意外和显著增长的刺激，并开始进行故障排除，以确定管理包工作流中的 bug（即发现规则、性能或事件收集规则、监视或警报规则）或其他症状（在发布管理过程测试和质量保证阶段未识别的管理包）。

数据库自动增长

当保留的数据库文件大小已满时，SQL Server 可以按百分比或固定数量自动增加大小。此外，可以配置最大数据库大小，以防止填满磁盘上的所有可用空间。默认情况下，Operations Manager 数据库未配置为启用自动增长;只有数据仓库和 ACS 数据库。

只有依靠自动增长作为意外增长的应变。自动增长引入了处理高度事务性数据库时应考虑的性能损失。性能处罚包括：

如果未提供适当的增长增量，则可能会出现日志文件或数据库的碎片。
如果运行的事务需要的日志空间比可用空间多，并且为该数据库的事务日志启用自动增长，则事务完成所需的时间将包括事务日志按配置量增长所需的时间。
如果运行需要日志增长的大型事务，则其他需要写入事务日志的事务也必须等到增长操作完成。

如果自动增长和自动收缩选项组合在一起，则这会产生不必要的开销。确保触发增长和收缩操作的阈值不会导致频繁的上下大小更改。例如，可以运行导致事务日志在提交时增长 100 MB 的事务;之后的一段时间，自动收缩将事务日志收缩 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 设计的必需部分。否则，随着时间，包含事务日志的磁盘将填满。

备份策略必须考虑到环境的详细信息。下表提供了典型的备份计划。

备份类型	计划
仅限事务日志	每一小时
完全	每周，星期日凌晨 3：00

优化 SQL Server Reporting Services

Reporting Services 实例充当对数据仓库数据库中数据的访问的代理。它基于存储在管理包中的模板生成和显示报表。

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

在 Reporting Services 的后台，有一个托管 ReportServer 和 ReportServerTempDB 数据库的 SQL Server 数据库实例。有关此实例性能优化的一般建议适用。

注意

从 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 报表无法部署

后续步骤

若要了解如何在防火墙后面配置托管（报告）数据仓库，请参阅跨防火墙连接（报告）数据仓库。

通过