檢查大型資料庫移轉最佳做法

  • 11 分鐘

下列指導方針是以實際客戶專案和衍生自這些專案的學習為基礎。 指導方針會識別過去失敗的案例。 例如，建議不要使用 UNIX 伺服器或虛擬化伺服器做為 R3load 匯出伺服器：

  • 通常，匯出效能是整體停機時間的一個管制因素。 目前的硬體通常超過 4-5 年，而且升級成本過高。
  • 因此，請務必取得實際達到的最大匯出效能。
  • 先前的專案在放棄和使用 Intel R3load 伺服器之前，花費了數週或甚至數月的工作時數嘗試微調 UNIX 或虛擬化平台上的 R3load 匯出效能。
  • 雙重通訊端商用 Intel 伺服器的成本較低，可提升實質效能，在某些情況下，數量級大於 UNIX 或虛擬化伺服器上可能的次要微調改善。
  • 客戶通常會有現有的 VM 伺服器陣列，但這些伺服器陣列經常不支援新式卸載或 SR-IOV 技術。 VMware 版本通常是舊版、未修補或未設定為高網路輸送量和低延遲。 R3load 匯出伺服器需要非常快速的執行緒效能和極高的網路輸送量。 R3load 匯出伺服器可能會在接近 100% 的 CPU 和網路使用率執行 10-15 小時。 這不是大部分 VMware 伺服器陣列的一般使用案例，而且大部分的 VMware 部署從未設計用來處理 R3load 之類的工作負載。

提示

請勿將時間投資在將 UNIX 或虛擬化平台上的 R3load 匯出效能進行最佳化。 這麼做不僅浪費時間，也會比在專案開始時購買低成本的 Intel 伺服器還要昂貴許多。 因此會要求 VLDB 移轉客戶，以確保專案小組在專案開始時，提供快速的新式 R3load 匯出伺服器。 這會降低專案的總成本和風險。

最佳作法

  • 調查和清查目前的 SAP 環境。 識別 SAP 支援套件層級，並判斷是否需要修補以支援目標 DBMS。 一般而言，作業系統相容性是由 SAP 核心所決定，而 DBMS 相容性是由 SAP_BASIS 修補程式層級所決定。
  • 建置需要在來源系統中套用的 SAP OSS 附註清單，例如 SMIGR_CREATE_DDL 的更新。 請考慮升級來源系統中的 SAP 核心，以避免在移轉至 Azure 期間發生大型變更 (例如，如果系統執行舊的 7.41 核心，請更新至來源系統上最新的 7.45，以避免在移轉期間發生大型變更)。
  • 開發及記錄高可用性和災害復原解決方案。 文件應該將解決方案分成資料庫層、ASCS 層和 SAP 應用伺服器層。 獨立解決方案 (例如 TREX 或 liveCache) 可能需要個別的解決方案。
  • 開發調整大小和設定文件，以詳細說明 Azure VM 類型和儲存體設定。 進階磁碟數量、資料檔案數量、資料檔案分散到磁碟的方式、儲存空間使用量、NTFS 格式大小 = 64 kb。 此外，文件備份/還原和 DBMS 設定，例如記憶體設定、平行處理原則的最大程度和追蹤旗標。
  • 開發網路設計文件，包括 VNet、子網路、NSG 和 UDR 設定。
  • 記錄並實作安全性和強化概念。 移除 Internet Explorer、為 SAP 服務帳戶和伺服器建立 Active Directory 容器，並套用防火牆原則來封鎖所有必要連接埠，但必要連接埠的數目有所限制。
  • 建立 OS/DB 移轉設計文件，詳細說明套件和資料表分割概念、R3loads 數目、SQL Server 追蹤旗標、排序/未排序、Oracle RowID 設定、SMIGR_CREATE_DDL 設定、Perfmon 計數器 (例如 BCP 資料列/秒和 BCP 輸送量 kb/秒、CPU、記憶體)、RSS 設定、加速網路設定、記錄檔設定、BPE 設定、TDE 設定。
  • 建立顯示每個測試週期 R3load 匯出/匯入進度的「正式發行前小眾測試版計劃」圖表。 這可讓移轉小組驗證微調和變更是否可改善 R3load 匯出或匯入效能。 X 軸是完成的套件數目，而 Y 軸是已耗用時間。 在生產環境移轉期間，此正式發行前小眾測試版計劃也很重要，因此計劃進度可以與早期識別的實際進度和任何問題進行比較。
  • 建立效能測試計劃。 識別前 20 名線上報告、批次作業和介面。 記錄原始來源系統上的輸入參數 (例如日期範圍、銷售辦公室、工廠、公司代碼等) 和執行階段。 與 Azure 上的執行階段比較。 如果有效能差異，請執行 SAT、ST05 和其他 SAP 工具來識別沒有效率的陳述式。
  • 稽核部署和設定，並確保叢集逾時、核心、網路設定、NTFS 格式大小都與設計文件一致。 在重要的伺服器上設定 perfmon 計數器，每隔 90 秒記錄基本健康情況參數。 確認 SAP 伺服器位於個別的 AD 容器中，且容器已套用具有防火牆設定的群組原則。
  • 請檢查潛在客戶 OS/DB 移轉顧問是否獲得授權！ 要求顧問名稱、s-user 和認證日期。 對 BC-INS-MIG 開啟 OSS 訊息，並要求 SAP 確認顧問為最新狀態且獲得授權。
  • 可能的話，請讓整個專案小組與一個實體位置內的 VLDB 移轉專案建立關聯，而非分散於數個大陸和時區。
  • 請確定已備妥適當的後援計畫，而且其為整體排程的一部分。
  • 選取 R3load 匯出伺服器的快速執行緒計數 Intel CPU 模型。 請勿使用「省電」CPU 模型，因為其效能低，且不會使用 4 通訊端伺服器。 Intel Xeon E5 Platinum 8158 是不錯的範例。

避免問題的最佳做法

  • 請勿轉包一個諮詢組織來執行匯出，並轉包另一個諮詢組織來執行匯入。 來源系統偶爾會由一個諮詢組織或合作夥伴進行外包及管理，而客戶想要遷移至 Azure 並切換到另一個合作夥伴。 由於匯出與匯入微調和設定之間的緊密結合，因此將這些工作指派給不同的組織不太可能會產生良好的結果。
  • 在移轉和上線期間，請勿在 Azure 硬體資源上節約。 Azure VM 會按分鐘計費，而且可以輕鬆地縮小大小。 在 VLDB 移轉期間，請使用可使用的最強大 VM。 客戶已成功在 200-250% 的過大系統上上線，然後在執行過大的系統時保持穩定。 監視系統使用率 4-6 週之後，容量過剩的 VM 會減少大小或關機來降低成本。