我们遇到了一个类似的问题，如Azure中提到的，太容易达到数据库cpu限制。我们还使用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数据库论坛上交叉发布了这个问题：https://social.msdn.microsoft.com/Forums/en-US/b7c7ad0a-0be4-4b15-8ae6-494181ec60b1/how-to-increase-max-number-of-databases-allowed-without-increasing-pricetier?forum=ssdsgetstarted答案是：
您不能部分(仅某些资源)扩展到另一层。不能仅缩放数据库的最大数量。
这不是我所希望的答案。
我有一个云应用程序，它类似地使用新的数据库碎片创建新的客户实例。我发现创建这些Azure数据库的代码必须是非常容错的。我是这样做的：
-
创建数据库时，请使用至少5分钟的超长超时。回来需要很长时间。
-
等待更长的时间，因为即使脚本运行并执行返回到应用程序，数据库仍然无法使用。我有一个简单的查询，每10秒对数据库运行一次。首先，查询在运行时抛出异常；我捕捉到异常是为了防止错误冒出来。过一段时间，查询将成功运行，并且您知道数据库已准备好接收请求。如果Azure从未成功创建表，我会在50次尝试后停止，以防止无限循环。
现在，对这样的常规程序流使用try/catchs并反复调用资源通常是不好的做法，然而，这是我发现的唯一一种100%适用于此问题的方法。