数据复制中的字符集转换最佳实践

文档选项 未显示需要 JavaScript 的文档选项

级别： 中级

吴先荣, 软件工程师, IBM 中国软件开发中心
李越, 软件工程师, IBM 中国软件开发中心
曹锐鑫, 实习生, IBM 中国软件开发中心

2007 年 7 月 02 日

针对 IBM WebSphere Information Integrator 的 SQL 复制和 Q 复制，本文通过描述字符集转换的各种机制与原理，介绍了在实际的多语言商业环境下的数据复制所应注意的各种配置组合与技巧。

在本系列的 第 1 篇文章中，作者针对 IBM WebSphere Information Integrator 的 SQL 复制和 Q 复制，分析了字符集转换的各种机制与原理。在本文中，作者介绍了在实际的多语言商业环境下的数据复制所应注意的各种配置组合与技巧，同时为客户提供了最佳的代码页配置方案，使得客户能够在最短的时间中了解数据复制过程中的字符集转换机制并及时地将其运用到商业环境中从而达到在数据复制过程中对多语言环境的最佳透明访问。

通常，我们为了正确实现数据库对多种字符集的支持及字符集之间的代码页转换，必定会引入 Unicode 数据库，现在各大数据库厂商均提供了对 Unicode 的支持，DB2 在对 Unicode 支持这一方面表现的相当出众，因此在下面的代码页转换配置中，我们经常使用代码页 1208 的设置，这表示使用了 Unicode 字符集。对于需要提供 DBCS 支持的数据库，强烈推荐用户在创建数据库时设定 CODESET 为 UTF-8，从而创建 Unicode 数据库。

如果需要在数据复制系统中正确高效地实现代码页转换，那么除数据库的代码页参数之外，我们同时需要综合考虑操作系统 LOCALE，DB2CODEPAGE 注册变量，以及其他重要参数（例如 MQ 中队列管理器的 CCSID）的设置。

在本章中我们分别针对 SQL 复制及 Q 复制进行阐述：

注意：Unicode 字符集与其他 SBCS，DBCS 字符集之间转换的实现方式并非本文的讨论重点，如果需要更为详细的信息，请查阅其他相关资料。

SQL 复制中的代码页转换配置

源表 -> capture 程序 -> CD 表

图 1 展现了数据由源表到 CD 表的过程中，不同参数的配置对数据代码页转换的影响过程，并且在这一过程中的代码页转换同时与 capture 程序密切相关。

在这个过程中 DB2 INSTANCE 级别注册变量 DB2CODEPAGE 扮演了主要角色，因为 capture 程序会根据 DB2CODEPAGE 来决定源表的代码页。

在表 1 中我们罗列了影响代码页转换过程的所有参数，并选取了一组特定值来进行分析：

• 红色线条代表的配置：

  如果用户未设定 DB2CODEPAGE 实例级别注册变量的当前值，那么 DB2CODEPAGE 将采用由（操作系统）LOCALE 决定的默认值，因此当启动 capture 程序时，必将会看到一个由于从代码页 943 到 1208 转换而产生的警告。但实际上，这个场景中的源表与 CD 表位于同一个数据库上，他们实际的代码页均为 1208。换句话说，代码页为 1208 的数据被 capture 程序错误地判断为代码页 943 的数据。显然，这里由于用户不恰当的设置带来了不必要的代码页转换，不仅影响了SQL 复制的效率，而且造成了数据转换异常。

• 蓝色线条代表的配置：

  这里用户通过设定 DB2CODEPAGE 变量的当前值为 1208，从而能够保证源表，CD 表具有相同代码页的前提下，使 capture 程序对做出了正确的代码页判断。这样我们避免了不必要的代码页转换，从而显著提高了 SQL 复制的效率，并消除了由于代码页转换所带来的异常。

通过对上述两种配置方法的对比分析，我们知道，第 2 种代码页转换配置方案正是我们所需要的，这里的关键在于 DB2CODEPAGE 注册变量的设置。

CD 表 -> apply 程序 -> 目标表

图 2 展现了数据由 CD 表到目标表的过程中，不同参数的配置对数据代码页转换的影响过程，并且在这一过程中的代码页转换同时与 apply 程序密切相关。

从图 2 中我们可以知道：数据由 CD 表流向目标表的过处理的过程中，总共发生了两次代码页转换。第一次转换发生在 CD 表中的数据在被 apply 程序定的代码页。第二次转换发生在 apply 程序将数据应用到目标数据库的过程中，这里数据的代码页将由 DB2CODEPAGE 注册变量所设定的代码页转换为目标数据库的代码页。

在表 2 中我们罗列了影响代码页转换过程的所有参数，并选取了一组特定值来进行分析：

注意：出于性能考虑，通常我们会使 apply 控制数据库与目标数据库是同一个数据库。因此 apply 控制数据库与目标数据库具有相同的代码页：1208。

• 绿色线条代表的配置：

  这里用户并未对 DB2CODEPAGE 注册变量做任何设定，因此它将保持自己的默认值，在日文的 LOCALE 下，DB2CODEPAG = 943，因此当数据由 CD 表被 apply 程序接收并处理时，数据的代码页发生了 1208 到 943 的转换；之后当 apply 程序将处理后的数据应用到目标表的过程中，数据的代码页再一次发生转换，从 943 到 1208。因此，观察整个代码页转换过程，实际上进行了从 1208 到 943 再到 1208 的过程。显然，这里由于用户选择了默认设置带来了 2 次不必要的代码页转换，直接给 SQL 复制的工作效率带来了负面影响，同时增大了数据转换发生异常的可能性。

• 蓝色线条代表的配置：

  这是一种没有任何代码页转换发生的配置方案。用户通过设定 DB2CODEPAGE = 1208，使得 DB2CODEPAGE = 源数据库代码页= 目标数据库代码页，从而直接避免了 2 次代码页转换，显著提高了 SQL 复制的效率，并消除了由于代码页转换所带来的异常。

通过对上述两种配置方法的对比分析，我们知道，第二种代码页转换配置方案正是我们所需要的，这里的关键在于 DB2CODEPAGE 注册变量的设置。

回页首

Q 复制中的代码页转换配置

为了对代码页转换配置做出一个详细的分析，我们将对 Q 复制中最为关键的两次代码页转换分别进行阐述：

1. 事务信息由源端服务器通过发送队列发送到目标端服务器的接收队列这一过程中的代码页转换；
2. apply 程序由接收队列中获得事务信息并应用到目标端数据库的过程中的代码页转换。

发送队列（源队列管理器） -> 接收队列（目标队列管理器）

当不同的主机充当 Q 复制中的源与目标的时候，MQ 允许在不同的队列管理器之间进行相互兼容的代码页转换，这种转换发生在每一次信息由源队列管理器（SQM）经通道抵达目标队列管理器的过程中。

这里，由图 3 可知，首先用户必须保证源队列管理器与源数据库以及数据库实例（db2codepage）具有相同的代码页，否则 capture 程序很可能发生数据代码页的错误判断。同样是在 Ja_JP 的环境中，不同的配置带来明显不同的代码页转换效果。

在表 3 中我们罗列了影响代码页转换过程的所有参数，并选取了一组特定值来进行分析：

• 采用默认参数的配置：

  选择源数据库的代码页为 943（日文），这样由于源队列管理器与目标队列管理器的代码页并不相同，因此在代码页转换必将发生，这里数据将发生代码页 943 到 1208的转换。虽然这样的配置单从数据的正确性没有明显的问题，但是由于代码页转换的引入直接给 Q 复制系统的工作效率带来了负面影响，同时增大了数据转换发生异常的可能性。

• 采用修正参数的配置：

  选择源数据库为 Unicode 数据库，从图中我们可以看出，这样既满足了支持 DBCS 的要求，同时避免了源队列管理器与目标队列管理器之间由于 CCSID 不同（当然是兼容的）而带来的一次代码页转换,从而显著提高了Q 复制的效率,并消除了由于代码页转换所带来的异常。

通过对上述两种配置方法的对比分析，我们知道，第二种代码页转换配置方案更加适应我们的需求，这里的关键在于及目标队列管理器的 CCSID 参数的设置。

清单 1 给出了修改 queue manager CCSID 参数的方法：

                1. strmqm qmgr_name        #启动queue manager
2. runmqsc qmgr_name       #进入MQSC交互模式
3. DISPLAY QMGR CCSID      #显示queue manager的CCSID
4. ALTER QMGR CCSID(1208)  #修改queue manager的CCSID =1208
5. END                     #结束MQSC交互模式

接收队列 -> apply 程序 -> 目标数据库

图 4 展现了数据由接收队列到目标表的过程中，不同参数的配置对数据代码页转换的影响，这一过程中的代码页转换与 apply 程序密切相关，并且这一代码页转换的特殊之处在于控制表 IBMQREP_TRG_COLS 中 MSG_COL_CODEPAGE 列的代码页是当我们在创建 Q 预定集时向控制表中插入的，具体说明请参照前文。

在表 4 中给出了影响代码页转换过程的所有参数，并选取了一组特定值来进行分析：

• 采用默认参数的配置：

  当用户注册目标表及创建 Q 预定集时，并未更改目标服务器上 DB2CODEPAGE 注册变量的值（此时的默认值由系统LOCALE决定，为943），因此 MSG_COL_CODEPAGE 中的代码页为 943，而我们所创建的目标数据库是 Unicode 数据库（代码页 = 1208），因此错误的代码页转换再度发生，由于 apply 程序通过 MSG_COL_CODEPAGE 判断目标数据库的代码页，因此通过接收队列获得的数据发生了代码页 1208 到 943 的转换。显然，这里由于用户不恰当的设置带来了错误的代码页转换，最终造成了数据转换异常。

• 采用修正参数的配置：

  这里在进行 Q 复制相关操作之前，用户通过设定 DB2CODEPAGE = 1208，从而保证目标队列管理器 CCSID，目标端服务器的 DB2CODEPAGE，及 MSG_COL_CODEPAGE 列具有相同值，因此 apply 程序对目标表做出了正确的代码页判断。这样我们避免了不必要的代码页转换，从而显著提高了 Q 复制的效率，并消除了由于代码页转换所带来的异常。

通过对上述两种配置方法的对比分析，我们知道，第 2 种代码页转换配置方案正是我们所需要的，这里的关键在于开始 Q 复制的相关动作之前必须保证 DB2CODEPAGE 注册变量的正确设置。

回页首

结束语

通过对数据复制系统中代码页转换过程及配置方法的分析可以看出，对各个代码页相关参数的设置将直接影响数据复制系统工作的准确性与高效性，因此，当我们使用数据复制来实现商业需求时，对代码页配置方案应当进行周密的设计与测试，尽可能地避免及减少代码页转换次数，从而优化解决方案。

回页首

术语表

下表罗列了对正文中各专业术语的简要介绍，如果需要更加详细的信息，请查阅相关资料：

参考资料

• “使用 XML-RPC 为 C++ 应用程序启用 Web 服务”（developerWorks 中国，2006 年 9 月）介绍了将 C++ 方法暴露为 Web 服务的详细指南。
  
  
• 在 developerWorks 中国网站 Architecture 专区中学习更多体系结构方面的知识。
  
  

• 下载 IBM 软件试用版，体验强大的 DB2®，Lotus®，Rational®，Tivoli® 和 WebSphere® 软件。

• 查看 developerWorks 博客的最新信息。
  
  

作者简介

		IBM 中国软件开发中心 WebSphere Information Integrator 组软件工程师。

		IBM 中国软件开发中心 WebSphere Information Integrator 组软件工程师。

		IBM 中国软件开发中心 WebSphere Information Integrator 组实习生。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首