C# 将SQL DB部署到Azure超时启用索引

我们在Azure中托管了一个项目，我们的SQL服务器存储在一个弹性池中。我们拥有的数据库是从.NET framework的代码优先迁移生成的；我们使用一些SQL导入脚本将数据加载到数据库中

问题在于将数据库部署到Azure。我们已经尝试在开发人员机器和SQL Server上使用SQL Server Management Studio。我们已尝试使用将数据库部署到Microsoft SQL Azure将数据库推送到Azure，并尝试直接连接到Azure并使用BACPAC导入数据层应用程序。SQL server 2014 12.0.4439.1是我们的服务器版本

在部署过程中，一切似乎都进展得非常快，模式被创建，数据被加载到表中，但它在大部分过程时间都挂在“启用索引”上，大约一小时后，整个过程超时并失败。我收到3个错误；第一个是错误0；以SQL server 2014为目标的数据库文件与SQL azure v12的兼容性非常神秘。另一个是关于超时的，带有进程已超时的一般消息。最后一个错误是注释

Could not import package.
Error SQL72016: Execution Timeout Expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
The statement has been terminated.
Error SQL72045: Script execution error.  The executed script:

Bulk data is loaded

---

在做了一些研究之后，我看到一些其他人抱怨说，如果使用基本层，则没有足够的DTU使流程在时间限制内运行。我们正在为数据库使用标准1层，并尝试将其升级到S2以用于导入过程作为测试。虽然事情似乎发生得更快，但我们也遇到了同样的问题。数据库为1.6Gigs，有2个大型表，其中约有1行轧机；虽然我不认为这是一个如此大的数据库，以至于这个过程会失败。

SQL DB的设计是为了在工作负载较安静时，您可以放大大型操作，缩小规模？如果仍然收到错误，为什么不在一个S3上扩展一两个小时（SQL DB账单以小时为增量）完成导入并缩小规模？

这不是问题的直接解决方案，但我在SSM中测试大型数据库迁移时遇到过这种情况。扩展可用资源似乎有帮助，但这意味着重新启动部署过程

重建所有索引应该是迁移的最后一个操作，以避免重做您可以自己执行的所有操作，例如：

DECLARE C CURSOR FAST_FORWARD FOR 
    SELECT so.name, si.name
    FROM sys.indexes si JOIN sys.objects so ON so.object_id = si.object_id 
    WHERE is_disabled = 1 
    ORDER BY CASE WHEN si.type_desc='CLUSTERED' THEN 0 ELSE 1 END, si.name; -- clustered first as disabled clustered index will stop others rebuilding
DECLARE @tbl NVARCHAR(MAX), @idx NVARCHAR(MAX), @start DATETIME, @sql NVARCHAR(MAX);

OPEN C;
FETCH NEXT FROM C INTO @tbl, @idx;
WHILE @@FETCH_STATUS = 0 BEGIN
    SET @sql = 'ALTER INDEX ['+@idx+'] ON ['+@tbl+'] REBUILD;';
    EXEC (@sql);
    FETCH NEXT FROM C INTO @tbl, @idx;
END
CLOSE C;
DEALLOCATE C;

我发现在重建过程中出现超时错误，而重建本身需要>5分钟。我没有考虑是否可以在迁移过程中配置此每次操作超时

请注意，以上假设所有表都在dbo模式中，如果不是这种情况，请在游标定义中添加一个连接到

sys.schemas

，并使用它将适当的模式名称前置到表名称

---

在评论中，凯文建议此时可能会禁用触发器，尽管我遇到这种情况时并非如此。以防万一，在当前

EXEC（@sql）之后添加以下内容在上述示例中：

    SET @sql = 'ALTER TABLE ['+@tbl+'] ENABLE TRIGGER ALL;';
    EXEC (@sql);

如果触发器已经激活，那么这本质上是一个NoOp，因此不会造成任何伤害。请注意，如果尚未定义触发器，这将没有帮助，但在重建索引时，它们应该已经存在，因为这是该过程早期架构构建的一部分。
再次运行该过程，以便我可以获得确切的错误消息，警告SQL0：指定SQL Server 2014作为目标平台的项目可能会遇到与Microsoft Azure SQL数据库v12的兼容性问题。错误SQL72016:超时已过期。操作完成前已过超时时间，或者服务器没有响应。声明已终止。错误SQL72045:脚本执行错误。已执行的脚本：/*数据在部署执行*/（Microsoft.SqlServer.Dac）的此时进行了大容量加载。我可以使用上的SQL数据库迁移向导制作我的数据库的副本，并检查其兼容性问题，它还将其与数据一起上载到Azure。您还应该能够使用SQL Server 2016升级顾问来执行相同的操作，但我没有对此进行测试。您是否也可以发布错误，我们从未发现表大小超过同一层的表的问题。我还建议在通过所有验证后将bacpac上载到存储，并从中导入there@TheGameiswar我确实发布了我在第一次评论中收到的错误消息的确切信息。我已尝试使用bacpac和上载程序，但我没有尝试将bacpac上载到Blob存储，然后从那里运行导入。在这一点上，我坚信使用Bacpac存在兼容性问题。我们确实尝试了这种方法，但这并没有解决问题。实际上，我们将服务器扩展到了两个级别。这并没有解决问题。此外，DTU的使用量仅在前10分钟固定在最大使用量。然后，它进入了一系列重复的尖峰。移动到一个“P”级的发布服务器为我解决了这个问题。S1到S3没有。通过确保我的目标与souce Azure Sql DTU/磁盘空间参数匹配，这对我也有效。e、 g.P2/250GB=>P/250GB。这确实使非产品环境的规模缩小变得更加困难，因为您需要在导入过程中进行一些放大/缩小操作。不！迁移也会关闭触发器（例如），因此假设唯一缺少的步骤是重建索引是错误的。当我遇到此问题时，未受影响的触发器可能会在索引重建发生时启用（进程失败的点）。为了以防万一，我将添加一个注释来警告其他人。我在原始数据库和迁移失败的数据库之间进行了架构比较，触发器定义本身都包含了一行额外的代码来禁用触发器。我认为该工具会生成触发器并立即禁用它们，这样它们就不会在数据迁移时触发。在我的例子中，触发器定义本身是