使用 DMV 进行监视_监视资源使用情况(3下)_针对 Azure SQL 数据库和 Azure SQL 托管实例进行手动性能优化

本文适用：AZURE SQL数据库，AZURE SQL托管实例

紧接上一篇的内容，本篇我们将再详细展开一些例子。

首先对于sys.server_resource_stats，我们先看一下如何公开此视图中的数据：

下面的示例演示可以用不同方式使用 sys.resource_stats 目录视图，以获取有关数据库如何使用资源的信息：

1. 若要查看数据库 userdb1 过去一周的资源使用情况，可以运行此查询：

SELECT *
FROM sys.resource_stats
WHERE database_name = 'userdb1' AND
    start_time > DATEADD(day, -7, GETDATE())
ORDER BY start_time DESC;

主要字段说明：

当处于AZURE SQL托管实例下

当处于AZURE SQL数据库下

2. 若要评估工作负荷与计算大小的适合程度，需要向下钻取资源指标的每个方面：CPU、读取数、写入数、辅助进程数和会话数。 下面是使用 sys.resource_stats 的修订查询，用于报告这些资源度量值的平均值和最大值：

SELECT
    avg(avg_cpu_percent) AS 'Average CPU use in percent',
    max(avg_cpu_percent) AS 'Maximum CPU use in percent',
    avg(avg_data_io_percent) AS 'Average physical data IO use in percent',
    max(avg_data_io_percent) AS 'Maximum physical data IO use in percent',
    avg(avg_log_write_percent) AS 'Average log write use in percent',
    max(avg_log_write_percent) AS 'Maximum log write use in percent',
    avg(max_session_percent) AS 'Average % of sessions',
    max(max_session_percent) AS 'Maximum % of sessions',
    avg(max_worker_percent) AS 'Average % of workers',
    max(max_worker_percent) AS 'Maximum % of workers'
FROM sys.resource_stats
WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());

 3. 使用每个资源指标的平均值和最大值信息，可以评估工作负荷与所选计算大小的适合程度。 通常情况下，sys.resource_stats 中的平均值可提供一个用于目标大小的良好基准。 它应该是主要测量标杆。 例如，你可能正在使用 S2 计算大小的“标准”服务层级。 CPU 和 IO 读写的平均使用百分比低于 40%，平均辅助角色数低于 50，平均会话数低于 200。 工作负荷可能适合 S1 计算大小。 很轻松就能判断数据库是否在辅助进程和会话限制范围内。 若要查看数据库是否适合 CPU 和读写数等更小的计算大小，请将更小计算大小的 DTU 数除以当前计算大小的 DTU 数，并将结果乘以 100：2. 若要评估工作负荷与计算大小的适合程度，需要向下钻取资源指标的每个方面：CPU、读取数、写入数、辅助进程数和会话数。 下面是使用 sys.resource_stats 的修订查询，用于报告这些资源度量值的平均值和最大值：

S1 DTU / S2 DTU * 100 = 20 / 50 * 100 = 40

结果是以百分比表示的两个计算大小之间的相对性能差异。 如果资源使用不超出此量，则工作负荷可能适合更低的计算大小。 但是，需要查看资源用量值的所有范围，并按百分比确定数据库工作负荷适合更小计算大小的频率。 以下查询会根据以上示例计算得出的阈值 40%，输出每个资源维度的适合性百分比：

SELECT
     100*((COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 40 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name)) AS 'CPU Fit Percent',
     100*((COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 40 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name)) AS 'Log Write Fit Percent',
     100*((COUNT(database_name) - SUM(CASE WHEN avg_data_io_percent >= 40 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name)) AS 'Physical Data IO Fit Percent'
 FROM sys.resource_stats
 WHERE database_name = 'sample' AND start_time > DATEADD(day, -7, GETDATE());

可以根据数据库服务层级的情况来确定工作负荷是否适合更小的计算大小。 如果数据库工作负荷目标为 99.9%，而上述查询针对所有三个资源维度返回的值大于 99.9%，则工作负荷可能适合更小的计算大小。

查看适合性百分比还可以深入分析是否应转到下一个更大的计算大小以满足目标。 例如，userdb1 显示过去一周的如下 CPU 使用率：

平均 CPU 大约是计算大小限制的四分之一，这意味着它很适合数据库的计算大小限制。 但是，最大值显示该数据库达到了计算大小的限制。 在这种情况下，是否需要转到下一个更大的计算大小？ 查看工作负荷达到 100% 的次数，并将这种情况与数据库工作负荷目标进行比较。

SELECT
     100*((COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name)) AS 'CPU Fit Percent',
     100*((COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name)) AS 'Log Write Fit Percent',
     100*((COUNT(database_name) - SUM(CASE WHEN avg_data_io_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name)) AS 'Physical Data IO Fit Percent'
 FROM sys.resource_stats
 WHERE database_name = 'sample' AND start_time > DATEADD(day, -7, GETDATE());

如果对于三个资源维度中的任何一个维度，此查询返回的值小于 99.9%，请考虑转到下一个更大的计算大小，或使用应用程序优化技术来减少数据库上的负载。

4. 另外，还应将未来预计的工作负荷增加考虑在内。做好规划也是DBA的任务。

对于弹性池，可以使用本部分中所述的技术来监视池中的单个数据库。 但也可总体监视该池。 有关信息，可以查阅监视和管理弹性池相关微软官方文档。

最后

以上就是英俊绿草为你收集整理的使用 DMV 进行监视_监视资源使用情况(3下)_针对 Azure SQL 数据库和 Azure SQL 托管实例进行手动性能优化的全部内容，希望文章能够帮你解决使用 DMV 进行监视_监视资源使用情况(3下)_针对 Azure SQL 数据库和 Azure SQL 托管实例进行手动性能优化所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。