背景、起點(diǎn)和目標(biāo)

聯(lián)合可口可樂瓶裝公司(Coca-Cola Bottling Co. Consolidated , CCBCC) 生產(chǎn)并銷售飲料，大部分是可口可樂公司( Coca-Cola Company)的產(chǎn)品。CCBCC是美國第二大可口可樂產(chǎn)品瓶裝廠，營運(yùn)點(diǎn)集中在東南部七個州。創(chuàng)立于 1902 年，總部設(shè)在北卡羅來納州夏洛特市，營業(yè)收入凈額高達(dá) 14 億美元以上。

善用綜效：SAP Unicode 轉(zhuǎn)換和 DB2 遷移
在進(jìn)行 SAP 環(huán)境的技術(shù)升級之前， CCBCC 決定執(zhí)行 Unicode 轉(zhuǎn)換，并從現(xiàn)有 Oracle 數(shù)據(jù)庫平臺遷移到具備Deep Compression（深度壓縮）功能的 IBM DB2。由于此策略不需要購買新的 Oracle 許可證，所以可降低總擁有成本 (TCO)。

遷移期間，使用 DB2 Deep Compression 功能，公司可降低 40% 以上的數(shù)據(jù)庫容量，還可縮短后續(xù) SAP 軟體升級的備份時間和執(zhí)行時間。

同時，在 SAP 升級之前，CCBCC 能夠從高度自動化的 DB2 數(shù)據(jù)庫管理中受益，從而降低運(yùn)營成本。DB2 9 版的功能包括自行管理存儲器、自動化的內(nèi)存管理 (STMM)、自動重組、自動化的運(yùn)行啟動，以及通過集成的FlashCopy 功能進(jìn)行實(shí)時的統(tǒng)計和備份。

所有的數(shù)據(jù)庫管理和監(jiān)控任務(wù)都可以通過 SAP Database Administrator (DBA) Cockpit for DB2 完成。此簡單易用的管理環(huán)境已經(jīng)被集成到了 SAP 應(yīng)用環(huán)境中。

部署 Unicode 是保障未來運(yùn)作的解決方案
CCBCC 之所以要部署 Unicode，是因?yàn)橐院笏行碌?SAP 產(chǎn)品版本（從 SAP NetWeaver 7.0 開始）都會以 Unicode 為標(biāo)準(zhǔn)。CCBCC希望能夠?yàn)?SAP NetWeaver Process Integration (SAP NW PI) 等新的 SAP 應(yīng)用做準(zhǔn)備，因?yàn)檫@些新 SAP 應(yīng)用已是未來實(shí)施計劃中的一部分。

以技術(shù)觀點(diǎn)而言，Unicode 轉(zhuǎn)換與數(shù)據(jù)庫遷移非常相似。因?yàn)樵谶@兩種情況下，客戶都必須使用 SAP 程序 R3load 來導(dǎo)入和導(dǎo)出數(shù)據(jù)庫。

Unicode 轉(zhuǎn)換是在遷移計劃的導(dǎo)出階段執(zhí)行的。因此，無需宕機(jī)，就可以將數(shù)據(jù)庫輕松地導(dǎo)入到一個新的目標(biāo)系統(tǒng)。遷移到 IBM DB2與 SAP 軟件升級和/或Unicode 轉(zhuǎn)換的好處是，不僅可以避免執(zhí)行重復(fù)的項(xiàng)目（如備份及測試），還可以有效地控制遷移成本。

遷移流程：異構(gòu)系統(tǒng)復(fù)制
CCBCC 使用標(biāo)準(zhǔn)的 SAP 方法來實(shí)施遷移，此方法又稱為“異構(gòu)系統(tǒng)復(fù)制”（或“OS/DB 遷移）方法。CCBCC可在事先安排好的維護(hù)窗口中執(zhí)行遷移和轉(zhuǎn)換，而無需利用新改進(jìn)的 SAP 遷移工具或服務(wù)，如 Zero Downtime。

整個 SAP R/3 Enterprise 環(huán)境遷移項(xiàng)目的完成共用了8周，其中包括 1TB 生產(chǎn)數(shù)據(jù)庫的兩次迭代測試。SAP 自身系統(tǒng)的遷移只需一個周末的時間（從周六晚上開始到周一凌晨）就可以完成。在整個遷移過程中，僅需宕機(jī) 26 小時。

為了縮短宕機(jī)時間，該公司使用了一系列 SAP 專用遷移工具：
1. Unsorted Export ，適用于透明表格

2. Package Splitter，適用于***表格（“大表格“組）

3. Table Splitter，適用于三大群集表格

4. Migration Monitor，可以對多個實(shí)例執(zhí)行分布式并行導(dǎo)入和導(dǎo)出流程

5. R3load，它具有 Deep Compression 功能，在遷移階段可以對數(shù)據(jù)庫進(jìn)行壓縮。

本文下面部分將說明CCBCC使用這些工具的方式、選擇這些工具的原因，以及重點(diǎn)說明其好處。

架構(gòu)概述：CCBCC 的遷移方案
CCBCC 將 IBM Power Systems 服務(wù)器（型號 p5-560）分成四個邏輯分區(qū) (LPAR) 進(jìn)行遷移。三個 LPAR 用于負(fù)責(zé)從源系統(tǒng)導(dǎo)出數(shù)據(jù)庫，一個 LPAR 負(fù)責(zé)將數(shù)據(jù)庫導(dǎo)入目標(biāo)系統(tǒng)。導(dǎo)出分區(qū)是由 Central Instance / Database 分區(qū)及其他兩個分區(qū)組成的；Central Instance / Database (CI/DB) 有 16個 1.50GHz 的 CPU 和 64GB 的內(nèi)存，其他兩個分區(qū)各自擁有 4 個 1.50GHz 的 CPU和 12GB 的內(nèi)存。導(dǎo)入分區(qū)（或新的 CI/DB 分區(qū)）有 16 個 1.50GHz 的 CPU 和 64GB 內(nèi)存。

測試期間，將系統(tǒng)設(shè)定為處理遷移工作負(fù)荷的***遷移環(huán)境。

為了達(dá)到目標(biāo)的宕機(jī)時間，導(dǎo)出包的工作負(fù)荷分布在CI/DB 服務(wù)器及其他兩個服務(wù)器（主機(jī) A 和 B），這三個服務(wù)器運(yùn)行在前三個 LPAR 中。CI/DB 服務(wù)器通過 Table Splitter 處理 3 大群集表格。主機(jī) A 處理較小的表格。主機(jī) B 處理“大表格”組（包含 >1 千萬、>2百萬及 >20萬的記錄）；這些數(shù)據(jù)會通過 Package Splitter 分成較小的壓縮包。這三個主機(jī)都使用本地存儲器，將數(shù)據(jù)導(dǎo)出到磁盤上。各個導(dǎo)出流程都由 Migration Monitor (MigMon) 實(shí)例進(jìn)行控管。

導(dǎo)入端只有一個服務(wù)器：主機(jī) C（新的 CI/DB 服務(wù)器）。CI/DB、主機(jī) A 和主機(jī) B 的導(dǎo)出磁盤是通過主機(jī) C 上的 NFS（用于讀）安裝的。導(dǎo)入作業(yè)由多個 MigMon 實(shí)例控管。

然后，使用“sorted unload”選項(xiàng)，從主機(jī) B 上的“大表格”組中導(dǎo)出子集，此功能的完成需要額外的 CPU 資源。因此，導(dǎo)出階段要指定一個額外的服務(wù)器。在導(dǎo)入階段，載入程序期間會壓縮“大表格”組中的表格。

數(shù)據(jù)庫導(dǎo)出 – 使用的遷移工具

Unsorted vs. sorted export
CCBCC 卸載 Oracle 數(shù)據(jù)庫中的數(shù)據(jù)采用了“Sorted export”和“Unsorted export”的導(dǎo)出方式。Unsorted Export通常比Sorted Export快。但由于CCBCC也要執(zhí)行 Unicode 轉(zhuǎn)換，遷移團(tuán)隊(duì)只好采用“Sorted Export”方式導(dǎo)出 SAP 群集表格（如 CDCLS、RFGLG、EDI40）及 SAP 存儲庫表格類。對數(shù)據(jù)進(jìn)行排序需要額外的 CPU 功耗，因此，在數(shù)據(jù)導(dǎo)出階段，CCBCC使用了三個服務(wù)器。

1. Sorted Export：Pool Table、Cluster Table、報表、Dynpro 及 Nametabs。
2. Unsorted Export：大部分透明表格

若使用“Sorted Export”方式，就會按照主鍵的順序來讀取表格頁面。如果群集比例不佳，則不會持續(xù)讀取數(shù)據(jù)頁面。此外，數(shù)據(jù)庫排序作業(yè)可能會延長執(zhí)行時間。

如使用“Unsorted Export”方式，會順序讀取數(shù)據(jù)，然后直接寫入文件，而無需對數(shù)據(jù)進(jìn)行排序。

群集表格的 Unicode 轉(zhuǎn)換注意事項(xiàng)
執(zhí)行 Unicode 轉(zhuǎn)換后，記錄的內(nèi)容及長度可能有所改變。即使是邏輯記錄，它的物理記錄數(shù)目也可能會不同。因?yàn)檫壿嬘涗浭怯晌锢碛涗浗M成的，必須以排序方式讀取數(shù)據(jù)，才能找到屬于該邏輯記錄的所有物理記錄。因此，無法使用未排序的卸載（Unsorted unload）方式。

數(shù)據(jù)庫限制
DB2 支持“Unsorted Export”，但有些數(shù)據(jù)庫只支持“Sorted Export”。換言之，這些數(shù)據(jù)庫在進(jìn)行遷移時會面臨重大挑戰(zhàn)，而且會限制日常運(yùn)作。例如，使用“Sorted Export”方式設(shè)定測試及 QA 系統(tǒng)會比較困難，尤其是龐大的數(shù)據(jù)庫。若被迫執(zhí)行“Sorted Export”，就會大大延長宕機(jī)時間，而且?guī)缀醪豢赡芨臄?shù)據(jù)庫，甚至無法在合理時間內(nèi)完成 Unicode 轉(zhuǎn)換。

套件及表格分割
在過去，將近 1TB 的數(shù)據(jù)庫大小及超大表格曾是導(dǎo)致服務(wù)中斷的主因。因此，CCBCC決定使用 Package Splitter 和 Table Splitter，并行導(dǎo)出數(shù)據(jù)庫，以提高整個遷移流程的速度。

Package Splitter 可將來源數(shù)據(jù)庫表格分割成一個個的套件，然后導(dǎo)出。每個套件都由專用 R3load 程序進(jìn)行處理。這些程序可同時進(jìn)行，因此能夠有效利用 CPU 資源。Table Splitter R3ta 可針對表格產(chǎn)生多個 WHERE 條件，通過多個同時執(zhí)行的 R3load 程序?qū)С霰砀駭?shù)據(jù)。各個 R3load 程序需要設(shè)置 WHERE 條件，來選擇表格中的數(shù)據(jù)子集。

1. 262 個大型表格（“大表格”群組）是通過 Package Splitter 對自己進(jìn)行打包，以提高其并行處理能力及確保套件的精度，在遷移過程中有效利用資源。

2. 12 個超大表格是使用 Table Splitter 分割成多個套件，以便多個 R3load 程序進(jìn)行表格的并行導(dǎo)出及導(dǎo)入。

3. 其他表格則使用 Package Splitter 納入聯(lián)合套件。將內(nèi)容分割成多個 R3load 程序（20 并行程序）之后，即可并行導(dǎo)出及導(dǎo)入資料，節(jié)省許多時間。

Migration Monitor (MigMon)
在 Unicode 轉(zhuǎn)換階段中，系統(tǒng)復(fù)制會在導(dǎo)出時產(chǎn)生龐大的 CPU 負(fù)載。多數(shù) CPU 資源會被用于轉(zhuǎn)換資料，尤其是處理群集表格時。

為了避免 CPU 瓶項(xiàng)，CCBCC 將導(dǎo)出和導(dǎo)入作業(yè)分散到 4 個 LPAR 上，以便有效地并行處理這些程序。如此一來，CCBCC 便能利用額外的處理器資源來處理數(shù)據(jù)庫的導(dǎo)入/導(dǎo)出作業(yè)。Migration Monitor 在系統(tǒng)復(fù)制期間協(xié)助執(zhí)行及控管卸載和載入程序，同時讓 20 個導(dǎo)出和導(dǎo)入程序得以同時執(zhí)行。

數(shù)據(jù)庫導(dǎo)入：使用 DB2 Deep Compression 功能

DB2 9 的存儲優(yōu)化功能
DB2 9 存儲優(yōu)化功能又稱為Deep Compression，可使用類似于字典的方式，使用短符號 (short symbol) 取代重復(fù)的型樣。字典會儲存最常出現(xiàn)的型樣，以相關(guān)符號檢索這些型樣，然后取代之。由于會取代表格中的所有型樣（不只是單頁的型樣），所以可達(dá)到可觀的壓縮率（每個表格高達(dá) 90%）。

R3load 具備 DB2 Deep Compression 功能：
CCBCC 希望利用 DB2 存儲優(yōu)化功能，所以決定在遷移過程中使用 Deep Compression。盡管知道 R3load 6.40 版的壓縮率并不是***的，但 CCBCC 還是決定這么做，因?yàn)檫@能達(dá)到 40% 的壓縮率，并且有效的提高性能（雖然只壓縮了 169 個較大表格）。

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

此功能可提供***數(shù)據(jù)壓縮，而且不需要耗時進(jìn)行表格重新整理。CCBCC使用的版本是 R3load 6.40 版，所以本文著重介紹其壓縮功能。

R3load 6.40 具有壓縮功能
為了生成壓縮字典，R3load 首先將已經(jīng)定義好的行載入表格，但不進(jìn)行壓縮。通過離線重新整理，R3load 基于這些行創(chuàng)建壓縮字典。

CCBCC 定義了環(huán)境變量 DB6LOAD_COMPRESSION_THRESHOLD 的值，此變量定義了最初載入的用于創(chuàng)建字典的行數(shù)。此臨界值默認(rèn)為 10,000 條記錄，但此值對較大的表格壓縮示例來說太低。

通過提取 10% - 80% 的記錄作為樣本（根據(jù)表格行數(shù)而定），CCBCC 能夠設(shè)置***臨界值，并達(dá)到非常理想的壓縮效果。***的兩個表格（COEP、BSIS）超過了 1億 3千萬條記錄，還有幾個表格的記錄數(shù)在 1千萬至 7千萬之間。

CCBCC 使用下列行數(shù)臨界值來為可壓縮的透明表格分組：
1. 記錄條數(shù)超過 3百萬的 20個表格一組；臨界值 = 3百萬

2. 記錄條數(shù)超過 200,000 的 47個表格一組；臨界值 = 200,000

3. 記錄條數(shù)超過 60,000 的 102個表格一組；臨界值 = 60,000

請注意，并不是所有符合臨界值的表格都會被附上壓縮標(biāo)志并被分到某個組。只有那些在測試階段壓縮效果表現(xiàn)良好的表格才會被選取。

初步導(dǎo)入并創(chuàng)建字典之后，R3load 會將剩余的行導(dǎo)入表格，DB2 根據(jù)字典來壓縮數(shù)據(jù)。

若要在載入階段進(jìn)行壓縮，該表格必須設(shè)置壓縮屬性設(shè)置。CCBCC 的某些表格需要壓縮，某些不需要，所以對于 Migration Monitor ，要使用不同的模板文件。

CCBCC通過多個 Migration Monitor 實(shí)例執(zhí)行導(dǎo)入，而對于各個實(shí)例，DB6LOAD_COMPRESSION_THRESHOLD 使用不同的值。

總結(jié)
CCBCC 已經(jīng)從 Unicode 升級和數(shù)據(jù)庫遷移中受益，具體表現(xiàn)在該公司在整個移轉(zhuǎn)過程中充分利用合成效果，消除了備份和測試等重復(fù)程序。從開始到完成，整個 ERP遷移項(xiàng)目只用了8周，包括 Unicode 轉(zhuǎn)換。

還有一點(diǎn)很重要，從 Oracle 到 DB2 ，數(shù)據(jù)庫管理技術(shù)的轉(zhuǎn)換很簡單，因?yàn)?DB2 很友好，易于使用。CCBCC 的數(shù)據(jù)庫管理員具有很強(qiáng)的 Oracle 技能，他們只需花費(fèi)幾周的時間就可以就可以充分掌握 DB2 的技術(shù)。這說明對于經(jīng)驗(yàn)豐富的 DBA 來說，不管其以前掌握的是什么技術(shù)，轉(zhuǎn)到 DB2 都十分輕松。

CCBCC 可馬上從 DB2中受益：
1. 較低的 TCO
2. 資料庫大小降低了 40%
3. 提高了性能：制造縮短了 65% 以上
4. 將數(shù)據(jù)庫更好地集成到了 SAP 工具中（SAP DBA cockpit for DB2）
5. 降低 DBA 管理DB2 的工作量

正確地使用 DB2 為CCBCC 即將升級到 SAP ERP 6.0 做了很好的準(zhǔn)備。SAP 目前的執(zhí)行比以前更加順暢，更加快速。因?yàn)閿?shù)據(jù)庫的大小減少了 40% ，所以SAP 軟件升級的備份及運(yùn)行時期也會跟著縮短。