Sql server Azure弹性池数据库的性能

我们遇到了中提到的类似问题。 我们还使用Azure弹性池，并为每个客户创建一个新的数据库。我们首先使用EF6代码来处理SQL内容

使用web前端，用户可以创建客户。他们一周会这样做几次，有时（不总是，但肯定是一周一次）数据库只是部分创建的，我们会得到

Microsoft.Azure.SqlDatabase.ElasticScale.ShardManagement

错误。 当我们删除这个客户机/db并再次创建它时，它可以正常工作。 当然这很烦人。我们现在正在捕获此错误，删除数据库并重新启动代码中的创建。有没有人有类似的经验，希望有更好的解决方案

另外，创建数据库需要很长时间：3-5分钟。我们每个数据库只有18个表。我们能加快速度吗

工作流的下一步是解析用户上传的XML文件。 我们使用EF6填充模型并将其保存到数据库中。这真的很慢。 XML文件包含我们需要填入几个表（大约15个表）的员工数据。例如，我们有一个9.7MB的XML文件，其中包含4416名员工，“.save（）”步骤大约需要12分钟。考虑到客户机每年大约有25个XML文件，用户一次上传5年，此保存时间太长

我们已经看过了代码，但考虑到EF6的局限性，我们认为我们无法对其进行进一步优化。我们现在正在查看Azure订阅的配置，但文档很紧张，我们无法确定如何更改以获得更好的性能

---

非常感谢您的指导。

我在Microsoft Azure>Azure SQL数据库论坛上交叉发布了这个问题： 答案是：

不能将部分（仅某些资源）扩展到另一层。您不能仅扩展数据库的最大数量

---

这不是我所希望的答案。

我有一个云应用程序，它非常类似地使用新的数据库碎片创建新的客户实例。我发现创建这些Azure数据库的代码必须非常容错。我是这样做的：

创建数据库时，请使用至少5分钟的超长超时。要花很长时间才能回来

等待更长时间，因为即使脚本运行并执行返回到应用程序，数据库仍然无法使用。我有一个简单的查询，每10秒对数据库运行一次。首先，查询在运行时抛出异常；我捕获异常以防止错误冒泡。一段时间后，查询将成功运行，您知道数据库已准备好接收请求。如果Azure从未成功创建表，我将在尝试50次以防止无限循环后停止

现在，像这样在常规程序流中使用try/catch并反复点击资源通常是不好的做法，然而，这是我发现的唯一一种在解决这个问题时100%有效的方法