探索大型資料庫的移轉
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 伺服器，而非 VM。
通常會使用四個匯出 R3load 伺服器，但匯出伺服器的數目沒有任何限制。 典型的設定如下：
- 匯出伺服器 1 ‒ 專用於最大的 1 到 4 個資料表 (取決於資料分佈在來源資料庫上的扭曲程度)
- 匯出伺服器 2 ‒ 專用於進行過資料表分割的資料表
- 匯出伺服器 3 ‒ 專用於進行過資料表分割的資料表
- 匯出伺服器 4 ‒ 所有其他資料表
匯出傾印檔案會透過公用網際網路，從 Intel R3load 伺服器中的本機磁碟傳輸到 Azure。 這通常比透過 ExpressRoute 快。
匯入的控制與順序是透過訊號檔案 (SGN) 進行，該檔案則在所有匯出套件完成後自動產生。 這讓半平行的匯出/匯入得以進行。
匯入 SQL Server 或 Oracle 中，在結構上與匯出相似，會使用四個匯入伺服器。 這些伺服器會是具備加速網路的其他專用 R3load 伺服器。 對於這項工作，建議不要使用 SAP 應用程式伺服器。
VLDB 資料庫通常會使用具有進階儲存體的 E64v3、m64 或 m128 VM。 您可以將交易記錄放在本機 SSD 磁碟上，加速交易記錄的寫入，然後從 VM 配額中移除交易記錄 IOPS 和 IO 頻寬。 在移轉之後，交易記錄應置於永續性磁碟中。
