练习 - 扩展工作负载的性能

10 分钟

在本练习中，你将利用在第一个练习中遇到的问题，并通过为 Azure SQL 数据库扩展更多 CPU 来提高性能。你将使用在上一个练习中部署的数据库。

可以在克隆的 GitHub 存储库或下载的 zip 文件的 04-Performance\monitor_and_scale 文件夹中找到本练习的所有脚本。

纵向扩展 Azure SQL 性能

若要针对似乎由 CPU 容量造成的问题缩放性能，则你应确定选项，然后继续使用为 Azure SQL 提供的接口缩放 CPU。

确定如何缩放性能。由于工作负载受 CPU 约束，因此提高性能的一种方法是增加 CPU 容量或速度。 SQL Server 用户必须移动到另一台计算机或重新配置 VM 以获得更多 CPU 容量。在某些情况下，即使是 SQL Server 管理员也可能没有权限进行这些缩放更改。此过程可能需要一些时间，甚至需要迁移数据库。

对于 Azure，你可使用 ALTER DATABASE、Azure CLI 或 Azure 门户增加 CPU 容量，无需用户来迁移数据库。
可在 Azure 门户中查看选项了解如何进行扩展来获得更多 CPU 资源。从数据库的“概述”窗格中，选择当前部署的定价层。通过定价层可更改服务层级和 vCore 数目。
可在此处查看用于更改或缩放计算资源的选项。对于常规用途，可轻松地纵向扩展到某种程度（例如 8 个 vCore）。

你还可使用其他方法来缩放工作负载。
在本练习中，必须先刷新查询存储，这样才能在报表中看到适当的差异。在 SQL Server Management Studio (SSMS) 中，选择 AdventureWorks 数据库，然后使用“文件”>“打开”>“文件”菜单。在 AdventureWorks 数据库的上下文中，在 SSMS 中打开 flushhquerystore.sql 脚本。查询编辑器窗口应类似于以下文本：
```
EXEC sp_query_store_flush_db;
```
选择“执行”以运行此 T-SQL 批处理。

注意

运行上述查询会将查询存储数据的内存中部分刷新到磁盘。
在 SSMS 中打开脚本 get_service_objective.sql。查询编辑器窗口应类似于以下文本：
```
SELECT database_name,slo_name,cpu_limit,max_db_memory, max_db_max_size_in_mb, primary_max_log_rate,primary_group_max_io, volume_local_iops,volume_pfs_iops
FROM sys.dm_user_db_resource_governance;
GO
SELECT DATABASEPROPERTYEX('AdventureWorks', 'ServiceObjective');
GO
```
该方法使用 T-SQL 来查找服务层级。定价层或服务层级也称为服务目标。选择“执行”以运行 T-SQL 批处理。

对于当前 Azure SQL 数据库部署，结果应如下图所示：

请注意，术语“slo_name”也用于服务目标。 slo 的全称是“服务级别目标”。

各种 slo_name 值均不记录，但你可在字符串值中看到，此数据库使用具有两个 vCore 的常规用途服务层级：

注意

SQLDB_OP_... 是用于业务关键的字符串。

查看 ALTER DATABASE 文档时，请注意可选择目标 SQL Server 部署来获取正确的语法选项。选择“SQL 数据库单一数据库/弹性池”可查看 Azure SQL 数据库的选项。若要匹配在门户中找到的计算规模，需要服务目标 'GP_Gen5_8'。
修改数据库的服务目标以扩展更多 CPU。在 SSMS 中打开脚本 modify_service_objective.sql，并运行 T-SQL 批处理。查询编辑器窗口应类似于以下文本：
```
ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
```
此语句会立即返回，但计算资源在后台进行缩放。缩放这种小规模所耗时间不会超过 1 分钟，数据库会脱机一小段时间来使更改生效。可使用 Azure 门户监视此缩放活动的进度。

在对象资源管理器的“系统数据库”文件夹下，右键单击 master 数据库，然后选择“新建查询”。在 SSMS 查询编辑器窗口中运行此查询：

SELECT * FROM sys.dm_operation_status;

这是监视为 Azure SQL 数据库更改服务目标的进度的另一种方法。此动态管理视图 (DMV) 会将使用 ALTER DATABASE 对数据库进行的更改的历史记录公开到服务目标。该视图显示了更改的活动进度。

下例显示了你在运行前面的 ALTER DATABASE 语句后，此 DMV 以表格式提供的输出：

项	值
session_activity_id	97F9474C-0334-4FC5-BFD5-337CDD1F9A21
resource_type	0
resource_type_desc	数据库
major_resource_id	AdventureWorks
minor_resource_id
operation	ALTER DATABASE
state	1
state_desc	IN_PROGRESS
percent_complete	0
error_code	0
error_desc
error_severity	0
error_state	0
start_time	[date time]
last_modify_time	[date time]

在服务目标的更改过程中，可对数据库执行查询，直到实现最终更改。应用程序将断开一小段时间连接。对于 Azure SQL 托管实例，更改层允许查询和连接，但阻止所有数据库操作，例如创建新数据库。在这些情况下，你会收到以下错误消息：“无法完成该操作，因为正在更改托管实例 [server] 的服务层级。请等待正常执行的操作完成，然后重试。”

完成此操作后，在 SSMS 中通过 get_service_objective.sql 使用前面列出的查询，验证是否具有 8 个 vCore 的新服务目标或服务层级已生效。

纵向扩展之后运行工作负载

现在数据库具有更多 CPU 容量，让我们运行我们在上一个练习中完成的工作负载，以观察性能是否提高。

现在缩放已完成，请检查工作负载持续时间是否更快以及 CPU 资源的等待时间是否减少。使用在上一练习中运行的 sqlworkload.cmd 命令再次运行工作负载。
通过 dmdbresourcestats.sql 脚本使用 SSMS 运行本模块的第一个练习中的查询，观察其结果：
```
SELECT * FROM sys.dm_db_resource_stats;
```
你应会看到与上一练习中几乎 100% 的使用率相比，平均 CPU 资源使用率有所下降。通常，sys.dm_db_resource_stats 显示一小时的活动。调整数据库大小会导致 sys.dm_db_resource_stats 重置。
通过 dmexecrequests.sql 脚本使用 SSMS 运行与本模块第一个练习相同的查询，观察其结果。
```
SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
FROM sys.dm_exec_requests er
INNER JOIN sys.dm_exec_sessions es
ON er.session_id = es.session_id
AND es.is_user_process = 1;
```
你会看到有更多查询的状态为“正在运行”。这意味着工作线程具有更多的 CPU 容量来执行。
观察新的工作负载持续时间。 sqlworkload.cmd 的工作负载持续时间现在大幅缩短，应该约为 25-30 秒。

观察查询存储报表

让我们看看与上一个练习中相同的查询存储报表。

使用与本模块中第一个练习相同的方法，从 SSMS 查看“资源消耗量最大的查询”报表：

现在会看到两个查询 (query_id)。它们是相同的查询，但在查询存储中显示为不同的 query_id 值，因为缩放操作需要重启，且必须重新编译查询。在报表中可以看到，总体和平均持续时间显著减少。
另请查看“查询等待统计信息”报表，然后选择“CPU 等待”栏。可以看到，查询的总体平均等待时间已减少，在总体持续时间中所占的百分比更低。这很好地表明，当数据库的 vCore 数量减少时，CPU 不会造成资源瓶颈：
可关闭所有报表和查询编辑器窗口。将 SSMS 保持在连接状态，因为你在下一练习中需要使用它。

观察 Azure 指标的更改

在 Azure 门户中转到 AdventureWorks 数据库，再次查看“概述”窗格中的“监视”选项卡来了解计算利用率：

请注意，如果 CPU 利用率较高，则持续时间较短，这意味着运行工作负载所需的 CPU 资源在总体上有所下降。
此图表可能有点误导。在“监视”菜单中，使用“指标”，然后将“指标”设置为“CPU 限制”。 CPU 比较图与下图非常类似：

提示

如果继续增加此数据库的 vCore 数目，则可将性能提升至达到阈值，此时所有查询都具有足够多的 CPU 资源。这并不意味着必须将 vCore 数与工作负载中的并发用户数相匹配。此外，可将定价层更改为使用“无服务器”计算层（而不是“已预配”计算层）。这有助于对工作负载实施自动缩放程度更高的方法。例如，对于此工作负载，如果选择了 vCore 最小值 2 和最大值 8，则此工作负载会立即扩展到 8 个 vCore。

在下一个练习中，你将发现性能问题，并通过实施应用程序性能的最佳做法来解决它。

练习 - 扩展工作负载的性能

纵向扩展 Azure SQL 性能

纵向扩展之后运行工作负载

观察查询存储报表

观察 Azure 指标的更改

反馈