1

我们遇到了Azure hits database cpu limits too easy中提到的类似问题。我们还在使用 Azure 弹性池，并正在为每个客户创建一个新数据库。我们使用 EF6-code-first 来处理 SQL 内容。

使用 Web 前端，用户可以创建客户。他们每周这样做几次，有时（不总是，但肯定是每周一次）数据库只是部分创建，我们会Microsoft.Azure.SqlDatabase.ElasticScale.ShardManagement出错。当我们删除此客户端/数据库并再次创建时，它工作正常。当然，这很烦人。我们现在正在努力捕捉这个错误，删除数据库并重新开始在代码中创建。这有人有类似的经验，希望有更好的解决方案吗？

同样创建数据库需要很长时间：3-5 分钟。我们每个数据库只有 18 个表。我们可以加快速度吗？

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

我们已经查看了代码，并且在 EF6 的边界内，我们认为我们无法对其进行更多优化。我们现在正在查看我们的 Azure 订阅的配置，但文档很吓人，我们无法弄清楚要更改什么以获得更好的性能。

非常感谢任何指导。

4

2 回答 2

1

我在 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 答案是：

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

这不是我所希望的答案。

于 2017-02-02T14:19:42.547 回答
0

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

  1. 创建数据库时，使用至少 5 分钟的超长超时。需要很长时间才能返回。

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

现在，对像这样的常规程序流使用 try/catch 并一遍又一遍地访问资源通常是一种不好的做法，但是，这是我发现的唯一一种在 100% 的时间内都可以解决这个问题的方法。

于 2017-03-30T23:21:23.217 回答