分析工具選取和移轉模型的決策準則

既然我們已探索移轉方法和工具選項的選項，我們可以探索需要考慮的決策準則，以執行移轉至適用於 PostgreSQL 的 Azure 資料庫彈性伺服器。 協助我們做出選擇的三個主要準則是 停機時間、源資料庫位置，以及 可自定義性。

停機時間

停機時間是移轉活動的關鍵面向，項目關係人可以接受的持續時間可協助我們決定是否必須執行離線或在線移轉活動。

通常，移轉活動會事先規劃好，以確保活動已完成適當的變更控件和相關聯的治理。 此規劃會與重要利害關係人對話，以了解系統可以離線多久。 在此情況下，建議您知道不同選項需要多久的時間，才能建立預估的最短和最大停機時間。

明確規劃執行應用程式切換所需的最短停機時間是關鍵。 最後，此時間是系統離線所需的時間長度，即使是線上 (或最短停機時間) 移轉作業。 應用程式的複雜性會決定這個時幅。 對於相對簡單的應用程式，此程式可能是停止服務、更新組態檔，然後重新開啟它的情況。 在更複雜的環境中，如果有多個伺服器和應用層可供使用，此程式可能需要更長的時間。

瞭解在線或離線移轉活動所需的持續時間，是與停機時間相關的下一個重要元素。 如果是離線移轉，則從來源擷取、傳輸和載入數據到目的地所花費的時間，後面接著驗證和驗證就是您的停機時間。 然後，此停機時間會夾在關閉應用程式/工作負載所需的時間，以及開啟應用程式/工作負載所需的時間之間。

如果是在線（最短停機時間）的移轉，停機時間是關閉應用程式後，將來源的最終變更同步處理至目的地所需的持續時間。 加入中斷時間，以及驗證和確認活動，然後重新設定並啟用應用程式/工作負載。

有了這項資訊之後，我們可以查看移轉的技術元素，以協助建立可行的選項。

源資料庫位置

要移轉的資料庫來源位置可能因任何特定組態中可能存在的限制而受到影響。

內部部署或非 Azure 來源

對於內部部署或非 Azure 位置資料庫，索引鍵條件約束通常是來源與目標之間的網路連線。 這裡要考慮的三點是頻寬、延遲和數據量。 一旦了解這些點，我們可以做出明智的決策，以瞭解哪種類型的移轉是可行的。

如果有大量要移轉的資料且頻寬比例較小，則可能無法進行簡單備份和還原。 而如果我們有大量數據和大量的頻寬，則不太擔心。

同樣地，如果是進行數據同步處理的在線移轉，則延遲是其中一個關鍵因素。 如果延遲很高，可能會對系統效能造成負面影響，因為同步處理程式需要太長的時間才能完成。

從其他雲端提供者移轉時，要考慮的一個重要因素是它們是否收取數據輸出費用。 如果是這樣，能夠將所傳輸數據的實體佔用空間降到最低可能是需要考慮的因素。 在這種情況下，壓縮技術對於用於同步用途的轉儲或數據流而言非常重要。

其他以 Azure 為基礎的服務

在某些情況下，您想要從其他 Azure 服務遷移至適用於 PostgreSQL 的 Azure 資料庫彈性伺服器。 這些來源資料庫可能位於 Azure VM、容器，或者可能位於適用於 PostgreSQL 的 Azure 資料庫單一伺服器。 若是，則需要探索一組不同的考量事項，但同時針對這些情況，也有很多機會能受益於 Azure 服務的最佳化。

可自定義性

考慮的最後一個區域是需要或想要多少客製化。 此考慮可以採取需要修改源資料庫結構以支援數據複寫的形式，或者，它可能表示您透過腳本自動化是多麼容易。

一個很好的範例是透過pg_dump和pg_restore將資料庫的離線移轉自動化，但同時包含傾印檔案的壓縮和解壓縮。

決策

既然我們已完成收集所有此資訊的程式，我們可以與項目關係人合作，以判斷指定案例的最佳選項。 在決定哪些方法和技術設定為使用時，不僅要與業務項目關係人合作，而且與技術項目關係人合作非常重要。 這項合作有助於避免企業追求最短停機時間的移轉，而技術團隊因人員配置、資源或技術限制而無法實現的情況。

這裡的關鍵是管理期望，並有一個開放和誠實的對話。 此外，務必確保企業會取得驗證任務的擁有權，這些任務超出負責資料庫遷移的技術小組的職責範圍。 這項驗證可能涉及數據一致性和驗證檢查，以及用戶體驗測試。