Azure SQL 数据库更新性能答案

【问题标题】：Azure SQL Database update performanceAzure SQL 数据库更新性能
【发布时间】：2017-03-13 14:41:49
【问题描述】：

我们正在将一些数据库从运行 SQL Server 的 Azure VM 迁移到 Azure SQL。当前的虚拟机是标准 DS12 v2，连接了两个 1TB SSD。

我们使用的是 P1 性能级别的弹性池。我们在这方面还处于早期阶段，所以池中没有真正运行其他任何东西。

无论如何，我们正在执行一个涉及少量约 20M 行表的 ETL 过程。我们批量加载这些表，然后更新一些属性以帮助完成其余过程。

例如，我目前正在运行以下更新：

UPDATE A
SET A.CompanyId = B.Id
FROM etl.TRANSACTIONS AS A
LEFT OUTER JOIN dbo.Company AS B
ON A.CO_ID = B.ERPCode

TRANSACTIONS 约为 20M 行；公司少于 50 家。

我已经运行此更新 30 分钟，这远远超出了可接受的范围。池上的使用量表徘徊在 40% 左右。作为参考，我们的 Azure VM 在大约 2 分钟内运行。

我通过批量复制加载此表，此更新已超出加载整个表所需的时间。

关于加快此（和其他）更新的任何建议？

【问题讨论】：

您的弹性池是否存在限制——也就是说，您是否限制此数据库使用超过 40% 的 DTU？
你读过这个吗？ alexandrebrisebois.wordpress.com/2013/02/16/…
是的，过程的批量加载部分不是问题。我将在大约 30 分钟内加载整个表格。我让更新在一夜之间完成，运行了五个小时。
@DanRediske-MSFT - 不，我没有设置上限。批量加载和其他一些操作能够远高于 40%。我想为我们池中的一些数据库配置限制，但我实际上在门户中找不到设置。
好的。我已经联系了其他几位专家，看看我们是否对您的案例有任何见解。您的查询计划是什么样的？

标签： azure azure-sql-database

【解决方案1】：

我们使用的是 P1 性能级别的弹性池。

不确定，这如何转换您的虚拟机性能水平以及您使用什么标准来比较两者

我会推荐以下步骤，因为没有提供执行计划..

1.在更新运行时检查是否有等待类型

select 
session_id,
start_time,
command,
db_name(ec.database_id) as dbname,
blocking_session_id,
wait_type,
last_wait_type,
wait_time,
cpu_time,
logical_reads,
reads,
writes,
((database_transaction_log_bytes_used +database_transaction_log_bytes_reserved)/1024)/1024 as logusageMB,
txt.text,
pln.query_plan
 from sys.dm_exec_requests ec
 cross apply
 sys.dm_exec_sql_text(ec.sql_handle) txt
 outer apply
 sys.dm_exec_query_plan(ec.plan_handle) pln
 left join
 sys.dm_tran_database_transactions trn
 on trn.transaction_id=ec.transaction_id

等待类型，为您提供大量信息，可用于故障排除..

2.您也可以使用下面的查询并行查看查询发生了什么

set statistics profile on
your update query

然后在单独的窗口中运行下面的查询

select 
session_id,physical_operator_name,
row_count,actual_read_row_count,estimate_row_count,estimated_read_row_count,
rebind_count,
rewind_count,
scan_count,
logical_read_count,
physical_read_count,
logical_read_count
 from
sys.dm_exec_query_profiles
where session_id=your sessionid;

根据您的问题，DTU 似乎没有问题。所以我在这方面没有看到太多问题..

【讨论】：

【解决方案2】：

在一种情况下解决了性能缓慢问题：

我最近遇到了 Azure 更新缓慢的严重问题，导致它几乎无法使用。它在 1 秒内只更新了 1000 行。所以 1M 行是 1000 秒。我相信这是由于登录 Azure，但我没有做足够的研究来确定。打开一个 MS 支持事件没有任何结果。我终于用两种技术解决了这个问题：

将数据复制到临时表并在临时表中进行更新。因此，在上述情况下，尝试将 50 行复制到临时表中，然后在更新后再次返回。在这种情况下没有/最少的日志记录。
我的复制速度仍然很慢（我有几 100K 行），我在该表上创建了一个聚集索引。更新持续时间减少了 4-5 倍。

我正在使用 S1-20DTU 数据库。它仍然比专用实例慢约 5 倍，但对于价格而言，这是非常棒的性能。

【讨论】：

【解决方案3】：

这个问题的真正答案是，如果您习惯使用配置良好的 VM 或物理机，SQL Azure 会比您预期的更快地溢出到 tempdb。

您可以通过记录实际的执行查询计划来判断这是否正在发生。寻找警告图标：

弹出窗口会抱怨溢出：

无论如何，如果您看到这一点，很可能是您试图在声明中做太多事情。

微软支持人员建议更新统计信息，但这并没有改变我们的情况。

似乎奏效的是传统建议将插入物分成更小的批次。

【讨论】：