你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
适用于 SAP NetWeaver 的 SQL Server Azure 虚拟机 DBMS 部署
本文档介绍在 Azure IaaS 中部署适用于 SAP 工作负荷的 SQL Server 时要考虑的多个不同领域。 在阅读本文档之前，应首先阅读文档适用于 SAP 工作负载的 Azure 虚拟机 DBMS 部署的注意事项以及 Azure 上的 SAP 工作负载文档中的其他指南。
重要
本文档的范围涵盖 SQL Server 上的 Windows 版本。 SAP 不支持带有任何 SAP 软件的 Linux 版 SQL Server。 本文档不讨论 Microsoft Azure Platform 的“平台即服务”产品 - Microsoft Azure SQL 数据库。 本文讨论的是如何运行 SQL Server 产品（已知适用于 Azure 虚拟机中的本地部署），以及如何运用 Azure 的“基础结构即服务”功能。 这两种产品/服务的数据库性能与功能差异很大，不应混用。 有关详细信息，请参阅 Azure SQL 数据库。
通常应考虑使用最新的 SQL Server 版本在 Azure IaaS 中运行 SAP 工作负荷。 最新的 SQL Server 版本提供与一些 Azure 服务和功能的更好集成。 或者具有优化 Azure IaaS 基础结构中操作的更改。
有关在 Azure 虚拟机 (VM) 中运行的 SQL Server 的一般性文档，请参阅以下文章：
- Azure 虚拟机 (Windows) 上的 SQL Server
- 使用 Windows SQL Server IaaS 代理扩展实现自动管理
- 为 Azure VM (Resource Manager) 上的 SQL Server 配置 Azure 密钥保管库集成
- 清单：有关 Azure VM 上 SQL Server 的最佳做法
- 存储：Azure VM 上的 SQL Server 的性能最佳做法
- HADR 配置最佳做法（Azure VM 上的 SQL Server）
并非 Azure VM 中的 SQL Server 一般性文档中的所有内容和语句都适用于 SAP 工作负载。 但是，该文档让人对原则印象深刻。 SAP 工作负载不支持的功能的一个示例是 FCI 群集的使用。
在继续操作之前，应该先了解 IaaS 中 SQL Server 的一些特定信息：
- SQL 版本支持：即使 SAP 说明 #1928533 指出支持的最低 SQL Server 版本为 SQL Server 2008 R2，Azure 上支持的 SQL Server 版本的时段仍取决于 SQL Server 的生命周期。 SQL Server 2012 延长维护期已于 2022 年年中结束。 因此，新部署系统的当前最低版本应为 SQL Server 2014。 版本越新越好。 最新的 SQL Server 版本提供与一些 Azure 服务和功能的更好集成。 或者具有优化 Azure IaaS 基础结构中操作的更改。
- 使用来自 Azure 市场的映像：部署新 Microsoft Azure VM 的最快方式是使用来自 Azure 市场的映像。 Azure 市场提供包含最新 SQL Server 版本的映像。 已经安装 SQL Server 的映像不能立即用于 SAP NetWeaver 应用程序。 原因在于这些映像中安装了默认的 SQL Server 排序规则，而不是 SAP NetWeaver 系统所需的排序规则。 若要使用此类映像，请查看使用来自 Microsoft Azure 市场的 SQL Server 映像一章中所述的步骤。
- 单个 Azure VM 内的 SQL Server 多实例支持：支持此部署方法。 但是，请注意资源限制，尤其是所用 VM 类型的网络和存储带宽。 有关详细信息，请参阅 Azure 中的虚拟机大小一文。 这些配额限制可能会导致你无法实现与本地可以实现的多实例体系结构相同的体系结构。 至于在单个 VM 内共享可用资源的配置和干扰，需要考虑与本地相同的事项。
- 单个 VM 内单个 SQL Server 实例中的多个 SAP 数据库：支持此类配置。 共享单个 SQL Server 实例中共享资源的多个 SAP 数据库的注意事项与本地部署相同。 请注意其他限制，例如可以附加到特定 VM 类型的磁盘数。 或者，特定 VM 类型的网络和存储配额限制，详见 Azure 中的虚拟机大小。
新的 M 系列 VM 和 SQL Server
Azure 在 Mv3 系列下发布了一些新的 M 系列 SKU。 此系列中的某些 VM 类型不适合用于 SQL Server（包括 SQL Server 2022），除非在 Windows Server 来宾操作系统中禁用 SMT（超线程）。 原因是 Windows Server 来宾操作系统中呈现的 NUMA 节点数超过 64 个 vCPU，这超出了 SQL Server 可以处理的上限。 通过在 Windows Server 来宾操作系统中禁用 SMT，将减少 vCPU 的数量。 因此，每个 NUMA 节点中的 vCPU 数小于 64 个。 有关如何禁用 SMT 的信息，请参阅此处。 特定的 VM 类型包括：
- M176（d）s_3_v3 - 禁用 SMT 或使用 M176bds_4_v3 或 M176bds_4_v3 作为替代项
- M176(d)s_4_v3 - 禁用 SMT 或使用 M176bds_4_v3 作为替代项
- M624(d)s_12_v3 - 禁用 SMT 或使用 M416ms_v2 作为替代项
- M832(d)s_12_v3 - 禁用 SMT 或使用 M416ms_v2 作为替代项
- M832i(d)s_16_v3 - 禁用 SMT 或使用 M416ms_v2 作为替代项
注意
对于某些新的 M(b)v3 VM 类型，使用读取缓存的高级 SSD v1 存储可能会导致读取和写入 IOPS 速率和吞吐量低于不使用读取缓存时的情况。
适用于 SAP 相关 SQL Server 部署的 VM/VHD 结构建议
根据常规说明，操作系统、SQL Server 可执行文件和 SAP 可执行文件应位于或安装在单独的 Azure 磁盘中。 通常情况下，SAP NetWeaver 工作负载对大部分 SQL Server 系统数据库的使用率都不会很高。 尽管如此，SQL Server 的系统数据库应与其他 SQL Server 目录一起放在单独的 Azure 磁盘上。 SQL Server tempdb 应位于 nonperisisted D:\ 驱动器或单独的磁盘上。
- 使用所有 SAP 认证的 VM 类型（请参阅 SAP 说明 #1928533），tempdb 数据和日志文件都可放置在非持久性驱动器 D:\ 上。
- 对于 SQL Server 版本（其中 SQL Server 将安装仅包含一个数据文件的 tempdb），建议使用多个 tempdb 数据文件。 请注意，D:\ 驱动器卷因 VM 类型而表现出大小和功能差异。 有关不同 VM 的驱动器 D:\ 精确大小的信息，请参阅 Azure 中 Windows 虚拟机的大小。
这些配置使 tempdb 能够占用更多空间，更重要的是，占用比系统驱动器能够提供的更多的每秒 I/O 操作 (IOPS) 和存储带宽。 非持久性 D:\ 驱动器还能提供更好的 I/O 延迟和吞吐量。 若要确定正确的 tempdb 大小，可以在现有系统上检查 tempdb 大小。
注意
将 tempdb 数据文件和日志文件放入在驱动器 D:\ 上创建的文件夹时，需要确保 VM 重启后，该文件夹存在。 由于 VM 重启后可新初始化驱动器 D:\，所有文件和目录结构均可清除。本文中记录了在启动 SQL Server 服务之前，有可能在驱动器 D:\ 上重新创建最终目录结构。
运行包含 SAP 数据库的 SQL Server 且 tempdb 数据和 tempdb 日志文件放置于 D:\ 驱动器和 Azure 高级存储 v1 或 v2 的 VM 配置应如下所示：
该图显示了一个简单事例。 正如适用于 SAP 工作负荷的 Azure 虚拟机 DBMS 部署注意事项一文中所提到的一样，Azure 存储类型、磁盘的数量和大小取决于不同的因素。 但是通常我们建议：
- 对于小型和中型部署，使用一个大型卷，其中包含 SQL Server 数据文件。 此配置背后的原因是，如果 SQL Server 数据文件没有相同的可用空间，这样就更易于处理不同的 I/O 工作负载。 而在大型部署中，尤其是某些部署中，客户使用异质数据库迁移来移动至 Azure 中的 SQL Server，我们使用了单独的磁盘，然后将数据文件分发到这些磁盘中。 只有每个磁盘具有相同数量的数据文件、所有数据文件大小相同且大致具有相同可用空间时，此类体系结构才会成功。
- 只要性能足够好，就可以为 tempdb 使用驱动器 D:\。 如果位于驱动器 D:\ 上的 tempdb 的性能限制了整体工作负载，则需要按照本文中的建议将 tempdb 移动到 Azure 高级存储 v1 或 v2 或超级磁盘。
SQL Server 按比例填充机制将读写平均分配到所有数据文件，前提是所有 SQL Server 数据文件大小都相同且可用空间相同。 当读写被均匀分配到所有可用数据文件上时，SQL Server 上的 SAP 将提供最佳性能。 如果数据库的数据文件过少或现有数据文件极度不平衡，则纠正的最佳方法是 R3load 导出和导入。 R3load 导出和导入涉及停机时间，并且应该只在出现需要解决的明显性能问题时执行此操作。 如果数据文件的大小仅稍有不同，请将所有的数据文件增加到相同的大小，然后 SQL Server 会随着时间的推移重新平衡数据。 如果设置了跟踪标志 1117，或者在没有跟踪标志的情况下使用了 SQL Server 2016 或更高版本，SQL Server 将自动均匀增长数据文件。
专用于 M 系列 VM
对于 Azure M 系列 VM，使用 Azure 写入加速器时，与 Azure 高级存储性能 v1 相比，可减少写入事务日志的延迟。 如果高级存储 v1 提供的延迟限制了 SAP 工作负载的可伸缩性，则可以为写入加速器启用存储 SQL Server 事务日志文件的磁盘。 有关详细信息，请阅读文档写入加速器。 Azure 写入加速器不适用于 Azure 高级存储 v2 和超级磁盘。 在这两种情况下，延迟都优于 Azure 高级存储 v1 提供的内容。 写入加速器不支持高级 SSD v2。
注意
对于某些新的 M(b)v3 VM 类型，使用读取缓存的高级 SSD v1 存储可能会导致读取和写入 IOPS 速率和吞吐量低于不使用读取缓存时的情况。
格式化磁盘
对于 SQL Server，包含 SQL Server 数据和日志文件的磁盘的 NTFS 块大小应该为 64 KB。 不需要将 D:\ 驱动器格式化。 此驱动器已预先格式化。
为避免还原或创建数据库时通过清空文件内容来初始化数据文件，请确保 SQL Server 服务运行所在的用户上下文具有用户权限“执行卷维护任务”。 有关详细信息，请参阅数据库即时文件初始化。
SQL Server 2014 及 SQL Server 的更新版本 - 将数据库文件直接存储在 Azure Blob 存储上
SQL Server 2014 及更新版本提供了一种可能性：将数据库文件直接存储在 Azure Blob 存储上，而不需要用 VHD 来“包装”。 此功能旨在解决数年前 Azure 块存储的缺陷。 现在，不建议使用此部署方法，可改为选择 Azure 高级存储 v1、高级存储 v2 或超级磁盘。 具体取决于要求。
SQL Server 的备份/恢复注意事项
将 SQL Server 部署到 Azure 中时，需要查看备份体系结构。 即使系统不是生产系统，也必须定期备份 SQL Server SAP 数据库。 由于 Azure 存储会保留三个映像，因此，在补救存储崩溃方面，备份现在已变得不太重要。 维护适当的备份和恢复计划的首要原因对于补偿逻辑/手动错误的时间点恢复功能重要。 目标是使用备份将数据库还原到某个时间点， 或者是使用 Azure 中的备份，以通过复制现有数据库备份为另一个系统设定种子。
可通过多种方式在 Azure 中备份和还原 SQL Server 数据库。 若要获取最佳概述和详细信息，请阅读文档 Azure VM 上 SQL Server 的备份和还原。 本文介绍了多种不同的可能性。
使用来自 Microsoft Azure 市场的 SQL Server 映像
Microsoft 在 Azure 市场中提供已经包含 SQL Server 版本的 VM。 对于需要 SQL Server 和 Windows 许可证的 SAP 客户，通过运行已安装 SQL Server 的 VM，使用这些映像可能满足对许可证的需求。 若要针对 SAP 使用此类映像，必须注意以下事项：
- SQL Server 非评估版的购置成本高于从 Azure 市场部署的“仅限 Windows”VM。 若要比较价格，请参阅 Windows 虚拟机定价和 SQL Server Enterprise 虚拟机定价。
- 你只能使用 SAP 为其软件支持的 SQL Server 版本。
- 安装于 VM（来自 Azure 市场）中的 SQL Server 实例的排序规则并不是 SAP NetWeaver 要求 SQL Server 实例运行的排序规则。 不过，可以遵循下一节的指示来更改排序规则。
更改 Microsoft Windows/SQL Server VM 的 SQL Server 排序规则
由于 Azure 市场中的 SQL Server 映像未设置为使用 SAP NetWeaver 应用程序所需的排序规则，因此需要在部署之后立即对其进行更改。 对于 SQL Server，一旦部署了 VM 且管理员能够登录已部署的 VM，就可以使用下列步骤来完成排序规则的更改：
- 以管理员身份打开 Windows 命令窗口。
- 将目录更改为 C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012。
- 执行命令：Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=
<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2<local_admin_account_name> 是第一次通过库部署 VM 时定义为管理员帐户的帐户。
此过程应该只需要几分钟的时间。 若要确保此步骤最终会有正确的结果，请执行下列步骤：
- 打开 SQL Server Management Studio。
- 打开查询窗口。
- 在 SQL Server master 数据库中执行 sp_helpsort 命令。
所需的结果应如下所示：
Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data
如果结果不同，请停止任何部署，并调查为什么安装命令未按预期运行。 对于 NetWeaver 部署，不支持将 SAP NetWeaver 应用程序部署到 SQL Server 代码页与上述代码页不同的 SQL Server 实例。
Azure 中适用于 SAP 的 SQL Server 高可用性
在用于 SAP 的 Azure IaaS 部署中使用 SQL Server，可增加几种不同的可能方法来部署高可用性数据库层。 对于使用不同 Azure 块存储的单个 VM、在某一 Azure 可用性集中部署的一对 VM 或在 Azure 可用性区域之间部署的一对 VM，Azure 为其提供不同的运行时间 SLA。 对于生产系统，我们希望你在虚拟机规模集中部署一对 VM，并在两个可用性区域之间实现灵活的业务流程。 有关详细信息，请参阅 SAP 工作负荷的不同部署类型的比较。 一个 VM 将运行活动的 SQL Server 实例。 其他 VM 将运行被动实例
使用 Windows 横向扩展文件服务器或 Azure 共享磁盘的 SQL Server 群集
借助 Windows Server 2016，Microsoft 引入了存储空间直通。 根据存储空间直通部署，通常支持 SQL Server FCI 群集。 Azure 还提供可用于 Windows 群集的 Azure 共享磁盘。 对于 SAP 工作负载，我们不支持这些 HA 选项。
SQL Server 日志传送
一个高可用性功能是 SQL Server 日志传送。 如果参与 HA 配置的 VM 具有有效的名称解析，那么不会出现问题。 Azure 中的设置与本地进行的任何有关设置日志传送和日志传送原则的设置没有区别。 有关 SQL Server 日志传送的详细信息，请参阅关于日志传送 (SQL Server) 一文。
几乎不在 Azure 中使用 SQL Server 日志传送功能来实现一个 Azure 区域内的高可用性。 但是，在以下场景中，SAP 客户成功将日志传送与 Azure 结合使用：
- 从一个 Azure 区域到另一个 Azure 区域的灾难恢复场景
- 从本地到 Azure 区域的灾难恢复配置
- 从本地到 Azure 切换的场景。 在这些情况下，日志传送用于将 Azure 中的新数据库部署与本地正在进行的生产系统同步。 在进行直接转换时，生产将会关闭并确保将最后和最新的事务日志备份传输到 Azure 数据库部署。 然后将会打开 Azure 数据库部署以用于生产。
SQL Server Always On
由于 AlwaysOn 受本地 SAP 支持（请参阅 SAP 说明 #1772688），因此，支持在 Azure 中将其与 SAP 搭配。 关于部署 SQL Server 可用性组侦听程序（不要与 Azure 可用性集混淆），有一些特殊注意事项。 因此，需要执行一些不同的安装步骤。
以下是使用可用性组侦听器的一些注意事项：
- 只有将 Windows Server 2012 或更高版本作为 VM 的来宾 OS 时，才支持使用可用性组侦听器。 对于 Windows Server 2012，确保已应用更新以在 Windows Server 2008 R2 和基于 Windows Server 2012 的 Microsoft Azure 虚拟机上启用 SQL Server 可用性组侦听器。
- 对于 Windows Server 2008 R2，此修补程序并不存在。 在这种情况下，需要以使用数据库镜像的方式使用 Always On。 通过在连接字符串中指定故障转移伙伴（通过 SAP default.pfl 参数 dbs/mss/server 完成 - 请参阅 SAP 说明 #965908）。
- 使用可用性组侦听程序时，需要将数据库 VM 连接到专用负载均衡器。 应该在 Always On 配置中为这些 VM 的网络接口分配静态 IP 地址（有关如何定义静态 IP 地址的信息，请参阅此文）。 与 DHCP 相比，静态 IP 地址可在两个 VM 都可能停止的情况下阻止分配新 IP 地址。
- 构建群集需要分配特殊 IP 地址的 WSFC 群集配置时，需执行一些特殊的步骤，因为 Azure 及其当前功能会为群集名称分配与创建群集所在的节点相同的 IP 地址。 此行为表示必须执行手动步骤，为群集分配不同的 IP 地址。
- 可用性组侦听器将创建于具有 TCP/IP 终结点的 Azure 中，这些终结点会分配给运行可用性组主要和次要副本的 VM。
- 可能需要使用 ACL 来保护这些终结点。
有关在 Azure VM 中使用 SQL Server 部署 Always On 的详细文档列表如下：
- 介绍 Azure 虚拟机上的 SQL Server Always On 可用性组。
- 在位于不同区域的 Azure 虚拟机上配置 Always On 可用性组。
- 在 Azure 中为 Always On 可用性组配置负载均衡器。
- HADR 配置最佳做法（Azure VM 上的 SQL Server）
注意
阅读介绍 Azure 虚拟机上的 SQL Server Always On 可用性组，你将了解 SQL Server 的直接网络名称 (DNN) 侦听器。 此新功能已在 SQL Server 2019 CU8 中引入。 此新功能利用 Azure 负载均衡器来处理已过时可用性组侦听程序的虚拟 IP 地址。
SQL Server Always On 是 Azure 中用于 SAP 工作负荷部署的最常用高可用性和灾难恢复功能。 大多数客户在单个 Azure 区域内使用 Always On 实现高可用性。 如果部署仅限于两个节点，则有两种连接选择：
- 使用可用性组侦听程序。 若使用可用性组侦听程序，需要部署 Azure 负载均衡器。
- 在 Windows Server 2016 或更高版本上使用 SQL Server 2016 SP3、SQL Server 2017 CU 25 或 SQL Server 2019 CU8 或更高的 SQL Server 版本时，可使用直接网络名称 (DNN) 侦听器，而不是 Azure 负载均衡器。 DNN 不再需要使用 Azure 负载均衡器。
使用 SQL Server 数据库镜像的连接参数应仅在使用其他两种方法调查问题时考虑。 在此情况下，需要以命名两个节点名称的方式配置 SAP 应用程序的连接。 有关此类 SAP 端 配置的确切详细信息，请参阅 SAP 说明 #965908。 通过使用此选项，无需配置可用性组侦听程序。 这样一来，没有 Azure 负载均衡器可以调查这些组件的问题。 但请记住，此选项仅在将可用性组限制为跨两个实例时适用。
大多数客户正在使用 SQL Server Always On 功能在 Azure 区域之间实现灾难恢复功能。 少数客户还使用此功能从次要副本执行备份。
SQL Server 透明数据加密
许多客户在 Azure 中部署 SAP SQL Server 数据库时，使用 SQL Server 透明数据加密 (TDE)。 SAP 完全支持 SQL Server TDE 功能（请参阅 SAP 说明 #1380493）。
应用 SQL Server TDE
如果从另一个本地运行的数据库执行异类迁移到 Azure 中运行的 Windows/SQL Server，则应提前在 SQL Server 中创建空的目标数据库。 下一步，对这个空数据库应用 SQL Server TDE 功能。 希望在此序列中执行的原因是，加密空数据库的进程可能需要相当长一段时间。 然后 SAP 导入进程将在停机阶段将数据导入加密数据库。 与在停机阶段的导出阶段之后加密数据库的开销相比，导入到加密数据库的开销的时间影响更小。 尝试在数据库上运行 SAP 工作负载情况下应用 TDE 时，会产生不好的体验。 因此，建议将 TDE 部署视为需要在特定数据库上具有较低或没有 SAP 工作负载的情况下完成的活动。 从 SQL Server 2016 开始，可以停止并继续执行初始加密的 TDE 扫描。 透明数据加密 (TDE) 文档介绍了命令和详细信息。
将 SAP SQL Server 数据库从本地移动到 Azure 时，我们建议测试在其上可最快应用加密的基础结构。 对此，请记住以下内容：
- 不能定义用于将数据加密应用于数据库的线程数。 线程数主要取决于 SQL Server 数据和日志文件分布的磁盘卷数。 这意味着不同的卷（驱动器号）越多，并行执行加密的线程就会越多。 此类配置与之前的磁盘配置建议有点矛盾，该建议是在 Azure VM 中为 SQL Server 数据库文件构建一个或少量存储空间。 具有少量卷的配置将导致一些线程执行加密。 单个线程加密正在读取 64 KB 的盘区、对其进行加密，然后将记录写入事务日志文件，同时告知已加密盘区。 因此，事务日志上的负载适中。
- 在较旧的 SQL Server 版本中，加密 SQL Server 数据库时，备份压缩不再有效。 当计划在本地加密 SQL Server 数据库，然后将备份复制到 Azure 以还原 Azure 中的数据库时，这种行为可能会发展成一个问题。 SQL Server 备份压缩可实现因子为 4 的压缩比。
- 对于 SQL Server 2016，SQL Server 引入了新功能，也允许以高效的方式压缩并备份加密的数据库。 请参阅此博客了解详细信息。
使用 Azure Key Vault
Azure 提供 Key Vault 服务以存储加密密钥。 另一方面，SQL Server 提供了一个连接器，可将 Azure Key Vault 用作 TDE 证书的存储。
有关将 Azure Key Vault 用于 SQL Server TDE 的详细信息列表如下：
- 为 Azure VM (Resource Manager) 上的 SQL Server 配置 Azure Key Vault 集成。
- 客户关于 SQL Server 透明数据加密 - TDE + Azure Key Vault 的更多问题。
重要
使用 SQL Server TDE，尤其是与 Azure Key Vault 搭配使用时，建议使用 SQL Server 2014、SQL Server 2016 和 SQL Server 2017 的最新修补程序。 因为根据客户反馈，优化和修复已应用于代码。 有关示例，请查看 KBA #4058175。
最低部署配置
在本部分中，建议为 SAP 工作负载下不同大小的数据库提供一组最低配置。 很难评估这些大小是否适合特定工作负载。 在某些情况下，与数据库大小相比，我们可能提供大量内存。 另一方面，对于某些工作负载，磁盘大小调整可能太低。 因此，应如实对待这些配置。 这些配置应该会为你提供一个起点。 要根据特定工作负载和成本效益要求进行微调的配置。
数据库大小为 50 GB 到 250 GB 之间的小型 SQL Server 实例的配置示例如下所示
| 配置 | 数据库 VM | 注释 |
|---|---|---|
| VM 类型 | E4s_v3/v4/v5 (4 vCPU/32 GiB RAM) | |
| 加速网络 | 启用 | |
| SQL Server 版本 | SQL Server 2019 或更高版本 | |
| 数据文件数 | 4 | |
| 日志文件数 | 1 | |
| 临时数据文件数 | 4 或默认值（自 SQL Server 2016 开始） | |
| 操作系统 | Windows Server 2019 或更高版本 | |
| 磁盘聚合 | 存储空间（如需要） | |
| 文件系统 | NTFS | |
| 格式块大小 | 64 KB | |
| 数据磁盘的数量和类型 | 高级存储 v1：2 x P10 (RAID0) 高级存储 v2：2 x 150 GiB (RAID0) - 默认 IOPS 和吞吐量或等效的高级 SSD v2 |
缓存 = 只读（对于高级存储 v1） |
| 日志磁盘的数量和类型 | 高级存储 v1：1 x P20 高级存储 v2：1 x 128 GiB - 默认 IOPS 和吞吐量或等效的高级 SSD v2 |
缓存 = 无 |
| SQL Server 最大内存参数 | 90% 的物理 RAM | 假设使用单个实例 |
数据库大小为 250 GB 到 750 GB 之间的小型 SQL Server 实例（例如较小的 SAP Business Suite 系统）配置示例如下所示
| 配置 | 数据库 VM | 注释 |
|---|---|---|
| VM 类型 | E16s_v3/v4/v5 (16 vCPU/128 GiB RAM) | |
| 加速网络 | 启用 | |
| SQL Server 版本 | SQL Server 2019 或更高版本 | |
| 数据文件数 | 8 | |
| 日志文件数 | 1 | |
| 临时数据文件数 | 8 或默认值（自 SQL Server 2016 开始） | |
| 操作系统 | Windows Server 2019 或更高版本 | |
| 磁盘聚合 | 存储空间（如需要） | |
| 文件系统 | NTFS | |
| 格式块大小 | 64 KB | |
| 数据磁盘的数量和类型 | 高级存储 v1：4 x P20 (RAID0) 高级存储 v2：4 x 100 GiB - 200 GiB (RAID0) - 默认 IOPS 和每磁盘 25 MB/秒额外吞吐量或等效的高级 SSD v2 |
缓存 = 只读（对于高级存储 v1） |
| 日志磁盘的数量和类型 | 高级存储 v1：1 x P20 高级存储 v2：1 x 200 GiB - 默认 IOPS 和吞吐量或等效的高级 SSD v2 |
缓存 = 无 |
| SQL Server 最大内存参数 | 90% 的物理 RAM | 假设使用单个实例 |
数据库大小为 750 GB 与 2,000 GB 之间的中型 SQL Server 实例（例如中型的 SAP Business Suite 系统）的配置示例如下所示
| 配置 | 数据库 VM | 注释 |
|---|---|---|
| VM 类型 | E64s_v3/v4/v5 (64 vCPU/432 GiB RAM) | |
| 加速网络 | 启用 | |
| SQL Server 版本 | SQL Server 2019 或更高版本 | |
| 数据设备数量 | 16 | |
| 日志设备数量 | 1 | |
| 临时数据文件数 | 8 或默认值（自 SQL Server 2016 开始） | |
| 操作系统 | Windows Server 2019 或更高版本 | |
| 磁盘聚合 | 存储空间（如需要） | |
| 文件系统 | NTFS | |
| 格式块大小 | 64 KB | |
| 数据磁盘的数量和类型 | 高级存储 v1：4 x P30 (RAID0) 高级存储 v2：4 x 250 GiB - 500 GiB - 加上 2,000 IOPS 和每磁盘 75 MB/秒吞吐量或等效的高级 SSD v2 |
缓存 = 只读（对于高级存储 v1） |
| 日志磁盘的数量和类型 | 高级存储 v1：1 x P20 高级存储 v2：1 x 400 GiB - 默认 IOPS 和 75MB/秒额外吞吐量或等效的高级 SSD v2 |
缓存 = 无 |
| SQL Server 最大内存参数 | 90% 的物理 RAM | 假设使用单个实例 |
数据库大小为 2,000 GB 与 4,000 GB 之间的大型 SQL Server 实例（例如较大的 SAP Business Suite 系统）的配置示例如下所示
| 配置 | 数据库 VM | 注释 |
|---|---|---|
| VM 类型 | E96(d)s_v5 (96 vCPU/672 GiB RAM) | |
| 加速网络 | 启用 | |
| SQL Server 版本 | SQL Server 2019 或更高版本 | |
| 数据设备数量 | 24 | |
| 日志设备数量 | 1 | |
| 临时数据文件数 | 8 或默认值（自 SQL Server 2016 开始） | |
| 操作系统 | Windows Server 2019 或更高版本 | |
| 磁盘聚合 | 存储空间（如需要） | |
| 文件系统 | NTFS | |
| 格式块大小 | 64 KB | |
| 数据磁盘的数量和类型 | 高级存储 v1：4 x P30 (RAID0) 高级存储 v2：4 x 500 GiB - 800 GiB - 加上 2500 IOPS 和每次盘 100 MB/秒吞吐量或等效的高级 SSD v2 |
缓存 = 只读（对于高级存储 v1） |
| 日志磁盘的数量和类型 | 高级存储 v1：1 x P20 高级存储 v2：1 x 400 GiB - 加上 1,000 IOPS 和 75MB/秒额外吞吐量或等效的高级 SSD v2 |
缓存 = 无 |
| SQL Server 最大内存参数 | 90% 的物理 RAM | 假设使用单个实例 |
数据库大小超过 4 TB 的大型 SQL Server 实例（例如在全球范围内使用的大型 SAP Business Suite 系统）配置示例如下所示
| 配置 | 数据库 VM | 注释 |
|---|---|---|
| VM 类型 | M 系列（1.0 到 4.0 TB RAM） | |
| 加速网络 | 启用 | |
| SQL Server 版本 | SQL Server 2019 或更高版本 | |
| 数据设备数量 | 32 | |
| 日志设备数量 | 1 | |
| 临时数据文件数 | 8 或默认值（自 SQL Server 2016 开始） | |
| 操作系统 | Windows Server 2019 或更高版本 | |
| 磁盘聚合 | 存储空间（如需要） | |
| 文件系统 | NTFS | |
| 格式块大小 | 64 KB | |
| 数据磁盘的数量和类型 | 高级存储 v1：4+ x P40 (RAID0) 高级存储 v2：4+ x 1,000 GiB - 4,000 GiB - 加上 4,500 IOPS 和每磁盘 125 MB/秒吞吐量或等效的高级 SSD v2 |
缓存 = 只读（对于高级存储 v1） |
| 日志磁盘的数量和类型 | 高级存储 v1：1 x P30 高级存储 v2：1 x 500 GiB - 加上 2,000 IOPS 和 125 MB/秒吞吐量或等效的高级 SSD v2 |
缓存 = 无 |
| SQL Server 最大内存参数 | 95% 的物理 RAM | 假设使用单个实例 |
例如，此配置为 SQL Server 上 SAP 商业套件的数据库 VM 配置。 此 VM 托管一家全球型公司单个全球 SAP Business Suite 实例的 30TB 数据库，该公司年收入超过 2000 亿美元，全职员工超过 20 万名。 该系统可运行所有财务处理、销售和分销处理，以及来自不同领域的更多业务流程，包括北美薪资事宜。 自 2018 年初以来，该系统一直在 Azure 中运行，并使用 Azure M 系列 VM 作为数据库 VM。 在高可用性方面，系统使用了 Always On 可用性组，其中一个同步副本位于同一 Azure 区域的另一个可用性区域。 另一个异步副本则位于另一个 Azure 区域。 NetWeaver 应用程序层部署在最新的 D(a)/E(a) VM 系列上。
| 配置 | 数据库 VM | 注释 |
|---|---|---|
| VM 类型 | M192dms_v2 (192 vCPU/4,196 GiB RAM) | |
| 加速网络 | 已启用 | |
| SQL Server 版本 | SQL Server 2019 | |
| 数据文件数 | 32 | |
| 日志文件数 | 1 | |
| 临时数据文件数 | 8 | |
| 操作系统 | Windows Server 2019 | |
| 磁盘聚合 | 存储空间 | |
| 文件系统 | NTFS | |
| 格式块大小 | 64 KB | |
| 数据磁盘的数量和类型 | 高级存储 v1：16 x P40 或等效的高级 SSD v2 | 缓存 = 只读 |
| 日志磁盘的数量和类型 | 高级存储 v1：1 x P60 或等效的高级 SSD v2 | 使用写入加速器 |
| tempdb 磁盘的数量和类型 | 高级存储 v1：1 x P30 或等效的高级 SSD v2 | 不缓存 |
| SQL Server 最大内存参数 | 95% 的物理 RAM |
适用于 Azure 上的 SAP 的 SQL Server 总体摘要
本指南提供了许多建议，因此，建议在规划 Azure 部署之前，反复阅读本指南。 但一般而言，请务必遵循最重要的 Azure 上的 SQL Server 特定的建议：
- 使用 Azure 中最具优势的最新 SQLServer 版本，例如 SQL Server 2022。
- 在 Azure 中仔细规划 SAP 系统布局，以平衡数据文件布局和 Azure 限制：
- 不要有太多磁盘，但必须足以确保可以达到所需的 IOPS。
- 只有在需要达到更高的吞吐量时，才在磁盘上划分带区。
- 不要有太多磁盘，但必须足以确保可以达到所需的 IOPS。
- 切勿安装软件或将任何需要持久性的文件放在 D:\ 驱动器上，因为它不是永久性的。 在 Windows 重新启动或 VM 重启时，此驱动器上的任何内容都可能会丢失。
- 使用 SQL Server Always On 可用性组解决方案复制数据库数据。
- 始终使用名称解析，不要依赖 IP 地址。
- 使用 SQL Server TDE 时，应用最新的 SQL Server 修补程序。
- 谨慎使用来自 Azure 市场的 SQL Server 映像。 如果使用 SQL Server 映像，就必须更改实例排序规则，才能在其上安装任何 SAP NetWeaver 系统。
- 按照部署指南中的说明，安装和配置适用于 Azure 的 SAP 主机监视。
后续步骤
阅读文章