在 Azure 虚拟机上运行 SQL Server 的性能注意事项与在盒子上运行 SQL Server 没有什么不同，但是在 Azure 基础架构中还有各种其他可用的优化或注意事项，您需要了解并利用这些优化或注意事项，以便以更低的成本提供可预测的性能。在本章中，我们将讨论这些性能最佳实践，以及在 Azure 虚拟机上运行 SQL Server 的注意事项。

在 Azure 虚拟机上运行 SQL Server 的一个主要区别是，您不再需要存储管理员的帮助。这可能是好的也可能是坏的，因为您现在可以自己控制存储，并且不依赖于存储团队，但是现在，如果存储不能为您提供最佳性能，您就没有其他人可以指责了。在本节中，我们将讨论您需要了解的各种存储注意事项和最佳实践，以便在 Azure 中为您提供优化的性能。

如前所述，Azure 是一个共享的多租户环境，因此 Azure 上的所有服务都有限制，以确保每个帐户都能获得专用的、可预测的存储和计算性能，而不会影响其他帐户。存储帐户充当一个容器，保存操作系统磁盘、临时磁盘和数据磁盘，以及 Azure Blob 存储。每个存储帐户的最大 IOPs 数和入口/出口限制都有限制。入口指的是发送到存储帐户的所有数据，而出口指的是从存储帐户提取的所有数据。

下表列出了标准和高级存储帐户限制:

表 3:标准存储账户限额

| | 注意:以上限制是从今天开始的，将来可能会改变。上表以及关于存储帐户和其他 Azure 服务的最新限制可以在以下文章中找到: https://Azure . Microsoft . com/en-us/documents/articles/Azure-subscription-service-limits/# storagelimits |

如上表所示，存储帐户支持的总请求速率为 20，000 IOPs。如果我们有一个虚拟机以全容量运行磁盘，那么标准存储帐户中可连接到该虚拟机的最大磁盘数为 40 (20000/500 IOPs)，以提供您所需的性能。但是，这并不是一个硬性限制，因此如果超过该值，存储帐户限制可能会生效，并对虚拟机的性能产生负面影响。

建议根据工作负载使用多个独立的存储帐户，以避免因存储延迟而导致的限制和对 SQL Server 性能的负面影响。为了获得最佳性能，存储帐户与虚拟机位于同一位置非常重要。

Azure 存储帐户支持地理冗余，以跨区域跨多个数据中心复制存储内容。这为内容交付网络和类似应用程序提供了高可用性和灾难恢复(HA/DR)以及高性能。但是，存储帐户中的地理冗余并不能保证跨磁盘的写一致性，这使得它实际上不能作为 Azure 中的高可用性/灾难恢复解决方案用于 SQL Server，因为它违反了 SQL Server 的提前写日志记录(WAL)协议，并导致灾难恢复站点上的数据库损坏。

由于地理冗余对于 SQL Server 工作负载不可用，因此为托管 SQL Server 数据磁盘的存储帐户禁用地理冗余是有益的，这样可以避免复制开销并降低存储帐户的每分钟成本。为 SQL Server 创建存储帐户的推荐选项是本地冗余存储(LRS)，它通过三个冗余副本在 Azure 数据中心本地复制存储内容，以提高可用性和可靠性。可以从 Azure 门户或 PowerShell 创建存储帐户。

截至目前，微软 Azure 提供了两种类型的存储产品:

• 标准存储
• 高级存储

Azure 标准存储支持连接到虚拟机的每个数据磁盘高达 500 IOPs。Azure 标准存储数据磁盘支持的 IOPs 可以通过向存储池添加多个磁盘来进一步提升，这相当于软件 RAID 配置。但是，标准存储磁盘不能提供运行 SQL Server 工作负载所需的低延迟。磁盘的高延迟使其成为运行 SQL Server 工作负载的不吸引人的产品，因为 SQL Server 具有固有的高 I/O 密集型工作负载，以及用于将数据读写到数据库和日志文件中的高读/写。

Azure 高级存储支持连接到虚拟机的每个数据磁盘高达 50k IOPs。此外，它在降低磁盘延迟的情况下支持高 IOPs，这使得它成为运行在 Azure 虚拟机上的高性能、输入/输出密集型工作负载的首选，尤其是运行在 Azure 虚拟机上的 SQL Server。

要使用高级存储，您需要创建一个高级存储帐户。这可以从 Azure 门户或通过 PowerShell 创建。Azure 将存储帐户用作操作系统和数据磁盘的容器。如果您想为虚拟机磁盘使用高级存储帐户，则需要使用 DS 系列虚拟机。您可以将标准和高级存储磁盘用于 DS 系列虚拟机。但是您不能将高级存储磁盘用于非 DS 系列虚拟机。高级存储数据磁盘支持的 IOPs 和带宽量取决于高级存储磁盘类型。截至目前，高级存储支持三种类型的磁盘类型，即 P10、P20 和 P30。下表列出了每种类型支持的 IOP 和带宽。此表也可以在以下微软文章中找到:https://azure . Microsoft . com/en-us/documents/articles/storage-premium-storage-preview-portal/# using-premium-storage-for-disks/。

表 4:高级存储帐户磁盘类型

| 高级存储磁盘类型 | P10 | P20 | P30 | | 磁盘容量 | 128 GB | 512 GB | 1024GB （1 兆字节） | | 每个磁盘的 IOPS | Five hundred | Two thousand three hundred | Five thousand | | 每个磁盘的吞吐量 | 每秒 100 兆字节 | 每秒 150 兆字节 | 每秒 200 兆字节 |

| | 注意:虚拟机中磁盘支持的吞吐量和 IOPs 也取决于虚拟机的大小(DS0-DS14)。确保并选择支持足够带宽的虚拟机大小以最大容量运行这些磁盘非常重要。 |

有关 Azure 高级存储的更多详细信息，请参见微软关于该主题的文章:

https://azure . Microsoft . com/en-us/documents/articles/storage-premium-storage-preview-portal/# using-premium-storage-for-disks

对于 SQL Server 工作负载，由于 IO 的性质，建议将数据文件和日志文件的磁盘分开(分别是随机读/写 IO 和顺序写入 IO)。使用高级存储时，对于运行在 Azure 虚拟机上的 SQL Server 工作负载，建议至少将 2 X P30 磁盘连接到专用于用户数据文件和日志文件的虚拟机。将标准存储与存储池一起使用时(如下节所述)，建议至少创建两个存储池，以分隔数据和日志文件的 IO 工作负载。另外，操作系统磁盘和临时磁盘不应用于存储任何数据库文件(包括除 tempdb 之外的系统数据库，这将在下一节中讨论)、备份、错误日志或跟踪文件。换句话说，除了 SQL Server 二进制文件之外，操作系统磁盘不应用于存放任何 SQL Server 文件。

D 和 G 系列虚拟机有一个标记为*D:*的临时驱动器，以及在调配虚拟机时连接到虚拟机的操作系统驱动器。它被称为临时磁盘，因为存储在磁盘中的数据不是持久的，并且在虚拟机每次重新启动时都会丢失。临时磁盘是一个高性能、低延迟的固态硬盘，但由于数据不持久，因此不能用于存储用户数据或日志文件。但是，临时磁盘可用于存储临时数据库或缓冲池扩展(BPE)文件，这些文件在每次重新启动 SQL Server 服务时都会被清理或重新创建。

Tempdb 是 SQL Server 实例中访问次数最多的数据库文件之一，因为大多数查询都需要 tempdb 来进行排序、哈希、版本控制或存储临时表。将临时数据库移动到固态硬盘将提高 SQL Server 工作负载的整体性能，尤其是那些大量使用临时数据库对象的工作负载。

微软产品团队在以下博客中记录了将 tempdb 和 BPE 文件移动到 D 系列虚拟机中的临时磁盘的详细步骤:

http://blogs . TechNet . com/b/data platforminsider/archive/2014/09/25/use-SSDs-in-azure-VMs-to-store-SQL-server-tempdb-and-buffer-pool-extensions . aspx

如前一节所述，建议使用高级存储帐户在 Azure 虚拟机上配置 SQL Server。如果出于某种原因，您希望使用标准存储为 SQL Server 虚拟机配置数据磁盘，建议您使用存储空间在多个数据磁盘上对数据进行条带化。创建存储池和使用存储空间的优势在于，它允许您超过每个磁盘的 IOP。在标准存储中，每个磁盘支持的最大 IOPs 为 500 IOPs，但是您可以在一个存储池中将四个数据磁盘条带化在一起，以支持每个 LUN 接近 2000 IOPs。存储池在一定程度上提高了整体输入输出吞吐量以及存储延迟。

但是，需要注意的是，存储空间是在 Windows8/Windows Server 2012 中引入的。只有运行 Windows 8/Windows Server 2012 的虚拟机才能支持创建存储池和存储空间，以跨多个数据磁盘进行条带化。

对于 SQL Server 工作负载，建议每个虚拟机至少创建两个存储池，一个用于数据文件，另一个用于托管日志文件。将 OLTP 工作负载的条带大小设置为 64 KB，将数据仓库工作负载的条带大小设置为 256 KB，以避免因分区未对齐而影响性能。此外，将列数设置为等于物理磁盘的数量。要配置具有八个以上磁盘的存储空间，您必须使用 PowerShell(而不是服务器管理器用户界面)来显式设置列数以匹配磁盘数。有关如何配置存储空间的更多信息，请参见 Windows PowerShell 中的存储空间 Cmdlets。

以下 PowerShell 代码片段可用于在 SQL Server Azure 虚拟机中创建存储池。该代码显示了两个存储池的创建，每个存储池跨两个磁盘分条，每个磁盘的分条大小为 64KB。存储空间被标记为数据磁盘和日志磁盘，以分别将它们标识为数据和日志文件的驱动器。

代码清单 16:在 Azure 虚拟机中为 SQL Server 数据和日志文件创建存储池

      # The original script for Provisioning of SQL Server Azure VM was created by Sourabh Agrawal and Amit Banerjee
      # The script is modified by Parikshit Savjani to suit the readers of the book SQL on Azure
      $PoolCount = Get-PhysicalDisk -CanPool $True
      $PhysicalDisks = Get-PhysicalDisk | Where-Object {$_.FriendlyName -like "*2" -or $_.FriendlyName -like "*3"}

      New-StoragePool -FriendlyName "DataFiles" -StorageSubsystemFriendlyName "Storage Spaces*" -PhysicalDisks $PhysicalDisks |New-VirtualDisk -FriendlyName "DataFiles" -Interleave 65536 -NumberOfColumns 2 -ResiliencySettingName simple –UseMaximumSize |Initialize-Disk -PartitionStyle GPT -PassThru |New-Partition -AssignDriveLetter -UseMaximumSize |Format-Volume -FileSystem NTFS -NewFileSystemLabel "DataDisks" -AllocationUnitSize 65536 -Confirm:$false

      PhysicalDisks = Get-PhysicalDisk | Where-Object {$_.FriendlyName -like "*4" -or $_.FriendlyName -like "*5"}

      New-StoragePool -FriendlyName "LogFiles" -StorageSubsystemFriendlyName "Storage Spaces*" -PhysicalDisks $PhysicalDisks |New-VirtualDisk -FriendlyName "LogFiles" -Interleave 65536 -NumberOfColumns 2 -ResiliencySettingName simple –UseMaximumSize |Initialize-Disk -PartitionStyle GPT -PassThru |New-Partition -AssignDriveLetter -UseMaximumSize |Format-Volume -FileSystem NTFS -NewFileSystemLabel "LogDisks" -AllocationUnitSize 65536 -Confirm:$false

如果您对数据和日志文件使用高级存储，建议您禁用托管日志文件的磁盘的缓存，并在托管数据文件和 tempdb 的磁盘上启用读缓存。对于标准存储，建议您禁用所有数据磁盘的缓存。

操作系统磁盘的默认缓存策略是读/写，不需要更改。强烈建议您不要在操作系统磁盘上存储任何数据库文件，包括系统数据库、错误日志、备份和跟踪文件。

所有连接到运行 SQL Server 的虚拟机的磁盘都应该用 NTFS 格式化，NTFS 分配单元大小为 64。

如前所述，虚拟机大小决定了虚拟机支持的计算和存储容量。在 Azure 中，虚拟机分为两层:基本层和标准层。这两种类型都提供了大小选择，但是基本层没有提供标准层提供的一些功能，例如负载平衡和自动扩展。标准层支持前面讨论过的 A 系列、D 系列、DS 系列和 G 系列的虚拟机。微软的以下文章记录了 Azure 中可用的虚拟机的详细大小:

https://azure . Microsoft . com/en-us/documents/articles/virtual-machines-size-specs/

在 Azure 上使用 SQL Server 时，建议您使用高级存储以获得更好的性能。如前所述，如果您需要为虚拟机使用高级存储，则需要使用 DS 系列虚拟机。DS 系列虚拟机支持连接高级存储帐户和标准存储帐户的磁盘，这使得它们成为安装和配置 SQL Server 的首选。即使您计划将标准存储连接到虚拟机，使用 DS 系列虚拟机可能更有意义，因为如果您选择以后升级，DS 系列虚拟机将允许您以最小的工作量迁移到高级存储。

因此，对于 SQL Server 工作负载，建议您选择带有 ds 系列虚拟机的标准层。对于 SQL 企业版，一般建议运行的虚拟机大小为 DS3 或更高，对于 SQL 标准版，运行的虚拟机大小为 DS2 或更高。

您选择的 DS 系列虚拟机(DS1–DS14)的大小取决于虚拟机上的应用程序工作负载、吞吐量要求和资源利用率。在云上运行虚拟机的最大好处是，您始终可以从较小的虚拟机规模开始，以最小的工作量、成本和停机时间扩展到更大的规模。

在 Azure 虚拟机中运行 SQL Server 的大多数性能建议或注意事项都集中在存储和 IO 优化上，因为存储是在本地运行 SQL Server 和在 Azure 虚拟机中运行 SQL Server 之间的主要性能差异。在本节中，我们将讨论一些已知的优化输入输出的 SQL Server 最佳实践配置，从而帮助优化运行在 Azure 虚拟机中的 SQL 工作负载的整体性能。

“锁定内存中的页面”是一种系统安全权限，默认情况下不会分配给任何用户，包括管理员。这是因为任何使用具有此权限的帐户运行的应用程序或服务都可以将其页面锁定在内存中，甚至操作系统也无法从内存中调出这些缓冲区。对于 SQL Server 工作负载，SQL 缓冲池页面应该被锁定在内存中，并且不应该被操作系统调出，以便为我们提供可预测的性能。建议您将“锁定内存页面”权限分配给 SQL 服务启动帐户。但是，在使用“锁定内存中的页面”权限时，将 SQL Server 实例的最大服务器内存限制在虚拟机总内存的 70-80%左右至关重要，以便为虚拟机上的操作系统和其他应用程序或服务(监控代理、备份软件、SQL Management Studio)留出喘息空间。

您可以使用以下步骤为 SQL Server 服务帐户启用“锁定内存中的页面”权限:

1. 在开始菜单上，点击运行。在打开框中，输入 gpedit.msc 。
2. 在本地组策略编辑器控制台，展开计算机配置，然后展开窗口设置。
3. 展开安全设置，然后展开本地政策。
4. 选择用户权限分配文件夹。
5. 这些策略将显示在详细信息窗格中。
6. 在窗格中，双击锁定内存中的页面。
7. 在本地安全设置-锁定内存页面对话框中，点击添加用户或组。
8. 在选择用户、服务帐户或组对话框中，添加具有运行 sqlservr.exe 权限的帐户。
9. 注销，然后重新登录，以使此更改生效。

| | 注意:在虚拟机服务器上，如果您将“锁定内存中的页面”权限分配给 SQL 服务帐户，并且您正在使用相同的帐户运行任何其他服务，则其他服务提交的内存页面也会被锁定，并且无法分页。从安全和管理的角度来看，建议保留专用于运行 SQL Server 服务的 SQL 服务帐户。 |

即时文件初始化最早是由微软 SQL 产品团队在 SQL 2005 中引入的，目的是在创建或增长数据库时减少数据文件的初始文件分配或增长所需的时间。即时文件初始化跳过了文件清零这一 IO 密集型操作，并显著减少了新文件分配的总时间。要利用即时文件初始化，您需要使用 SE_MANAGE_VOLUME_NAME 向 SQL Server (MSSQLSERVER)服务帐户授予权限，并将其添加到“执行卷维护任务”安全策略中。当我们从 Azure Gallery 调配 SQL Server 映像时，此权限不会自动分配给 SQL 服务帐户，需要在调配 SQL Server 映像后作为配置后任务手动分配。

您需要采取以下步骤来授予帐户执行卷维护任务的权限:

1. 在将要创建备份文件的计算机上，打开本地安全策略应用程序(secpol.msc)。
2. 在左窗格中，展开本地策略，然后单击用户权限分配。
3. 在右窗格中，双击执行卷维护任务。
4. 单击添加用户或组，添加任何用于备份的用户帐户。
5. 单击应用，然后关闭所有本地安全策略对话框。
6. 重新启动 SQL Server 服务以使权限生效。

| | 注意:使用即时文件初始化可能会有安全隐患。您可以从 MSDN 阅读以下文章，了解更多关于即时文件初始化的信息:https://msdn.microsoft.com/library/ms175935.aspx |

支持即时文件初始化，仅适用于数据文件。即使您将此权限分配给了您的 SQL 服务帐户，T 日志文件的分配也将是 IO 密集型和耗时的，因为它将涉及文件的清零。

Autoshrink 是一个数据库文件属性，允许您在数据库不使用时自动收缩数据库。自动刷新是一种 IO 密集型活动，会导致数据库文件和磁盘碎片。默认情况下，“自动收缩”属性被禁用，建议保持禁用状态；它不应该被用作收缩数据库文件的首选方法，尤其是在 Azure 虚拟机上运行时。

自动增长是一个数据库文件属性，用于在数据库文件空间不足时自动增长数据库。自动增长也是一项 IO 密集型操作，可以在数据或日志文件空间不足时随时随机启动。自动增长会导致数据库文件和磁盘碎片化，如果在工作时间发生，它会暂停或挂起 SQL Server，直到数据库文件增长完成。不建议禁用自动增长，因为它可以作为一种保险措施，并在关键情况下帮助您在数据库文件已满时增长数据库文件。理想情况下，您应该有一个监视和警报系统，当数据库文件只有 10-15%的可用空间时，它会向数据库管理员发出警报。数据库管理员应该通过在维护窗口期间手动增长文件或在工作时间关闭文件来响应警报，以避免自动增长。

SQL Server 数据压缩是在 SQL 2008 中引入的，它允许您压缩数据库页面，同时将它们存储在数据文件中。这减少了存储数据文件所需的输入输出带宽和存储空间，从而由于输入输出工作负载的减少而提高了整体性能。SQL Server 支持行压缩、页压缩和列存储压缩(在 SQL 2014 中引入)，每种压缩都以更高的 CPU 利用率为代价提供不同的压缩比。

有关 SQL Server 中数据压缩的更多详细信息，您可以参考 MSDN 的以下文章:

https://msdn.microsoft.com/library/cc280449.aspx

对于运行在 Azure 虚拟机上的 SQL Server 工作负载，建议您尽可能使用数据库压缩来减少 IO 带宽，从而提高查询的响应时间。

从 SQL 2008 R2 开始，SQL Server 支持本机备份压缩，这有助于在创建备份时减小备份的大小。对于在 box 或 Azure 虚拟机上运行的 SQL Server 工作负载，建议在实例级别打开备份压缩。这将确保在 SQL 实例上执行的任何备份都被压缩。此外，当备份被压缩时，数据库的恢复不会受到太大影响。

您可以使用以下 t-sql 代码在实例级启用压缩备份:

代码清单 17:启用压缩备份

      USE master;
      GO
      EXEC sp_configure 'backup compression default', '1';
      RECONFIGURE WITH OVERRIDE;

为运行在 Azure 虚拟机中的 SQL Server 执行备份时，可以使用 SQL Server 备份到 URL 。此功能从 SQL Server 2012 SP1 CU2 版开始提供，建议用于备份到连接的数据磁盘。当您备份或恢复到/从 Azure 存储时，请遵循 SQL Server 备份到 URL 最佳实践和故障排除以及从存储在 Azure 存储中的备份恢复中提供的建议。您也可以使用Azure 虚拟机中的 SQL Server 自动备份来自动执行这些备份。

默认情况下，始终建议在最新的服务包或累积更新上运行 SQL Server，以涵盖服务器的所有已知问题。特别是对于运行在 Azure 虚拟机上的 SQL Server 2012，请安装服务包 1 累积更新 10。此更新包含对在 SQL Server 2012 中执行选择进入临时表语句时输入/输出性能不佳的修复。