【问题标题】:Azure SQL Database - queries significantly slower than SQL Database on Azure VMAzure SQL 数据库 - 查询比 Azure VM 上的 SQL 数据库慢得多
【发布时间】:2017-09-22 17:02:51
【问题描述】:

我们将 SQL Server 从 Azure VM 移至 Azure SQL 数据库。 Azure VM 是 DS2_V2、2 核、7GB RAM、6400 最大 IOPS Azure SQL 数据库是标准 S3、100 DTU。在 Azure VM 上运行 Azure DTU 计算器工具 24 小时后,我选择了这一层 - 它为我推荐了这一层。

问题在于,与在 Azure VM 上的查询相比,查询(主要是 SELECT 和 UPDATE)现在非常缓慢。我注意到的一件事是,在运行查询时,我转到了 Azure 门户中监控下的资源利用率图,在运行任何查询的整个过程中,它都在 100% ping。 这是否意味着我的tier其实太低了?我希望不会,因为下一层的成本会有很大的飞跃。

仅供参考,Azure SQL 数据库在架构和数据上与 Azure VM 数据库相同,我在迁移后重建了所有索引(包括全文)。

到目前为止,在我的研究中,我已经阅读了所有内容,从确保我的 Azure SQL DB 位于 Azure 上的正确区域(它是)到导致问题的网络延迟(Azure VM 上不存在)。

【问题讨论】:

  • 我认为它是同一个 VNET,并且与 VM 相同的身份验证 (?)
  • 也许通过查看执行计划来确保您的索引正在被使用?
  • @Stefanod'Antonio 是的,两者都是正确的。感谢您的回复。
  • @EMUEVIL 好点。我会检查这个。
  • 您好,要检查的一个区域是 sys.dm_db_resource_stats,以查看您是否确实达到了等效工作负载的 DTU 限制(您也可以使用 sys.resource_stats - 数据最多保留 14 天) .先看看这个,看看你是否达到了 DTU 限制。如果没有达到限制 - 然后比较执行计划 - 例如 DB 与 VM 中的串行与并行。

标签: sql-server azure azure-virtual-machine azure-sql-database


【解决方案1】:

这个系统现在作为 Azure SQL Server 数据库运行了多长时间?据推测,如果它超过几个小时(即一些“生产”查询已经命中它)并且它生成了一些有用的统计信息。

分析这一点并确定问题的根源将是一个多管齐下的策略

服务层检查

尝试以下查询,以确定您是否处于正确的服务级别:

-----------------------
---- SERVICE TIER CHECK
-----------------------
-- The following query outputs the fit percentage per resource dimension, based on a threshold of 20%.
-- IF the query below returns values greater than 99.9 for all three resource dimensions, your workload is very likely to fit into the lower performance level.
SELECT 
    (COUNT(end_time) - SUM(CASE WHEN avg_cpu_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'CPU Fit Percent'
    ,(COUNT(end_time) - SUM(CASE WHEN avg_log_write_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Log Write Fit Percent'
    ,(COUNT(end_time) - SUM(CASE WHEN avg_data_io_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Physical Data Read Fit Percent'
FROM sys.dm_db_resource_stats

-- Look at how many times your workload reaches 100% and compare it to your database workload SLO.
-- IF the query below returns a value less than 99.9 for any of the three resource dimensions, you should consider either moving to the next higher performance level or use application tuning techniques to reduce the load on the Azure SQL Database.
SELECT 
(COUNT(end_time) - SUM(CASE WHEN avg_cpu_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'CPU Fit Percent'
,(COUNT(end_time) - SUM(CASE WHEN avg_log_write_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Log Write Fit Percent'
,(COUNT(end_time) - SUM(CASE WHEN avg_data_io_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(end_time) AS 'Physical Data Read Fit Percent'
FROM sys.dm_db_resource_stats

资源消耗水平

检查资源消耗也很有用,您可以使用以下查询来完成。这将报告 DTU 消耗和 IO 等内容。

-----------------
-- Resource Usage
-----------------
select *
from sys.dm_db_resource_stats 
order by end_time desc

索引

还值得快速检查一下您是否缺少索引,或者您的某些现有索引是否妨碍了您。

缺少的索引查询很麻烦,但应该谨慎对待。我通常将其视为关于如何使用 db 的建议,并且我自己判断要添加哪些索引以及如何添加。例如,作为一般经验法则,所有外键都应具有非聚集索引,以促进它们所涉及的不可避免的 JOIN。

--------------------
-- Find poor indexes
--------------------
DECLARE @dbid int
SELECT @dbid = db_id()

SELECT 'Table Name' = object_name(s.object_id), 'Index Name' =i.name, i.index_id,
        'Total Writes' =  user_updates, 'Total Reads' = user_seeks + user_scans + user_lookups,
        'Difference' = user_updates - (user_seeks + user_scans + user_lookups)
FROM sys.dm_db_index_usage_stats AS s 
INNER JOIN sys.indexes AS i
ON s.object_id = i.object_id
AND i.index_id = s.index_id
WHERE objectproperty(s.object_id,'IsUserTable') = 1
AND s.database_id = @dbid
AND user_updates > (user_seeks + user_scans + user_lookups)
ORDER BY 'Difference' DESC, 'Total Writes' DESC, 'Total Reads' ASC;

------------------
-- Missing Indexes
------------------
declare @improvementMeasure int = 100

SELECT
CONVERT (decimal (28,1), 
migs.avg_total_user_cost * 
migs.avg_user_impact * 
(migs.user_seeks + migs.user_scans)) 
AS improvement_measure, 
OBJECT_NAME(mid.object_id, mid.database_id) as table_name,
  mid.equality_columns as index_column,
  mid.inequality_columns,
  mid.included_columns as include_columns, 
'CREATE INDEX IX_' + 
OBJECT_NAME(mid.object_id, mid.database_id) + 
'_' + 
REPLACE(REPLACE(mid.equality_columns, '[', ''), ']', '') + 
' ON ' + 
mid.statement + 
' (' + ISNULL (mid.equality_columns,'') + 
CASE WHEN mid.equality_columns IS NOT NULL 
AND mid.inequality_columns IS NOT NULL 
THEN ',' 
ELSE '' 
END + ISNULL (mid.inequality_columns, '') + 
')' + 
ISNULL (' INCLUDE (' + mid.included_columns + ')',
'') AS create_index_statement, 
migs.user_seeks,
migs.unique_compiles,
migs.avg_user_impact,
migs.avg_total_user_cost

FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs 
ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid 
ON mig.index_handle = mid.index_handle
WHERE CONVERT (decimal (28,1), 
migs.avg_total_user_cost * 
migs.avg_user_impact * 
(migs.user_seeks + migs.user_scans)) > @improvementMeasure
ORDER BY migs.avg_total_user_cost * 
migs.avg_user_impact * 
(migs.user_seeks + migs.user_scans) DESC

维护

还应制定维护计划,从而定期重建索引和统计信息。不幸的是,Azure SQL 环境中没有 SQL 代理。但是 Powershell 和 Azure functionAzure WebJob 可以帮助您安排和执行此操作。对于我们的本地服务器和 Azure 服务器,我们每周执行一次。

请注意,WebJob 只有在您有一个预先存在的应用服务可以在其中运行时才会有所帮助。

有关帮助您维护索引和统计信息的脚本,请查看Ola Hallengren's 脚本产品。

【讨论】:

  • 非常详细的答案 - 谢谢你。我有几个问题: 服务层检查查询:我为两个查询的所有 3 列返回 1.00000。我应该将其解读为 100%(大于 cmets 中提到的 99.9)还是 1(远低于 cmets 中提到的 99.9%)。资源使用查询 - 我收到错误“列名 'start_time' 无效。查找不良索引查询 - 我如何解释此查询的结果?它列出了我的索引以及总写入、总读取和差异。我在这里寻找什么?(下一条评论中的最后一个问题......)
  • 最后,缺少索引查询 - 这是一个令人难以置信的查询。运行它后,我是否只是想遵循“create_index_statement”列中返回的建议?
  • 在服务层查询的 cmets 中,它在两个地方说“如果上面的查询...”,那些应该说“如果下面的查询...”?我对什么评论指的是什么查询感到困惑。
  • 我很高兴@Stpete111。为过时的资源检查道歉。我忘记了他们弃用了双重时间戳。我已经相应地更新了查询。好问题,1.0 的值表示 100%。你说的完全正确,应该在下面。
  • 缺少的索引查询是一个笨蛋,但应该谨慎对待。我通常将其视为关于如何使用 db 的建议,并且我自己判断要添加哪些索引以及如何添加。例如,作为一般经验法则,所有外键都应具有非聚集索引,以促进它们所涉及的不可避免的JOIN
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2021-12-05
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-10-20
相关资源
最近更新 更多