长时间的 Azure SQL 数据库导入，100% DTU - 更改恢复期间的层有帮助吗？答案

【问题标题】：Long Azure SQL database import, 100% DTU - will changing tier for period of restore helps?长时间的 Azure SQL 数据库导入，100% DTU - 更改恢复期间的层有帮助吗？
【发布时间】：2016-01-22 20:26:38
【问题描述】：

我们在 blob 中从 bacpac 导入 azure 数据库，100%DTU 需要 2 天时间。有时我接受快速但昂贵的恢复（但只想为恢复时间支付额外费用），我该怎么做？

如果我将层级更改为具有 100 或 200 个 DTU 的更高级别，是否会加快恢复速度？另外，如果我在恢复开始后执行此操作，是否会应用更改，或者我必须在开始导入时首先执行此操作？

还原后，我将切换回所需的 S2 层。另一个子问题是降级数据库层的潜在风险是什么？至少我知道需要禁用异地复制。

根据https://msdn.microsoft.com/en-us/library/azure/dn369872.aspx，升级后可能需要数小时才能应用和正常化性能，通常在降级后需要数小时。

如此理想的方式是在最大 P6 层开始恢复，然后降级到 S2，而且在大多数情况下必须是暂时的？

具体案例详情：数据库大小 ~ 60 gb，bacpac ~ 5 gb，S2 标准（50 个 DTU）。我看到整个恢复时间的 DTU 百分比为 100%，最后一天的导入导出历史记录停留在“状态正在运行，进度 = 94.81 %”，而数据库大小从 30 Gb 缓慢增加到 60 Gb。

'select * from sys.dm_db_resource_stats' gives for example this

avg_cpu_percent=42.96
avg_data_io_percent=37.08
avg_log_write_percent=91.65
avg_memory_usage_percent=83.67

【问题讨论】：

当您拥有built-in backup restore 时，如果您能了解为什么要使用 Import/Export，那就太好了。如果您可以利用内置的备份恢复功能，您的恢复应该比导入快得多。
我们有两个 azure 帐户（一个用于生产，一个用于开发）并且必须在它们之间移动数据库。导出到 bacpac，通过服务器端使用异步跨帐户复制 blob 在 blob 之间移动它们，然后导入是我知道的正确方法。
你有没有解决这个问题？切换层会影响恢复时间吗？
是的，更好的层减少恢复时间
我现在正在运行大型导入，我得到的最大 DTU 使用率为 40%，根据您的经验，不能指望 100% 吗？

标签： azure-sql-database

【解决方案1】：

根据您的描述，Azure SQL DB 正在按预期执行。与您的服务层和性能级别关联的 DTU 确实会影响导入时间。您应该在导入时升级到更高的性能级别，然后再降级。

希望对你有帮助

【讨论】：

我现在正在运行大型导入，我得到的最大 DTU 使用率为 40%，难道不能指望 100% 吗？

【解决方案2】：

根据您描述的场景，最好使用数据库副本 TSQL 进行跨服务器数据库副本。我假设您在导出时首先创建一个数据库副本，以保证您最终得到一个事务一致的 BACPAC 作为suggested by this article。如果是这种情况，您只需将数据库直接复制到目标帐户和服务器即可节省一些性能。只要源服务器和目标服务器具有相同的 SQL 登录信息，Cross server copy 就可以工作。

确认两台服务器共享相同的登录凭据后，您只需登录到要将数据库复制到的服务器的主数据库，然后运行以下 TSQL：

CREATE DATABASE [NEW_DATABASE_NAME] AS COPY OF [SOURCE_SERVER_NAME].[SOURCE_DATABASE_NAME]

这应该会大大节省您的时间，因为导出方法需要您读出数据库的所有数据和架构。然后您需要复制该文件（再次移动数据）。然后您需要将所有数据读入新数据库（第三次移动数据）。

说了这么多，如果你绝对需要使用导出和导入服务，使用更高服务层的导出和导入将比更低的服务层更快，因为你有更多的资源可以更快地读取和读取数据。

如果您想澄清任何事情，请回复此内容。

【讨论】：