背景、起点和目标
联合可口可乐瓶装公司(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 个导出和导入程序得以同时执行。
