数据库导入：使用 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 软件升级的备份及运行时期也会跟着缩短。