背景、起點和目標
聯合可口可樂瓶裝公司(Coca-Cola Bottling Co. Consolidated , CCBCC) 生產並銷售飲料，大部分是可口可樂公司( Coca-Cola Company)的產品。CCBCC是美國第二大可口可樂產品瓶裝廠，營運點集中在東南部七個州。創立於 1902 年，總部設在北卡羅來納州夏洛特市，營業收入淨額高達 14 億美元以上。
善用綜效：SAP Unicode 轉換和 DB2 遷移
在進行 SAP 環境的技術升級之前， CCBCC 決定執行 Unicode 轉換，並從現有 Oracle 數據庫平台遷移到具備Deep Compression深度壓縮）功能的 IBM DB2。由於此策略不需要購買新的 Oracle 許可證，所以可降低總擁有成本 (TCO)。
遷移期間，使用 DB2 Deep Compression 功能，公司可降低 40% 以上的數據庫容量，還可縮短後續 SAP 軟體升級的備份時間和執行時間。
同時，在 SAP 升級之前，CCBCC 能夠從高度自動化的 DB2 數據庫管理中受益，從而降低運營成本。DB2 9 版的功能包括自行管理存儲器、自動化的內存管理 (STMM)、自動重組、自動化的運行啟動，以及通過集成的FlashCopy 功能進行實時的統計和備份。
所有的數據庫管理和監控任務都可以通過 SAP Database Administrator (DBA) Cockpit for DB2 完成。此簡單易用的管理環境已經被集成到了 SAP 應用環境中。
部署 Unicode 是保障未來運作的解決方案
CCBCC 之所以要部署 Unicode，是因為以後所有新的 SAP 產品版本從 SAP NetWeaver 7.0 開始）都會以 Unicode 為標准。CCBCC希望能夠為 SAP NetWeaver Process Integration (SAP NW PI) 等新的 SAP 應用做准備，因為這些新 SAP 應用已是未來實施計劃中的一部分。
以技術觀點而言，Unicode 轉換與數據庫遷移非常相似。因為在這兩種情況下，客戶都必須使用 SAP 程序 R3load 來導入和導出數據庫。
Unicode 轉換是在遷移計劃的導出階段執行的。因此，無需宕機，就可以將數據庫輕松地導入到一個新的目標系統。遷移到 IBM DB2與 SAP 軟件升級和/或Unicode 轉換的好處是，不僅可以避免執行重復的項目如備份及測試），還可以有效地控制遷移成本。
遷移流程：異構系統復制
CCBCC 使用標准的 SAP 方法來實施遷移，此方法又稱為“異構系統復制”或“OS/DB 遷移）方法。CCBCC可在事先安排好的維護窗口中執行遷移和轉換，而無需利用新改進的 SAP 遷移工具或服務，如 Zero Downtime。
整個 SAP R/3 Enterprise 環境遷移項目的完成共用了8周，其中包括 1TB 生產數據庫的兩次迭代測試。SAP 自身系統的遷移只需一個周末的時間從周六晚上開始到周一凌晨）就可以完成。在整個遷移過程中，僅需宕機 26 小時。
為了縮短宕機時間，該公司使用了一系列 SAP 專用遷移工具：
1. Unsorted Export ，適用於透明表格
2. Package Splitter，適用於最大表格“大表格“組）
3. Table Splitter，適用於三大群集表格
4. Migration Monitor，可以對多個實例執行分布式並行導入和導出流程
5. R3load，它具有 Deep Compression 功能，在遷移階段可以對數據庫進行壓縮。
本文下面部分將說明CCBCC使用這些工具的方式、選擇這些工具的原因，以及重點說明其好處。
架構概述：CCBCC 的遷移方案
CCBCC 將 IBM Power Systems 服務器型號 p5-560）分成四個邏輯分區 (LPAR) 進行遷移。三個 LPAR 用於負責從源系統導出數據庫，一個 LPAR 負責將數據庫導入目標系統。導出分區是由 Central Instance / Database 分區及其他兩個分區組成的；Central Instance / Database (CI/DB) 有 16個 1.50GHz 的 CPU 和 64GB 的內存，其他兩個分區各自擁有 4 個 1.50GHz 的 CPU和 12GB 的內存。導入分區或新的 CI/DB 分區）有 16 個 1.50GHz 的 CPU 和 64GB 內存。
測試期間，將系統設定為處理遷移工作負荷的最佳遷移環境。
為了達到目標的宕機時間，導出包的工作負荷分布在CI/DB 服務器及其他兩個服務器主機 A 和 B），這三個服務器運行在前三個 LPAR 中。CI/DB 服務器通過 Table Splitter 處理 3 大群集表格。主機 A 處理較小的表格。主機 B 處理“大表格”組包含 >1 千萬、>2百萬及 >20萬的記錄）；這些數據會通過 Package Splitter 分成較小的壓縮包。這三個主機都使用本地存儲器，將數據導出到磁盤上。各個導出流程都由 Migration Monitor (MigMon) 實例進行控管。
導入端只有一個服務器：主機 C新的 CI/DB 服務器）。CI/DB、主機 A 和主機 B 的導出磁盤是通過主機 C 上的 NFS用於讀）安裝的。導入作業由多個 MigMon 實例控管。
然後，使用“sorted unload”選項，從主機 B 上的“大表格”組中導出子集，此功能的完成需要額外的 CPU 資源。因此，導出階段要指定一個額外的服務器。在導入階段，載入程序期間會壓縮“大表格”組中的表格。
數據庫導出 – 使用的遷移工具
Unsorted vs. sorted export
CCBCC 卸載 Oracle 數據庫中的數據采用了“Sorted export”和“Unsorted export”的導出方式。Unsorted Export通常比Sorted Export快。但由於CCBCC也要執行 Unicode 轉換，遷移團隊只好采用“Sorted Export”方式導出 SAP 群集表格如 CDCLS、RFGLG、EDI40）及 SAP 存儲庫表格類。對數據進行排序需要額外的 CPU 功耗，因此，在數據導出階段，CCBCC使用了三個服務器。
1. Sorted Export：Pool Table、Cluster Table、報表、Dynpro 及 Nametabs。
2. Unsorted Export：大部分透明表格
若使用“Sorted Export”方式，就會按照主鍵的順序來讀取表格頁面。如果群集比例不佳，則不會持續讀取數據頁面。此外，數據庫排序作業可能會延長執行時間。
如使用“Unsorted Export”方式，會順序讀取數據，然後直接寫入文件，而無需對數據進行排序。
群集表格的 Unicode 轉換注意事項
執行 Unicode 轉換後，記錄的內容及長度可能有所改變。即使是邏輯記錄，它的物理記錄數目也可能會不同。因為邏輯記錄是由物理記錄組成的，必須以排序方式讀取數據，才能找到屬於該邏輯記錄的所有物理記錄。因此，無法使用未排序的卸載Unsorted unload）方式。
數據庫限制
DB2 支持“Unsorted Export”，但有些數據庫只支持“Sorted Export”。換言之，這些數據庫在進行遷移時會面臨重大挑戰，而且會限制日常運作。例如，使用“Sorted Export”方式設定測試及 QA 系統會比較困難，尤其是龐大的數據庫。若被迫執行“Sorted Export”，就會大大延長宕機時間，而且幾乎不可能更改數據庫，甚至無法在合理時間內完成 Unicode 轉換。
套件及表格分割
在過去，將近 1TB 的數據庫大小及超大表格曾是導致服務中斷的主因。因此，CCBCC決定使用 Package Splitter 和 Table Splitter，並行導出數據庫，以提高整個遷移流程的速度。
Package Splitter 可將來源數據庫表格分割成一個個的套件，然後導出。每個套件都由專用 R3load 程序進行處理。這些程序可同時進行，因此能夠有效利用 CPU 資源。Table Splitter R3ta 可針對表格產生多個 WHERE 條件，通過多個同時執行的 R3load 程序導出表格數據。各個 R3load 程序需要設置 WHERE 條件，來選擇表格中的數據子集。
1. 262 個大型表格“大表格”群組）是通過 Package Splitter 對自己進行打包，以提高其並行處理能力及確保套件的精度，在遷移過程中有效利用資源。
2. 12 個超大表格是使用 Table Splitter 分割成多個套件，以便多個 R3load 程序進行表格的並行導出及導入。
3. 其他表格則使用 Package Splitter 納入聯合套件。將內容分割成多個 R3load 程序20 並行程序）之後，即可並行導出及導入資料，節省許多時間。
Migration Monitor (MigMon)
在 Unicode 轉換階段中，系統復制會在導出時產生龐大的 CPU 負載。多數 CPU 資源會被用於轉換資料，尤其是處理群集表格時。
為了避免 CPU 瓶項，CCBCC 將導出和導入作業分散到 4 個 LPAR 上，以便有效地並行處理這些程序。如此一來，CCBCC 便能利用額外的處理器資源來處理數據庫的導入/導出作業。Migration Monitor 在系統復制期間協助執行及控管卸載和載入程序，同時讓 20 個導出和導入程序得以同時執行。
數據庫導入：使用 DB2 Deep Compression 功能
DB2 9 的存儲優化功能
DB2 9 存儲優化功能又稱為Deep Compression，可使用類似於字典的方式，使用短符號 (short symbol) 取代重復的型樣。字典會儲存最常出現的型樣，以相關符號檢索這些型樣，然後取代之。由於會取代表格中的所有型樣不只是單頁的型樣），所以可達到可觀的壓縮率每個表格高達 90%）。
R3load 具備 DB2 Deep Compression 功能：
CCBCC 希望利用 DB2 存儲優化功能，所以決定在遷移過程中使用 Deep Compression。盡管知道 R3load 6.40 版的壓縮率並不是最好的，但 CCBCC 還是決定這麼做，因為這能達到 40% 的壓縮率，並且有效的提高性能雖然只壓縮了 169 個較大表格）。
若在資料庫遷移及/或 Unicode 轉換期間使用 DB2 Deep Compression功能，將可順利在載入資料庫時壓縮資料。R3load 工具可在資料載入表格時，提供多種部署 DB2 Deep Compression 的方法。不同的 R3load 版本即 6.40 版、7.00 或更新版）所提供的壓縮選項也不盡相同，如新版 R3load 7.00 的 SAMPLED 選項。
此功能可提供最佳數據壓縮，而且不需要耗時進行表格重新整理。CCBCC使用的版本是 R3load 6.40 版，所以本文著重介紹其壓縮功能。
R3load 6.40 具有壓縮功能
為了生成壓縮字典，R3load 首先將已經定義好的行載入表格，但不進行壓縮。通過離線重新整理，R3load 基於這些行創建壓縮字典。
CCBCC 定義了環境變量 DB6LOAD_COMPRESSION_THRESHOLD 的值，此變量定義了最初載入的用於創建字典的行數。此臨界值默認為 10,000 條記錄，但此值對較大的表格壓縮示例來說太低。
通過提取 10% - 80% 的記錄作為樣本根據表格行數而定），CCBCC 能夠設置最佳臨界值，並達到非常理想的壓縮效果。最大的兩個表格COEP、BSIS）超過了 1億 3千萬條記錄，還有幾個表格的記錄數在 1千萬至 7千萬之間。
CCBCC 使用下列行數臨界值來為可壓縮的透明表格分組：
1. 記錄條數超過 3百萬的 20個表格一組；臨界值 = 3百萬
2. 記錄條數超過 200,000 的 47個表格一組；臨界值 = 200,000
3. 記錄條數超過 60,000 的 102個表格一組；臨界值 = 60,000
請注意，並不是所有符合臨界值的表格都會被附上壓縮標志並被分到某個組。只有那些在測試階段壓縮效果表現良好的表格才會被選取。
初步導入並創建字典之後，R3load 會將剩余的行導入表格，DB2 根據字典來壓縮數據。
若要在載入階段進行壓縮，該表格必須設置壓縮屬性設置。CCBCC 的某些表格需要壓縮，某些不需要，所以對於 Migration Monitor ，要使用不同的模板文件。
CCBCC通過多個 Migration Monitor 實例執行導入，而對於各個實例，DB6LOAD_COMPRESSION_THRESHOLD 使用不同的值。
總結
CCBCC 已經從 Unicode 升級和數據庫遷移中受益，具體表現在該公司在整個移轉過程中充分利用合成效果，消除了備份和測試等重復程序。從開始到完成，整個 ERP遷移項目只用了8周，包括 Unicode 轉換。
還有一點很重要，從 Oracle 到 DB2 ，數據庫管理技術的轉換很簡單，因為 DB2 很友好，易於使用。CCBCC 的數據庫管理員具有很強的 Oracle 技能，他們只需花費幾周的時間就可以就可以充分掌握 DB2 的技術。這說明對於經驗豐富的 DBA 來說，不管其以前掌握的是什麼技術，轉到 DB2 都十分輕松。
CCBCC 可馬上從 DB2中受益：
1. 較低的 TCO
2. 資料庫大小降低了 40%
3. 提高了性能：制造縮短了 65% 以上
4. 將數據庫更好地集成到了 SAP 工具中SAP DBA cockpit for DB2）
5. 降低 DBA 管理DB2 的工作量
正確地使用 DB2 為CCBCC 即將升級到 SAP ERP 6.0 做了很好的准備。SAP 目前的執行比以前更加順暢，更加快速。因為數據庫的大小減少了 40% ，所以SAP 軟件升級的備份及運行時期也會跟著縮短。
