將 SQL DB 部署到 Azure 超時啟用索引

Question

我們有一個在 Azure 中托管的項目，我們將 SQL 服務器存儲在彈性池中。 我們擁有的數據庫是從 .NET 框架的 Code First 遷移生成的； 我們使用一些 SQL 導入腳本將數據加載到數據庫中。

問題在於將數據庫部署到 Azure。 我們已經嘗試在開發機器和 sql 服務器上使用 SQL Server Management Studio。 我們嘗試使用將數據庫部署到 Microsoft SQL Azure 將數據庫推送到 Azure，並嘗試使用 BACPAC 直接連接到 Azure 和導入數據層應用程序。 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.6 gigs，確實有 2 個大表，大約有 1 個軋機行； 雖然我不認為這是一個太大的數據庫，這個過程應該失敗。

Answer 1

不是問題的直接解決方案，但我在 SSMS 中測試大型數據庫遷移時遇到過這種情況。 擴展可用資源似乎有幫助，但這意味着重新啟動部署過程。

重建所有索引應該是遷移的最后一個操作，以避免重做您可以自己執行的所有操作，例如：

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在游標定義中添加到sys.schemas的連接，並使用它在表名之前添加適當的模式名稱。}

---

在評論中，Kevin 建議此時可以禁用觸發器，盡管在我遇到這種情況時情況並非如此。 以防萬一，在當前EXEC (@sql);之后添加以下內容EXEC (@sql); 在上面的例子中：

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

如果觸發器已經處於活動狀態，那么這本質上是一個 NoOp，因此不會造成任何傷害。 請注意，如果觸發器尚未定義，這將無濟於事，但它們應該在重建索引時完成，因為這是流程早期架構構建的一部分。

Answer 2

SQL DB 的設計目的是讓您可以針對大型操作進行縱向擴展，並在工作負載較安靜時縮減規模？ 如果您仍然收到錯誤消息，為什么不擴展到 S3 一兩個小時（SQL DB 賬單以小時為單位）完成導入並縮減？