Azure SQL数据库复制命令导致源Azure应用程序运行缓慢

我们正在使用Devops重新创建演示环境。在Devops部署中，我们有一个Azure Powershell任务，用于将生产Azure SQL数据库复制到prod db所在服务器上的“演示”数据库

我们首先在服务器上搜索数据库，如果“demo”数据库存在，则删除它：

Remove-AzSqlDatabase  -ResourceGroupName prdResource -ServerName  prdServer -DatabaseName demoDb 

然后我们将prod db复制到demo db：

New-AzSqlDatabaseCopy  -ResourceGroupName prdResource -ServerName prdServer -DatabaseName prodDb -CopyDatabaseName demoDb

最后，我们在解调器上设置服务级别：

Set-AzSqlDatabase      -ResourceGroupName prdResource -ServerName prdServer -DatabaseName demoDb -Edition "Standard" -RequestedServiceObjectiveName "S4"

这一切都可以正常工作，并且使用适当的服务级别正确创建了演示数据库。问题是我们连接到prod数据库的Azure prod webapp遇到了性能问题。在复制数据库之前通常需要约2秒的呼叫，现在需要30秒以上。我们发现，如果我们重新启动清除问题的webApp

只是想知道为什么copydb命令会影响我们在web应用程序上的性能？是否有其他设置应与“复制”命令一起使用？我们已经多次运行此过程，每次运行时都会遇到相同的性能问题

---

根据我们的理解，该过程不应对prod db产生任何负面影响，这是正确的假设吗？无需重新启动webApp即可解决此问题的任何其他方法？

扩展sql数据库层，并将webApp和db定位在同一区域

这两个变化导致了性能的大幅提升

---

此外，您还可以参考本文，通过智能洞察来解决Azure SQL数据库性能问题。

DTU似乎不是问题所在，因为它们没有超过20%。我们有一个DevOps部署，它运行所有任务，并计划在每个Sat的凌晨1:00执行。以下是该时间段内该数据库的DTU屏幕截图：

此外，DB和WebApp都位于美国东部地区，因此这也不应成为问题

---

再次，重新启动webapp会清除该问题，从而表明它不是DB/DTU问题

您是否查看了生产数据库门户中的DTU使用情况。我想当复制发生时会出现峰值？如果让系统单独运行（比如）30分钟，DTU的使用率会下降还是真的需要重新启动？DTU会出现峰值，但还不错。复制过程在周六凌晨1:00运行。我们将在周六上午8:00尝试webApp，这是在复制过程完成且DTU稳定之后。Web应用程序中的连接似乎不稳定或出现问题，因为重新启动会再次清除所有内容，并且所有内容都按预期工作。您可以尝试其他方法复制azure数据库，如所述。您也可以提交此问题以让开发人员了解此问题。我已在此处发布了其他与Azure相关的问题，Azure人员已回答了这些问题。他们不再监控Azure问题的StackOverflow帖子了吗？