探索大型資料庫的移轉
SAP 系統現在已移至 Azure 雲端，普遍包含大型的跨國「單一全域執行個體」系統。 比起 Azure 首次通過 SAP 工作負載時所部署的第一個客戶系統，這些系統大了許多倍。
超大型資料庫 (VLDB) 現在一般都會移至 Azure。 超過 20 TB 的資料庫大小需要額外的技術和程序，才能在低風險的情況下，於可接受的停機時間內，從內部部署移轉至 Azure。
高階概述
完全最佳化的大型資料庫移轉，至少需要達到每小時 2 TB (甚至更高) 的移轉輸送量。 這表示 20-TB 移轉的資料傳輸部份，可在約 10 小時內完成。 還需要完成各種後置處理和驗證步驟。 一般而言，只要有適當的時間進行準備和測試，幾乎任何規模的客戶系統皆可移至 Azure。
VLDB 移轉需要大量的技能、對細節的關注及分析。 例如，必須測量和分析資料表分割的淨影響。 將大型資料表分割成超過 50 份平行匯出，可能會大幅減少匯出資料表所需的時間，但太多資料表分割可能會導致匯入時間大幅增加。 因此，必須計算及測試資料表分割最後會產生的影響。 專家授權的 OS/DB 移轉顧問會熟悉此概念和工具。 我們將著重於 VLDB 移轉的 Azure 專屬內容。
具體而言，我們會使用 R3load 和 Migmon 等工具，來處理異質性 OS/DB 到 Azure 的移轉 (以 SQL Server 為目標資料庫)。 移轉步驟不適用於同質系統複本，也就是 DBMS 和處理器架構 (位元組順序) 維持不變的複本。 一般情況下，因為記錄傳送可用於同步 Azure 中的資料庫複本，所以無論 DBMS 的大小為何，同質系統複本的停機時間都應該很短。
說明一般 VLDB OS/DB 移轉的區塊圖，並在關鍵點之後移至 Azure：
目前的來源 OS/DB 通常是 AIX、HPUX、Solaris 或 Linux，以及 DB2 或 Oracle。
目標 OS 可以是 Windows、Suse 12.3、Red Hat 7.x 或 Oracle Linux 7.x。
目標 DB 通常是 SQL Server 或 Oracle 12.2。
IBM pSeries、Solaris SPARC 硬體和 HP Superdome 執行緒效能，遠低於低成本的新款 Intel 商用伺服器，因此 R3load 會在不同的 Intel 伺服器上執行。
VMWare 需要進行特殊調整和設定，才能達到良好、穩定且可預測的網路效能。 實體伺服器通常用來作為 R3load 伺服器，而不是虛擬機器。
通常會使用四個匯出 R3load 伺服器，但匯出伺服器的數目沒有任何限制。 典型的設定如下：
- 匯出伺服器 1: 專用於最大的 1 到 4 個資料表 (取決於資料分佈在來源資料庫上的扭曲程度)。
- 匯出伺服器 2: 專用於具有資料表分割的資料表。
- 匯出伺服器 3: 專用於具有資料表分割的資料表。
- 匯出伺服器 4: 所有其他資料表。
匯出傾印檔案會透過公用網際網路，從 Intel R3load 伺服器中的本機磁碟傳輸到 Azure。 這通常比透過 ExpressRoute 快。
匯入的控制與順序是透過在所有匯出套件完成後自動產生的訊號檔案 (SGN) 進行。 這讓半平行的匯出/匯入得以進行。
匯入 SQL Server 或 Oracle 中，在結構上與匯出相似，會使用四個匯入伺服器。 這些伺服器會是具備加速網路的其他專用 R3load 伺服器。 建議您不要針對這項工作使用 SAP 應用程式伺服器。
VLDB 資料庫通常會使用具有進階記憶體的 E64v3、m64 或 m128 虛擬機器。 可以將交易記錄放在本機固態硬碟上，加速變更檔的寫入，並從 VM 配額中移除變更檔 IOPS 和 IO 頻寬。 在移轉之後，交易記錄應置於永續性磁碟中。
