可口可樂利用 SAP 技術升級專案，從 Oracle 移轉到 IBM DB2

背景、起點及目標
可口可樂製造、銷售及提供汽水和飲料，主要是 The Coca-Cola Company 的產品。可口可樂是美國第二大的可口可樂產品瓶裝廠，營運據點集中在東南部七個州。創立於 1902 年，總部設在北卡羅來納州夏洛特市，營業收入淨額高達 14 億美元以上。

善用綜效：SAP Unicode 轉換及 DB2 移轉
在進行 SAP 環境的技術升級之前，可口可樂決定執行 Unicode 轉換，並從現有 Oracle 資料庫平台移轉到具備 Deep Compression 功能的 IBM DB2。此策略不需要購買新的 Oracle 授權，因此可降低總擁有成本 (TCO)。

移轉期間啟動 DB2 Deep Compression 功能，公司可降低 40% 以上的資料庫容量，還可縮短後續 SAP 軟體升級的備份時間和執行時間。

同時，在升級 SAP 之前，可口可樂可受惠於高度自動化的 DB2 資料庫管理，進而降低作業成本。DB2 9 版的功能包括自行管理儲存、自行調整記憶體管理 (STMM)、自動重新整理、自動 Runstats、即時統計資料及透過整合型 FlashCopy® 功能執行的備份。

所有資料庫管理及監視作業都可以透過 SAP Database Administrator (DBA) Cockpit for DB2 完成。此簡單易用的管理環境已納入 SAP 應用程式環境。

部署 Unicode 是保障未來運作的解決方案
可口可樂之所以要部署 Unicode，是因為以後所有新的 SAP 產品版本（從 SAP NetWeaver 7.0 開始）都會以 Unicode 為標準。而這些新 SAP 應用程式已是未來實作計畫中的一部分，所以可口可樂希望為 SAP NetWeaver Process Integration (SAP NW PI) 等新的 SAP 應用程式做好準備。

以技術觀點而言，Unicode 轉換的需求很類似資料庫移轉。在這兩種情況下，客戶都必須使用 SAP 程式 R3load 來匯入及匯出資料庫。

Unicode 轉換是在移轉計畫的匯出階段執行。因此，很容易直接將資料庫導入新的目標系統，不需要另外執行及關機。移轉到 IBM DB2，並搭配 SAP 軟體升級和（或）Unicode 轉換的好處是，可避免重複的專案作業（如備份及測試），而且可控制移轉成本。

移轉程序：異質系統複製
可口可樂使用了標準 SAP 方法來進行移轉，此方法又稱為「異質系統複製」（或 OS/DB 移轉）。可口可樂可在排定的維護時間內執行移轉和轉換，所以不需要利用 SAP 的強化移轉工具或服務，如 Zero Downtime。

整個 SAP R/3 Enterprise 環境移轉專案總共花了八週，其中包括兩次 1TB 正式作業資料庫測試。SAP 正式作業系統則花了一個週末就完成移轉，從週六晚上開始到星期一凌晨。正式作業移轉的總關閉時間只有 26 小時。

為了縮短關閉時間，該公司使用了一組 SAP 專用移轉工具：

1. 用於透通表格的 Unsorted Export

2. 用於最大表格（「大表格」群組）的 Package Splitter

3. 用於三大叢集表格的 Table Splitter

4. Migration Monitor 的多個實例，以便進行分散式平行匯入及匯出程序

5. 具備 Deep Compression 選項的 R3load，以便在移轉階段啟動壓縮。

本文下一節將說明可口可樂使用這些工具的方式、選擇這些工具的原因，以及重點說明其好處。

架構概觀：可口可樂的移轉專案
可口可樂將 IBM Power Systems 伺服器（型號 p5-560）分成四個邏輯分割區 (LPAR) 進行移轉。三個 LPAR 用來處理來源系統的資料庫匯出程序，另一個 LPAR 則負責執行匯入程序的目標系統。匯出分割區是由 Central Instance / Database 分割區及其他兩個分割區所組成；Central Instance / Database (CI/DB) 有 16 個 1.5GHz 的 CPU 和 64GB 的記憶體，其他兩個分割區則有 4 個 1.5GHz 的 CPU、各包含 12GB 的記憶體。匯入分割區（或新的 CI/DB 分割區）有 16 個 1.5GHz 的 CPU 和 64GB 記憶體。

測試期間，此系統設定顯示，這是處理移轉工作量的最佳移轉環境。

為了達到目標關閉時間，在前三個 LPAR 中執行的 CI/DB 伺服器及其他兩個伺服器（主機 A 和 B）會分配匯出套件的工作量。CI/DB 伺服器透過 Table Splitter 處理 3 大叢集表格。主機 A 處理較小的表格。主機 B 則處理「大表格」群組（包含 >1 千萬、>2 千萬及 >200,000 筆記錄）的匯出作業；這些資料會以 Package Splitter 分成較小的套件。這三個主機都使用區域儲存體，將匯出資料傾出到磁碟。每個匯出程序皆由 Migration Monitor (MigMon) 實例本身的配置進行控管。

匯入端只有一個伺服器：主機 C（新的 CI/DB 伺服器）。CI/DB、主機 A 和主機 B 的匯出磁碟是透過主機 C 上的 NFS 裝載（以便讀取）。匯入作業則由多個 MigMon 實例控管。

然後，使用已排序的卸載選項從主機 B 上的「大表格」群組匯出子集，此功能需要額外的 CPU 資源，所以匯出階段要指定一個額外的伺服器。在匯入階段，載入程序期間會壓縮「大表格」群組的表格。

資料庫匯出－移轉作業所用的工具
未排序與排序匯出
可口可樂使用了排序與未排序的匯出方式，從 Oracle 資料庫卸載資料。未排序匯出通常比排序匯出快。但由於可口可樂也要執行 Unicode 轉換，移轉團隊只好透過排序匯出方式，匯出 SAP 叢集表格（如 CDCLS、RFGLG、EDI40）及 SAP 儲存庫資料類型。排序資料需要額外的 CPU 資源，所以可口可樂以三個伺服器處理匯出階段。

1. Sorted Export：Pool Table、Cluster Table、報表、Dynpro 及 Nametabs。

2. Unsorted Export：大部分透通表格

若使用排序匯出，就會以主要索引鍵的順序讀取表格頁面。如果叢集比例不佳，則不會持續讀取資料頁面。此外，可能會進行資料庫排序作業，導致匯出執行時間延長。使用未排序選項時，會按順序讀取資料，然後直接寫入檔案，而不是使用索引嘗試排序資料，再寫入檔案。

叢集表格的 Unicode 注意事項
執行 Unicode 轉換後，記錄的內容及長度可能有所改變。即使屬於邏輯記錄的實體記錄數目也可能會不同。因為邏輯記錄是由實體記錄共同組成的，必須以排序方式讀取資料，才能找到屬於該邏輯記錄的所有實體記錄。因此，無法進行未排序的卸載。

資料庫限制
DB2 支援未排序匯出，但有些資料庫只支援排序匯出。換言之，這些資料庫在進行移轉時會面臨重大障礙，而且會限制日常作業。例如，使用排序匯出來設定測試及 QA 系統會比較困難。尤其是龐大的資料庫，若被迫執行排序匯出，就會大幅延長關閉時間，而且幾乎不可能更換資料庫，甚至無法在合理時間內完成 Unicode 轉換。

套件及表格分割
在過去，將近 1TB 的資料庫大小及超大表格曾是導致服務中斷的主因。因此，可口可樂決定使用 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 瓶項，可口可樂將匯出及匯入作業分散到 4 個 LPAR 上，以便有效地平行處理這些程序。如此一來，可口可樂便能利用額外的處理器資源進行資料庫匯出/匯入。Migration Monitor 在系統複製期間協助執行及控管卸載和載入程序，同時讓 20 個匯出及匯入程序得以同時執行。

匯入資料庫：啟用 DB2 Deep Compression
DB2 9 的 Storage Optimization 功能
DB2 9 Storage Optimization 能功又稱為 Deep Compression，可透過以字典為基礎的方式，使用短符號 (short symbol) 取代重複的型樣。字典會儲存最常出現的型樣，以相關符號檢索這些型樣，然後取代之。由於會取代表格中的所有型樣（不只是單頁的型樣），即可達到可觀的壓縮率（每個表格高達 90%）。

具備 DB2 Deep Compression 功能的 R3load：
可口可樂希望利用 DB2 Storage Optimization 功能所提供的好處，所以決定在移轉過程中啟用 Deep Compression。儘管知道 R3load 6.40 版的壓縮率並不是最好的，但可口可樂還是決定這麼做，而且達到 40% 的壓縮率及卓越的效能提升 （雖然只壓縮了 169 個較大表格）。

若在資料庫移轉及（或） Unicode 轉換期間啟用 DB2 Deep Compression，將可順利在載入資料庫時壓縮資料。R3load 工具可在資料載入表格時，提供多種部署 DB2 Deep Compression 的方法。不同的 R3load 版本（即 6.40 版、7.00 或更新版）所提供的壓縮選項也不盡相同，如新版 R3load 7.00 的 SAMPLED 選項。

此功能可提供最佳資料壓縮，而且不需要耗時進行表格重新整理。可口可樂是使用 R3load 6.40 版，所以本文著重介紹其壓縮功能。

隨附壓縮選項的 R3load 6.40
為了產生壓縮字典，R3load 會先將指定列數載入表格，但不進行壓縮。R3load 會執行離線重新整理，根據這些資料列建立壓縮字典。

可口可樂增加了環境變數 DB6LOAD_COMPRESSION_THRESHOLD 的值，以定義最初載入並用來建立字典的列數。此臨界值的預設值為 10,000 筆記錄，但此值對較大型的表格壓縮取樣來說太低。

可口可樂以 10% 至 80% 的記錄為樣本（依表格中的列數而定），即可設定最佳臨界值，並達到非常理想的壓縮效果。最大的兩個表格（COEP、BSIS）有 1 億 3 千萬筆記錄以上，還有幾個表格的記錄筆數介於 1 千萬至 7 千萬之間。
可口可樂使用下列資料列計數臨界值，來分類可壓縮的透通表格：

1. 記錄筆數超過 3 百萬的 20 個表格一組；臨界值 = 3 百萬

2. 記錄筆數超過 200,000 的 47 個表格一組；臨界值 = 200,000

3. 記錄筆數超過 60,000 的 102 個表格一組；臨界值 = 60,000

請注意，並不是所有符合臨界值的表格都會標示要進行壓縮並加入群組。只有在測試階段顯示壓縮效果良好的表格才會被選取。

初步匯入及建立字典之後，R3load 會將其餘資料列匯入表格，DB2 則根據字典來壓縮資料。

若要在載入階段進行壓縮，該表格必須啟動壓縮屬性。可口可樂有一些表格要壓縮，但有一些不要，所以針對 Migration Monitor 使用不同的範本。

可口可樂透過多個 Migration Monitor 實例執行匯入，而每個實例的 DB6LOAD_COMPRESSION_THRESHOLD 亦使用不同的值。

摘要
對可口可樂而言，整合 Unicode 升級和資料庫移轉的作法已奏效，不僅讓該公司在整個移轉過程中發揮了綜效，也可避免備份及測試等重複程序。從開始到完成，整個 ERP 移轉專案只花了八週，包括 Unicode 轉換。

還有一點很重要，即從 Oracle 轉換到 DB2 的資料庫管理技術很簡單，DB2 也很容易使用。可口可樂內部擁有很強的 Oracle 技能，但資料庫管理員只要幾個星期就能充分掌握 DB2；這證明了不管其既有技術如何，對經驗豐富的 DBA 來說，轉到 DB2 十分輕鬆。
可口可樂可直接受惠於 DB2：

1. 較低的 TCO

2. 資料庫大小降低了 40%

3. 提高效能：製程縮短了 65% 以上

4. 將資料庫有效整合到 SAP 工具中（SAP DBA cockpit for DB2）

5. 降低 DBA 的 DB2 管理工作量

使用 DB2 後，可口可樂便可有效因應後續的 SAP ERP 6.0 升級作業。此工具目前的執行效能已較稍早順暢且快速。資料庫大小降低 40% 後，SAP 軟體升級的備份及執行時期也會跟著縮短。

我有興趣