背景、起点和目标
联合可口可乐瓶装公司(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 软件升级的备份及运行时期也会跟着缩短。
