azure - 主动异地复制能否用于分离读写负载以提高性能？

Question

我们在从 SQL Azure 中获得所需的性能时遇到了困难，我很好奇是否有人尝试过使用主动异地复制来分割读写负载以提高性能，无论成功还是失败？

我们的一个数据库似乎非常适合这一点。此数据库上发生的唯一写入来自从第三方服务以 xml 文件形式下载数据更新的应用程序；它处理这些文件以更新数据。文件频繁进入，应用程序每分钟执行几百到几千次插入和更新。该应用程序由我们的数据提供商提供。目前还无法对其更新程序进行改进，例如批量插入和更新语句。他们的更新程序是用 perl 编写的并使用 ODBC。我们已更新到最新的 SQL Server ODBC 驱动程序 11，以在连接字符串中启用连接重试。

读取发生在我们的 .Net Web 服务中。它执行的查询非常繁重，有很多连接。我们已经进行了大量的调整和缓存来减少数据库的负载。当我们在安装在一些中间租赁服务器硬件上的 SQL Server 上运行它时，我们完全在容量范围内。现在我们已经结束了 SQL Azure，即使在高级 P2 级别，处理速度也很慢。目前进入 P3 的成本过高。

今天早些时候，我设置了主动可读辅助，但我没有看到我所期望的结果。唯一连接到我们的可写主机的是更新程序应用程序。我们的网络服务正在连接到可读的辅助设备。然而，Azure 的门户显示了我们主服务器上的所有负载:

我还注意到，自设置事件辅助设备以来，我们的平均 DTU 使用百分比增加了约 20%。

如果我执行SELECT SUM(execution_count) FROM sys.dm_exec_query_stats，每个数据库上的总执行次数接近相同。如果我坐下来刷新SELECT * FROM sys.dm_exec_requests CROSS APPLY sys.dm_exec_sql_text(sql_handle)，我还会看到每个数据库上运行的查询数量相似。此外，我们的读取查询使用我们创建的 View ，并且我在每个数据库上看到我们的查询 - 不仅仅是查询更新应用程序运行(它不知道我们的 View )。

谁能帮我理解这里发生了什么？如果这两个查询没有在辅助设备上显示执行情况，我想说我们甚至没有连接到它。我们从一个 DTU 约为 60-70% 的 P2 DB 变为两个 P2 DB，其中一个 DTU 约为 90%，另一个 DTU 约为 0%。因此，现在我们支付的费用是原来的两倍，而且我们可用的资源似乎更少。

我们认为这里应该有 2x P2 总 DTU，这是错误的吗？对于事件异地复制集，Azure 是否只为您提供一个数据库的资源？统计数据是否以某种方式组合在一起，导致我没有真正看到这些查询对每个数据库的影响？

Answer 1

我们的辅助服务器未接收查询的问题是我们的连接字符串使用了“user@primary-server”的用户 ID。即使主机名用于辅助服务器，连接仍然会转到主服务器。一旦我们使用“user@secondary-server”，我们的读取负载就会按预期转移到辅助服务器。

至于以这种方式分割负载的有用性..到目前为止，看起来以这种方式使用两个 P1 为我们提供了大约相同的容量，也许比单个 P2 稍微多一点(我们还没有运行基准测试，只是根据我们的正常流量负载来判断已用容量)。此设置提供的一个优点是，我们可以将其中一个或两个数据库放在 P2 上，以实现 P2 和 P3 数据库之间的资源级别(很有用，因为这两者之间的价格差异相当大)。