資料庫層級移轉的基礎是 Oracle 歸檔記錄檔、其中包含資料庫變更的記錄檔。歸檔記錄通常是備份與還原策略的一部分。恢復程序從還原資料庫開始、然後重新播放一或多個歸檔記錄檔、將資料庫恢復到所需的狀態。這項相同的基本技術可用於執行移轉、幾乎不會中斷營運。更重要的是、這項技術可在不影響原始資料庫的情況下進行移轉、並保留一條向外移轉的路徑。

移轉程序從將資料庫備份還原至次要伺服器開始。您可以透過多種方式進行、但大多數客戶都會使用正常的備份應用程式來還原資料檔案。資料檔案還原後、使用者便可建立記錄傳送方法。目標是建立由主要資料庫所產生的持續歸檔記錄摘要、並在還原的資料庫上重新播放、使兩者都接近相同的狀態。轉換時間到達時、來源資料庫會完全關閉、最後的歸檔記錄會複製並重新播放、有時則會複製重做記錄。重做記錄也必須列入考量、因為它們可能包含已提交的部分最終交易。

在傳輸和重播這些記錄之後、兩個資料庫彼此之間的一致性。此時、大多數客戶都會執行一些基本測試。如果在移轉過程中發生任何錯誤、則記錄重新執行應會報告錯誤並失敗。還是建議您根據已知的查詢或應用程式導向的活動來執行一些快速測試、以驗證組態是否最佳化。在關閉原始資料庫之前建立一個最終測試表格、以確認該表格是否存在於移轉的資料庫中、這也是常見的做法。此步驟可確保在最終記錄同步期間不會發生任何錯誤。

簡單的記錄傳送移轉作業可針對原始資料庫進行頻外設定、這對關鍵任務資料庫特別有用。來源資料庫不需要變更組態、移轉環境的還原和初始組態也不會影響正式作業。設定記錄傳送之後、它會對正式作業伺服器提出一些 I/O 需求。不過、記錄傳送是由簡單的歸檔記錄循序讀取所組成、這對正式作業資料庫效能不太可能有任何影響。

已證實、記錄傳送對於長期、高變更率的移轉專案特別有用。在某個案例中、單一 220TB 資料庫已移轉至距離約 500 英哩的新位置。變更率極高、安全性限制無法使用網路連線。記錄傳送是使用磁帶和快遞業者來執行。原始資料庫的複本最初是使用下列程序來還原。然後、快遞業者每週寄送記錄、直到最後一組磁帶送達時、記錄才會套用至複本資料庫。

在某些情況下、保證提供完整的 DataGuard 環境。使用術語 DataGuard 來指稱任何記錄傳送或待命資料庫組態是不正確的。Oracle DataGuard 是管理資料庫複寫的全方位架構、但它不是複寫技術。在移轉工作中、完整的 DataGuard 環境的主要優點是能從一個資料庫透明切換到另一個資料庫。如果發現問題（例如新環境的效能或網路連線問題）、 Dataguard 也能將切換回原始資料庫。完整設定的 DataGuard 環境不僅需要設定資料庫層、也需要設定應用程式、以便應用程式能夠偵測主要資料庫位置的變更。一般而言、不需要使用 DataGuard 來完成移轉、但有些客戶內部擁有豐富的 DataGuard 專業知識、而且已經仰賴它來進行移轉工作。

如前所述、運用儲存陣列的進階功能有時需要變更資料庫配置。此外、從 ASM 移轉至 NFS 檔案系統等儲存傳輸協定變更、也必然會改變檔案系統配置。

記錄傳送方法（包括 DataGuard ）的主要優點之一是複寫目的地不需要與來源相符。使用記錄傳送方法從 ASM 移轉至一般檔案系統時沒有任何問題、反之亦然。您可以在目的地變更資料檔案的精確配置、以最佳化易插拔資料庫（ PDB ）技術的使用、或選擇性地設定特定檔案的 QoS 控制。換句話說、以記錄傳送為基礎的移轉程序可讓您輕鬆安全地最佳化資料庫儲存配置。

資料庫層級移轉的一項限制是需要第二部伺服器。使用第二部伺服器的方法有兩種：

第一個選項是最簡單的、但在需要非常強大伺服器的大型環境中、使用它可能不可行。第二個選項需要額外的工作、才能將檔案系統重新放置回原始位置。這可以是一項簡單的作業、使用 NFS 做為儲存傳輸協定、因為檔案系統可以從暫存伺服器卸載、然後重新掛載到原始伺服器上。

區塊型檔案系統需要額外的工作、才能更新 FC 分區或 iSCSI 啟動器。對於大多數邏輯磁碟區管理員（包括 ASM ）、 LUN 會在原始伺服器上可用後自動偵測並上線。不過、某些檔案系統和 LVM 實作可能需要更多工作才能匯出和匯入資料。確切的程序可能會有所不同、但通常很容易建立簡單且可重複的程序、以完成移轉並將資料重新存放在原始伺服器上。

雖然可以在單一伺服器環境中設定記錄傳送和複寫資料庫、但新執行個體必須具有不同的處理程序 SID 、才能重新播放記錄。您可以使用不同的 SID 、在不同的處理序識別碼集下暫時開啟資料庫、稍後再變更。然而、這樣做可能會導致許多複雜的管理活動、並使資料庫環境面臨使用者錯誤的風險。

不應低估簡單複製作業的價值。現代化的網路基礎架構可以以每秒 GB 的速度來移動資料、而檔案複製作業則是以高效率的連續讀寫 I/O 為基礎相較於記錄傳送、主機複本作業無法避免造成更多中斷、但移轉不只是資料移動而已。通常包括網路變更、資料庫重新啟動時間和移轉後測試。

複製資料所需的實際時間可能並不重要。此外、複製作業會保留保證的回傳路徑、因為原始資料不會受到影響。如果在移轉過程中遇到任何問題、可以重新啟動原始資料的原始檔案系統。

重組是指 CPU 類型的變更。當資料庫從傳統的 Solaris 、 AIX 或 HP-UX 平台移轉至 x86 Linux 時、由於 CPU 架構的變更、資料必須重新格式化。SPARC 、 IA64 和 Power CPU 稱為 Big endian 處理器、而 x86 和 x86_64 架構則稱為小 endian 。因此、 Oracle 資料檔案中的某些資料會根據使用中的處理器而有不同的訂購方式。

傳統上、客戶都使用 DataPump 跨平台複寫資料。datapump 是一種公用程式、可建立特殊類型的邏輯資料匯出、以便更快地匯入目的地資料庫。因為它會建立資料的邏輯複本、所以 DataPump 會將處理器位準的相依性留在背後。有些客戶仍使用資料平台來重新建立平台、但 Oracle 11g 提供更快速的選項：跨平台可攜式表格空間。這項進階功能可將資料表空間轉換成不同的 endian 格式。這是一種實體轉型、效能優於 DataPump 匯出、它必須將實體位元組轉換為邏輯資料、然後再轉換回實體位元組。

關於 DataPump 和可攜式資料表空間的完整討論不在 NetApp 文件的範圍之內、但 NetApp 根據我們協助客戶移轉至具有新 CPU 架構的新儲存陣列記錄的經驗、提供一些建議：

LVMS 的運作方式是將一組或多個 LUN 拆分為一般稱為擴充的小型單元。然後將擴充集區用作建立邏輯磁碟區的來源、這些邏輯磁碟區基本上是虛擬化的。此虛擬化層以各種方式提供價值：

使用 LVM 移轉的運作方式有兩種：移動範圍或鏡射 / 去除範圍。LVM 移轉使用高效率的大型區塊連續 I/O 、而且很少會造成任何效能問題。如果這確實是問題、通常有節流 I/O 速率的選項。如此可增加完成移轉所需的時間、同時減輕主機和儲存系統的 I/O 負擔。

Oracle ASM 是結合邏輯 Volume Manager 與檔案系統的產品。在較高層級、 Oracle ASM 會將 LUN 集合起來、分成小的分配單元、並將其呈現為稱為 ASM 磁碟群組的單一磁碟區。ASM 也能透過設定備援層級來鏡射磁碟群組。磁碟區可以是無鏡射（外部備援）、鏡射（正常備援）或三向鏡射（高備援）。設定備援層級時、請務必謹慎、因為建立後無法變更。

ASM 也提供檔案系統功能。雖然檔案系統無法直接從主機看到、但 Oracle 資料庫仍可在 ASM 磁碟群組上建立、移動及刪除檔案與目錄。此外、您也可以使用 asmcmd 公用程式來瀏覽結構。

與其他 LVM 實作一樣、 Oracle ASM 也會在所有可用 LUN 之間、對每個檔案的 I/O 進行分拆和負載平衡、以最佳化 I/O 效能。其次、基礎擴充可重新定位、以便同時調整 ASM 磁碟群組的大小和移轉。Oracle ASM 會透過重新平衡作業來自動化程序。新的 LUN 會新增至 ASM 磁碟群組、而舊的 LUN 會被丟棄、這會觸發磁碟群組中的磁碟區重新配置及後續刪除已清空的 LUN 。此程序是最獲證實的移轉方法之一、而 ASM 提供透明移轉的可靠性、可能是最重要的功能。

使用 NetApp SnapMirror 資料複寫軟體、幾乎可以通用地從 NetApp 系統之間移轉資料庫。此程序包括為要移轉的磁碟區設定鏡射關係、允許它們進行同步處理、然後等待轉換時間。當來源資料庫到達時、即會關閉、執行最後一個鏡像更新、而且鏡像也會中斷。然後、複本磁碟區就可以開始使用、方法是掛載包含的 NFS 檔案系統目錄、或是探索包含的 LUN 並啟動資料庫。

在單一 ONTAP 叢集中重新放置磁碟區並不視為移轉作業、而是例行作業 volume move 營運。SnapMirror 用作叢集中的資料複寫引擎。此程序完全自動化。當磁碟區的屬性（例如 LUN 對應或 NFS 匯出權限）與磁碟區本身一起移動時、無需執行其他移轉步驟。重新配置不會中斷主機作業。在某些情況下、必須更新網路存取、以確保以最有效率的方式存取新重新部署的資料、但這些工作也不會中斷營運。

FLI 是一項功能、可讓執行 8.3 或更高版本的 Data ONTAP 系統從另一個儲存陣列移轉現有 LUN 。此程序很簡單： ONTAP 系統會分區到現有的儲存陣列、就像是任何其他 SAN 主機一樣。然後 Data ONTAP 控制所需的舊版 LUN 、並移轉基礎資料。此外、匯入程序會在資料移轉時使用新 Volume 的效率設定、也就是說、資料可以在移轉過程中內嵌進行壓縮及刪除重複資料。

Data ONTAP 8.3 中首次實作的 FLI 僅允許離線移轉。這是非常快速的傳輸、但仍表示在移轉完成之前、 LUN 資料無法使用。線上移轉是在 Data ONTAP 8.3.1 中推出。這類移轉可讓 ONTAP 在傳輸過程中提供 LUN 資料、將中斷情形減至最低。當主機重新分區以透過 ONTAP 使用 LUN 時、會發生短暫的中斷。不過、一旦進行這些變更、資料就會再次存取、並在整個移轉程序中保持可存取的狀態。

讀取 I/O 會透過 ONTAP 代理、直到複製作業完成為止、而寫入 I/O 會同步寫入外部和 ONTAP LUN 。這兩個 LUN 複本會以這種方式保持同步、直到系統管理員執行完整的轉換程式來釋放外部 LUN 、而不再複寫寫入內容。

FLI 的設計可與 FC 搭配使用、但如果您想要變更為 iSCSI 、則可在移轉完成後、輕鬆將移轉的 LUN 重新對應為 iSCSI LUN 。

FLI 的功能包括自動對齊偵測與調整。在這種情況下、「對齊」一詞是指 LUN 裝置上的分割區。最佳效能需要將 I/O 與 4K 區塊對齊。如果分割區的偏移量不是 4K 的倍數、效能就會受到影響。

第二個對齊層面無法透過調整分割區偏移（檔案系統區塊大小）來修正。例如、 ZFS 檔案系統通常預設為 512 位元組的內部區塊大小。其他使用 AIX 的客戶偶爾會建立具有 512 或 1 、 024 位元組區塊大小的 JFS2 檔案系統。雖然檔案系統可能會與 4K 邊界對齊、但在該檔案系統中建立的檔案不會受到影響、效能也會受到影響。

在此情況下不應使用 FLI 。雖然資料在移轉後仍可存取、但結果是檔案系統的效能嚴重限制。一般而言、任何支援 ONTAP 上隨機覆寫工作負載的檔案系統、都應該使用 4K 區塊大小。這主要適用於資料庫資料檔案和 VDI 部署等工作負載。區塊大小可使用相關的主機作業系統命令來識別。

例如、在 AIX 上、可以使用檢視區塊大小 lsfs -q。使用 Linux 、 xfs_info 和 tune2fs 可用於 xfs 和 ext3/ext4。與 zfs、命令是 zdb -C。

控制區塊大小的參數為 ashift 而且通常預設值為 9 ，即 2^9 或 512 位元組。為了獲得最佳效能 ashift 值必須為 12 （ 2^12=4K ）。此值是在創建 zpool 時設置的，不能更改，這意味着使用的數據 zpool ashift 除 12 個以外、應將資料複製到新建立的 zPool 、以進行移轉。

Oracle ASM 沒有基本區塊大小。唯一的要求是必須正確對齊 ASM 磁碟所在的磁碟分割區。

7-Mode Transition Tool （ 7MTT ）是一種自動化公用程式、用於將大型 7-Mode 組態移轉至 ONTAP 。大多數資料庫客戶發現其他方法都比較容易、部分原因是他們通常會依資料庫來移轉環境資料庫、而非重新配置整個儲存設備佔用空間。此外、資料庫通常只是較大型儲存環境的一部分。因此、資料庫通常會個別移轉、其餘的環境則可以使用 7MTT 進行移轉。

有少數客戶擁有專為複雜資料庫環境設計的儲存系統。這些環境可能包含許多磁碟區、快照和許多組態詳細資料、例如匯出權限、 LUN 啟動器群組、使用者權限和輕量型目錄存取傳輸協定組態。在這種情況下、 7MTT 的自動化功能可簡化移轉作業。

7MTT 可在下列兩種模式中的其中一種運作：

這兩種選項的主要差異在於：無複製轉換是一種非常有效的方法、其中所有連接至原始 7-Mode HA 配對的磁碟櫃都必須重新放置到新環境中。沒有選項可以移動一部分機櫃。複製型方法可讓選取的磁碟區移動。此外、由於可重新儲存磁碟櫃和轉換中繼資料所需的連結、因此也可能會有較長的轉換時間、且無需複製。根據現場經驗、 NetApp 建議允許 1 小時重新配置及重新配置磁碟櫃、 15 分鐘至 2 小時的中繼資料轉換時間。