最佳移轉選項取決於多種因素、包括要移轉的環境規模、避免停機的需求、以及執行移轉所需的整體工作。大型資料庫顯然需要更多時間和精力來進行移轉、但這類移轉的複雜度極低。小型資料庫可以快速移轉、但如果要移轉數千個資料庫、則工作規模可能會造成複雜問題。最後、資料庫越大、業務關鍵的可能性就越大、因此需要將停機時間降至最低、同時保留一條後端路徑。

此處將討論規劃移轉策略的一些考量事項。

要移轉的資料庫大小顯然會影響移轉規劃、但大小不一定會影響轉換時間。當必須移轉大量資料時、主要考量的是頻寬。複製作業通常是以高效率的連續 I/O 來執行保守估計、假設複製作業的可用網路頻寬使用率為 50% 。例如、 8GB FC 連接埠理論上可傳輸約 800MBps 。假設使用率為 50% 、則資料庫的複製速度約為 400Mbps 。因此、 10TB 資料庫可在此速率下在大約七小時內複製。

遠距離移轉通常需要更具創意的方法、例如中所說明的記錄傳送程序 "線上資料檔案移動"。遠距 IP 網路在任何接近 LAN 或 SAN 速度的地方、都很少會有頻寬。在某種情況下、 NetApp 協助 220 TB 資料庫進行遠距移轉、而且產生的歸檔記錄率非常高。所選的資料傳輸方法是每天運送磁帶、因為這種方法提供最大可能的頻寬。

在許多情況下、移動大量資料的問題並不是資料大小、而是支援資料庫的組態複雜度。只要知道必須移轉 50TB 的資料庫、就無法獲得足夠的資訊。它可以是單一 50TB 關鍵任務資料庫、 4 、 000 個舊資料庫的集合、或是正式作業和非正式作業資料的混合。在某些情況下、大部分資料是由來源資料庫的複本所組成。這些複本完全不需要移轉、因為它們可以輕鬆地重新建立、特別是當新架構設計為使用 NetApp FlexClone Volume 時。

在移轉規劃方面、您必須瞭解範圍內有多少資料庫、以及它們的優先順序。隨著資料庫數量的增加、偏好的移轉選項在堆疊中會較低和較低。例如、在 RMAN 和短暫停機的情況下、複製單一資料庫可能很容易。這是主機層級的複寫。

如果有 50 個資料庫、可能會更容易避免設定新的檔案系統結構來接收 RMAN 複本、而改為將資料移到適當位置。此程序可透過利用主機型 LVM 移轉來將資料從舊 LUN 重新放置到新的 LUN 來完成。這樣做會將責任從資料庫管理員（ DBA ）團隊移轉至作業系統團隊、因此資料會以透明方式移轉至資料庫。檔案系統組態不變。

最後、如果必須移轉 200 部伺服器上的 500 個資料庫、則可使用 ONTAP 外部 LUN 匯入（ FLI ）功能等儲存型選項來執行 LUN 的直接移轉。

一般而言、必須變更資料庫檔案配置才能運用新儲存陣列的功能、但情況並非總是如此。例如、 EF 系列 All Flash 陣列的功能主要是針對 SAN 效能和 SAN 可靠性。在大多數情況下、資料庫可以移轉至 EF 系列陣列、而無需特別考量資料配置。唯一的要求是高 IOPS 、低延遲和強大的可靠性。雖然 RAID 組態或動態磁碟集區等因素都有最佳實務做法、但 EF 系列專案很少需要對整體儲存架構進行任何重大變更、才能運用這些功能。

相反地、移轉至 ONTAP 通常需要更多考量資料庫配置、以確保最終組態能提供最大價值。ONTAP 本身可為資料庫環境提供許多功能、即使沒有任何特定的架構工作也沒問題。最重要的是、當目前的硬體達到使用壽命時、它能夠不中斷地移轉至新的硬體。一般而言、移轉至 ONTAP 是您最後需要執行的移轉作業。隨後的硬體即會就地升級、資料也不會中斷營運地移轉至新媒體。

有了一些規劃、就能獲得更多效益。使用快照時最重要的考量事項。快照是執行近乎即時的備份、還原及複製作業的基礎。作為快照功能的範例、已知最大的用途是在 6 個控制器上的約 250 個 LUN 上執行單一資料庫 996TB 。此資料庫可在 2 分鐘內備份、 2 分鐘內還原、 15 分鐘內複製完成。其他優點包括：能夠在叢集內移動資料、以因應工作負載的變化、以及應用服務品質（ QoS ）控制來在多資料庫環境中提供良好且一致的效能。

QoS 控制、資料重新配置、快照和複製等技術幾乎可在任何組態中運作。不過、一般需要考慮一些方法才能最大化效益。在某些情況下、資料庫儲存配置可能需要變更設計、以最大化對新儲存陣列的投資。這類設計變更可能會影響移轉策略、因為主機型或儲存型移轉會複寫原始資料配置。完成移轉並提供針對 ONTAP 最佳化的資料配置、可能需要其他步驟。中所示的程序 "Oracle 移轉程序概述" 稍後、我們將示範一些方法、讓您不只是移轉資料庫、還能以最少的心力將資料庫移轉至最佳的最終配置。

應決定轉換期間允許的服務中斷上限。假設整個移轉程序會造成中斷、這是常見的錯誤。許多工作都可以在服務中斷開始之前完成、許多選項都能在不中斷或中斷的情況下完成移轉。即使無法避免中斷、您仍必須定義允許的服務中斷上限、因為轉換時間的持續時間因程序而異。

例如、複製 10TB 資料庫通常需要大約七小時才能完成。如果企業需要中斷七小時、檔案複製是輕鬆安全的移轉選項。如果五小時不可接受、則只需簡單的記錄傳送程序（請參閱 "Oracle 記錄傳送"）只需最少的努力就能設定、將轉換時間縮短至約 15 分鐘。在此期間、資料庫管理員可以完成此程序。如果 15 分鐘是不可接受的、則可透過指令碼將最後的轉換程序自動化、將轉換時間縮短至幾分鐘。您可以隨時加快移轉速度、但這樣做的代價是時間和精力。轉換時間目標應以企業可接受的內容為基礎。

沒有移轉作業完全沒有風險。即使技術運作正常、使用者也永遠可能發生錯誤。與所選移轉路徑相關的風險、必須與移轉失敗的後果一併考量。例如、 Oracle ASM 的透明線上儲存移轉功能是其重要功能之一、這是最可靠的方法之一。然而、資料正以這種方法進行無法扭轉的複製。在 ASM 發生問題的極不可能發生的事件中、沒有簡單的回傳路徑。唯一的選項是還原原始環境、或使用 ASM 將移轉回復至原始 LUN 。如果系統能夠執行此類作業、則可在原始儲存系統上執行快照類型備份、將風險降至最低、但不會消除。

某些移轉程序必須在執行前經過完整驗證。移轉和排練轉換程序是關鍵任務資料庫的常見要求、移轉必須成功、停機時間必須降至最低。此外、使用者驗收測試通常是移轉後工作的一部分、只有在完成這些測試之後、才能將整個系統恢復正常運作。

如果需要排練、有幾項 ONTAP 功能可以讓流程更輕鬆。特別是、快照可以重設測試環境、並快速建立資料庫環境的多個具空間效益的複本。