Azure SQL数据库更新性能

Question

我们正在将一些数据库从运行SQL Server的Azure VM迁移到Azure SQL。当前的VM是标准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分钟内运行它。

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

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

Answer 1

在一种情况下解决了性能下降的问题：

我最近在缓慢的Azure更新方面遇到了严重问题，这使其几乎无法使用。它在一秒钟内仅更新1000行。因此1M行等于1000秒。我相信这是由于登录Azure而引起的，但是我还没有做足够的研究来确定。开启MS支持事件无济于事。我终于使用两种技术解决了这个问题：

1. 将数据复制到临时表并在临时表中进行更新。因此，在上述情况下，请尝试将50行复制到临时表中，然后在更新后再次返回。在这种情况下，没有/最少的日志记录。

2. 我的复制仍然很慢（我有10万行），并且在该表上创建了聚集索引。更新持续时间下降了4-5倍。

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

Answer 2

  

我们在P1性能水平使用弹性池。

不确定，这将如何转换您的VM效果级别以及您用来比较两者的标准

我建议以下步骤，因为没有提供执行计划..

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似乎不是一个问题。所以我在这方面看不到太多问题..

Answer 3

这个问题的真正答案是，如果您习惯使用配置良好的VM或物理机，SQL Azure将以比您预期更快的速度泄漏到tempdb。

您可以通过记录实际执行查询计划来判断是否发生了这种情况。查找警告图标：

弹出窗口会抱怨漏油事件：

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

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

似乎有效的是将插入物分成小批量的传统建议。