Azure SQL 数据库时间点还原耗时超过 24 小时

如何解决Azure SQL 数据库时间点还原耗时超过 24 小时

我一直在尝试对 2GB S0 Azure sql Server 数据库进行 PITR。它已经运行了超过 24 小时。 DB 恢复进度一直说 50% 已完成 18 小时没有任何错误。我应该升级服务器 DTU 和大小还是实际的服务层？

解决方法

根据此post。在 SQL 数据库上，“马力”由数据库吞吐量单位或仅“DTU”来衡量。该单位以整数衡量，可能在 5 到 1750 之间变化。每个数据库版本都有一个或多个“服务目标”的报价，这些报价与 DTU 的数量和要播放的价格直接相关。
在下图中，您可以找到每个 SQL 数据库版本的“服务目标”（S0、P3、Basic、P11、S3 等）列表及其各自的价格。请注意，Microsoft 一直在更新其报价，因此当您阅读这篇文章时，这些​​价格和每个版本的服务目标可能已经过时：

一种选择是更保守、负责和有尊严的方式来选择 DTU 的数量，并且基于有关您的数据库活动的真实数据。它是 DTU 计算器 (http://dtucalculator.azurewebsites.net/)，这是一项在线服务，可通过建议最适合数据库的服务目标来帮助我们。您只需要下载 DTU Calculator 网站上提供的 PowerShell 脚本，然后在您的数据库所在的服务器中运行它。运行此脚本后，将测量以下数据并将其记录在 CSV 文件中：

• 处理器 - % 处理器时间
• 逻辑磁盘 - 磁盘读取数/秒
• 逻辑磁盘 - 磁盘写入数/秒
• 数据库 – 刷新日志字节数/秒
  收集完成后，您只需上传脚本生成的文件并解释结果。以下是 DTU 计算器生成的图表之一的示例，表明 89.83% 的数据库负载可以在“标准”SQL 数据库版本的服务目标 S3 下运行良好。
  
  这是一个决策树，可帮助您达到数据库的最佳点。
  所以我认为你可以适当增加 DTU 来加快进程。 :)

,

如果您在 S0 上，则使用的是 Azure SQL 数据库，而不是托管实例。

2GB很小，应该是一个小时左右的时间点恢复。

联系微软支持。