您可能需要安装一个级别与计算机上当前已安装的其它 DB2 产品的版本不同的 DB2(R) 产品。要求 DB2 产品处于相同级别。
|如果要安装的产品的级别比同一计算机上已安装的其它 DB2 产品的版本级别要新，则需要将现有 DB2 产品更新为较新的级别。例如，如果要安装修订包级别为 10 的 DB2 Connect(TM) for iSeries(TM)，而其它 DB2 产品的修订包级别为 9，则在安装修订包级别为 10 的 DB2 Connect for iSeries 之前，需要将修订包 10 应用于当前已安装的 DB2 产品。
|相反，如果要在安装了较新版本的 DB2 产品的计算机上安装一个产品，需要遵循以下一些准则：
| | db2licm -a filename其中 filename 是许可证文件的名称，可以在原始介质的 db2\license 目录中找到它。还可以将此许可证添加至修订包的 db2\license 目录，这样将在安装过程中安装该许可证。
|在安装额外的产品或组件之前，必须停止下列项：
|必须停止的实例和 DAS 属于将安装额外 DB2 产品或组件的 DB2 安装的实例和 DAS。
|有关进一步的指示信息，参阅修订包自述文件。
如果当前系统上不存在 |DB2 DAS，但额外产品或组件需要或支持 DB2 DAS，则 db2setup 将在安装期间安装 DB2 DAS。在某些平台上，使用 db2setup 创建 DB2 DAS 期间可能会出错。这些错误是意料之中的，可以忽略它们。
|可以在要安装的额外产品或组件的 |DB2 产品 CD 或映像中找到 db2setup 程序。
|有关使用 db2setup 的详细信息，参阅《命令参考》指南和《安装和配置补遗》。
|可以在要安装的额外产品或组件的 DB2 产品 CD 或映像中找到 db2_install 脚本。
|有关使用 db2_install 脚本的详细信息，参阅《安装和配置补遗》。
|有关使用系统安装程序的详细信息，参阅《安装和配置补遗》。
|要说明此场景，假定下列情况：
|安装后必须重新应用常规修订包 10。
| |程序包 db2cliv81 已安装在系统上。 |安装补丁 nnnnnnn-nnn 异常终止。 |要重新安装此补丁，在尝试重新安装它之前先卸载它。产生此错误的原因是系统中的 db2cliv81 已经与正在安装的修订包处于同一级别。可以忽略这种类型的错误。使用系统安装程序确认 DB2 组件或程序包确实与正在安装的修订包处于同一级别。
如果您使用 DB2 通用数据库(TM)版本 8.2 来创建数据库，则不能在版本 8.1 级别使用该数据库。只能在版本 8.2 或更新级别使用该数据库。
在 DB2(R) UDB 版本 8.2 级别创建的数据库可能具有较早版本不具备的其它功能。这种差别可能会导致您在试图将新数据库移至 DB2 UDB 的前发行版时产生意外的并且是不希望发生的行为。
《DB2 客户机快速入门》的『DB2 客户机概述』一节说明了下列内容：
DB2 客户机可以连接至比该客户机的发行版级别晚两个发行版或者早一个发行版的 DB2 服务器，还可以连接至与它处于同一个发行版级别的服务器。
针对该陈述的修正如下：
虽然在某些环境中可以从版本 N 的客户机连接至版本 N + 2 的服务器，但是，仅当在使用版本 N 时此连接才是受支持的配置。一旦不使用版本 N，此配置就不再受支持。
因为已经不再使用 DB2 版本 7，所以连接至 DB2 版本 8 服务器的 DB2 版本 7 客户机不再受支持。
在 DB2 UDB 版本 8.2 级别所作的任何注册表更改在迁移回 DB2 UDB 版本 8.1 时都会丢失。注册表还原为版本 8.1 HealthRules.reg 文件，该文件包含升级至 DB2 UDB 版本 8.2 并开始使用 HealthRules2.reg 文件中的设置之前已经存在的设置。
在 DB2 通用数据库（UDB）版本 8 之前，修订包仅充当对一个修订位置的已安装 DB2 UDB 程序包或文件集的更新。这表示修订包安装将现有文件替换为已更新文件，这些更新文件是在修订包中提供的。单个系统中不能有多个 DB2 修订包级别共存。现在，DB2 UDB 企业服务器版（ESE）可在基于 Linux(TM) 和基于 UNIX(R) 的操作系统的同一系统中以多个修订包级别存在。自从版本 8.1.2 开始，此功能即在生产操作环境中受支持，它是通过使用以下两种修订包类型实现的：
要将多修订包实例更新为另一修订包级别，执行下列其中一个操作：
有关备用修订包的进一步信息：
从版本 8.2.2（相当于版本 8.1 修订包 9）开始，在 32 位环境中捕获的 TRACK_QUERY_INFO Query Patroller 控制表的内容可以在 64 位环境中使用。此功能使得迁移至 64 位环境所需的工作轻松不少。在版本 8.2.2 中的 TRACK_QUERY_INFO Query Patroller 控制表中捕获的信息不能用于生成该查询的历史数据或在任何先前的修订包级别下执行已挂起查询。
对于 DB2 通用数据库（UDB）企业服务器版版本 8 数据仓库中心的先前服务器支持，存在下列局限性：
在 Windows(R) 或 UNIX 操作系统上，当在 DB2 通用数据库（UDB）版本 8 的“应用程序开发”客户机上使用开发中心时，需要在服务器上安装下列 APAR 才能启用 SQLJ 和“SQL 助手”支持：
可以从 DB2 通用数据库版本 8 中调用版本 7 和版本 8 的 SQL 助手。可从 DB2 数据仓库中心中启动版本 7。所有其它中心启动最新的版本 8。产品的联机帮助中包含关于 SQL 助手版本 7 的其它信息。
在版本 7 中，Unicode 服务器在连接时忽略应用程序发送的任何图形代码页，并假设使用的是 UCS2 Unicode（代码页 1200）。版本 8 Unicode 服务器现在接受由客户机发出的代码页。
DB2 UDB 版本 8.2 使用名为 SQLDBCONF 的新的 16K 数据库配置参数文件。这是一个与名为 SQLDBCON 的 DB2 UDB 版本 8.1 4K 数据库配置参数文件不同的文件。
在迁移到 DB2 UDB 版本 8.2 之后，该产品将迁移版本 8.1 4K 文件的内容，并使用 16K 文件来记录数据库配置参数更改。保留了版本 8.1 4K 文件，但是未使用它。
如果迁移回 DB2 UDB 版本 8.1，则 DB2 UDB 版本 8.1 产品将还原为使用原始的版本 8.1 4K 文件来记录数据库配置参数更改。保留了版本 8.2 16K 文件，但是 DB2 UDB 版本 8.1 产品不能识别它。实际上，较早的 DB2 UDB 级别看不到迁移至版本 8.2 和迁移回版本 8.1 时对 16K 数据库配置参数文件所作的更改，因为这些更改未迁移至原始 4K 文件。
另外，如果再次迁移至 DB2 UDB 版本 8.2，则 DB2 UDB 版本 8.2 产品会认为 16K 数据库配置文件已存在，从而还原为使用版本 8.2 16K 文件来记录数据库配置参数更改。保留了版本 8.1 4K 文件，但是 DB2 UDB 版本 8.2 产品不识别它。实际上，更新的 DB2 UDB 级别看不到迁移回版本 8.1 并重新迁移至版本 8.2 时对 4K 数据库配置参数文件所作的更改，因为这些更改未迁移至现有 16K 文件。
db2diag.log 文件的格式在版本 8.2 中已作了一些改进。现在，日志文件更便于人们阅读并且更易于使用软件进行解析。改进内容有：
还作了其它更改，例如，将 database 字段名更改为 DB。
事件记录已作为诊断消息添加至 db2diag.log 文件。这类事件的示例包括：
对事件记录在 LEVEL 字段中指定了“Event”。尽管事件不是错误，但根据其重要性它们可能在 4（参考）或 3（警告）以外的诊断级别作记录。
从版本 8.2 开始，下列更新将记录在 db2diag.log 文件中：
这些更新的消息将根据其重要性在高诊断级别作记录。
将记录下列类型的 db2set 概要文件注册表更新：
2004-04-22-19.19.14.156959-240 I79582C286 LEVEL: Event PID : 2437242 TID : 1 PROC : db2set INSTANCE: db2user NODE : 000 FUNCTION: DB2 UDB, oper system services, db2set_main, probe:40 CHANGE : CFG DB2SET: DB2DBDFT: From: "OLDDB" To: "SAMPLE"
CHANGE : CFG DB2SET: DB2DBDFT: From: "SAMPLE" To: ""
CHANGE : CFG DB2SET: Profile registry was reset
DB 和 DBM 配置参数更新的示例包括：
CHANGE : CFG DB SAMPLE: "Maxlocks" From: "10" To: "20" CHANGE : CFG DBM: "Diaglevel" From: "3" To: "1" CHANGE : CFG DBM: Reset to the system defaults
要查找这些配置更新消息，使用 db2diag 工具。例如：
DB2 通用数据库(TM)（UDB）Linux、UNIX 和 Windows(R) 版版本 8.2.2（相当于版本 8.1 修订包 9）支持在所有 DB2 UDB 支持的 32 位和 64 位工作站操作系统环境中使用的 JDK 1.4.2。此支持包括（但不限于）对构建和运行 Java(TM) 客户机应用程序的支持、对从命令行构建和运行 Java(TM) 例程的支持、对从支持它的 DB2 开发中心构建和运行 Java 例程的支持以及对运行其它 DB2 工具的支持。
安装 DB2 UDB 版本 8.2 时，还将安装最新的受支持版本的 Java Developer Kit（如果还未安装的话），除非 DB2 UDB 安装是先前 DB2 UDB 版本 8 安装的更新。如果要更新 DB2 UDB 版本 8 的先前安装，必须从 CD 安装 Java Developer Kit。
下表指示 DB2 支持的 32 位和 64 位工作站操作系统环境和每个环境支持的最新 JDK 级别。有关之前 JDK 支持的信息，参阅 Java Application Development Web 页面，网址如下：http://www.ibm.com/software/data/db2/udb/ad/v8/java/。
| DB2 支持的环境 | 最新的受支持 JDK 级别 |
|---|---|
| Windows IA/AMD 32 位 | JDK 1.4.2 |
| Windows IA 64 位 | JDK 1.4.2 |
| Windows AMD/EM64T 64 位 | JDK 1.4.2 |
| AIX(R) 4.3.3 32 位 | JDK 1.3.1 SR6 [2] |
| AIX(R) 5（混合 [1]） | JDK 1.4.2 |
| Solaris（混合[1]） | JDK 1.4.2 |
| HPUX RISC & Itanium（混合[1]） | JDK 1.4.2.01 |
| Linux AMD/EM64T 32 位，64 位（混合[1]） | JDK 1.4.2 [3] |
| Linux IA 32 位 | JDK 1.4.2 |
| Linux IA 64 位 | JDK 1.4.2 |
| Linux 390 31 位 | JDK 1.4.2 |
| Linux 390 64 位 | JDK 1.4.2 |
| Linux PPC（混合[1]） | JDK 1.4.2 |
下面是设置 Linux Java 环境的更新过程。
要在带有 DB2 JDBC 支持的 Linux 上构建 Java 应用程序：
要运行 Java 存储过程或用户定义的函数，Linux 运行时链接程序必须能够访问特定 Java 共享库，并且 DB2 UDB 必须能够装入这些库和 Java 虚拟机。运行存储过程和用户定义的函数的过程只会将这些库装入在 /etc/ld.so.conf 文件中定义的安全位置。其中一个安装位置为 /usr/lib。余下指示信息显示哪些库在 /usr/lib 中需要符号链接。
cd /usr/lib ln -fs JAVAHOME/jre/bin/libjava.so . ln -fs JAVAHOME/jre/bin/classic/libjvm.so . ln -fs JAVAHOME/jre/bin/libhpi.so .其中 JAVAHOME 是 IBM(R) Developer Kit 的基本目录。如果 DB2 UDB 找不到这些库，在尝试运行 Java 例程时将产生 -4301 错误，并且管理通知日志中将出现有关找不到库的消息。
cd /usr/lib ln -fs JAVAHOME/jre/bin/libjava.so ln -fs JAVAHOME/jre/bin/classic/libjvm.so ln -fs JAVAHOME/jre/bin/libhpi.so ln -fs JAVAHOME/jre/bin/libjsig.so其中 JAVAHOME 是 IBM Developer Kit 的基本目录。如果 DB2 UDB 找不到这些库，在尝试运行 Java 例程时将产生 -4301 错误，并且管理通知日志中将出现有关找不到库的消息。
cd /usr/lib ln -fs JAVAHOME/jre/bin/libjava.so ln -fs JAVAHOME/jre/bin/classic/libjvm.so ln -fs JAVAHOME/jre/bin/libhpi.so ln -fs JAVAHOME/jre/bin/libjsig.so ln -fs JAVAHOME/jre/bin/libjitc.so ln -fs JAVAHOME/jre/bin/libxhpi.so ln -fs JAVAHOME/jre/bin/libdbgmalloc.so其中 JAVAHOME 是 IBM Developer Kit 的基本目录。如果 DB2 UDB 找不到这些库，在尝试运行 Java 例程时将产生 -4301 错误，并且管理通知日志中将出现有关找不到库的消息。
JAVAHOME/jre/bin其中 JAVAHOME 是 IBM Developer Kit |的基本目录。如果 DB2 UDB 找不到这些库，在尝试运行 Java 例程时将产生 -4301 或 -1042 错误。 |
可以将存储 Java 共享库的目录的名称添加至 /etc/ld.so.conf 文件，而不是在 /usr/lib 目录中显式创建指向共享库的链接。此文件需要 root 用户许可权。在更新 /etc/ld.so.conf 之后，您必须作为 root 用户运行 ldconfig 命令以激活您的更改。如果在此备用过程中遇到任何问题，按先前的指示在 /usr/lib 目录中创建这些链接。
如果要使用被配置为将 NETBIOS 协议与 DB2 系列产品配合使用的 Microsoft(R) XP 64 位操作系统（2600），您需要从 Microsoft 获取最新修订程序。请与 Microsoft 联系以获取编号为 Q317437 的 Knowledge Base 文档。
只有 DB2 通用数据库（UDB）个人版产品才支持 Windows XP Home Edition 操作系统。
Windows XP Professional 操作系统受下列 DB2 产品支持：
仅支持下列 DB2 产品在 Windows XP 上进行开发和测试（生产环境需要 Windows 2000 或 Windows Server 2003）：
在 DB2 通用数据库（UDB）版本 8.2 中，DB2 UDB 工作组服务器版和 DB2 UDB 易捷版（当根据每个用户定价模型发放许可证时）不能安装 DB2 UDB 高可用性灾难恢复（HADR）单独定价选件。在 DB2 UDB 版本 8.2 修订包 1（相当于版本 8.1 修订包 8）中已经修正了此问题。
DB2 仓库管理器标准版版本 8.2 中的 OLAP 实用程序与 IBM DB2 OLAP Server(TM) FP3（Essbase API 级别 6.5.4）和更新版本不兼容。在解决此问题之前，建议您使用 DB2 OLAP Server FP2（Essbase 6.5.3）或较早版本。
要在 DB2 通用数据库（UDB）版本 8.2.2（相当于版本 8.1 修订包 9）之前将日志与原始 I/O 设备配合使用，需要将物理设备绑定至带有原始实用程序的 Linux 原始字符设备驱动程序。从 DB2 UDB 版本 8.2.2（相当于版本 8.1 修订包 9）开始，可直接指定日志的原始 I/O。例如，要将设备分区 /dev/sdb1 用于 SAMPLE 数据库的原始日志，发出以下命令：
db2 update db cfg for sample using newlogpath /dev/sdb1
尽管 DB2 UDB 仍支持将原始实用程序用于原始 I/O 的方法，但最新分发产品已不推荐使用此功能，将来可能会除去它。首选方法是通过直接指定设备来使用新方法。
DB2 通用数据库版本 8.2 支持 Red Hat Enterprise Linux AS 版本 3 和 2.1。但是，数据仓库中心仅支持 Red Hat Enterprise Linux AS V2.1。数据仓库中心使用的是不支持 Red Hat Enterprise Linux AS V3.1 的 DataDirect ODBC 驱动程序。因此，数据仓库中心不支持 Red Hat Enterprise Linux AS V3.1 代理站点中的 ODBC 仓库源和仓库目标。
| | |在 IBM(R) WebSphere(R) MQ（以前称为 IBM MQSeries(R)）环境中运行应用程序时，WebSphere(R) MQ 可以充当符合 XA 的事务管理器，它协调任何分布式两阶段落实事务。当 WebSphere MQ 以这种方式充当事务管理器，并且数据源来自 DB2 系统产品时，有一些配置要求。已经记录了大多数这些配置要求。例如，必须在 DB2 运行时客户机处将 DB2 配置参数 TP_MON_NAME 设置为“MQ”。
|但是，还有一个配置要求尚未记录。当连接至为 DB2 OS/390(R) 版服务器的数据源时，该配置要求特定于 DB2 Connect：使用 WebSphere MQ 协调涉及 DB2 z/OS(R) 版和 DB2 iSeries 版服务器的分布式事务时，必须在网关处启用 DB2 Connect 连接集中器功能。当 MAX_CONNECTIONS 配置参数的值大于 MAX_COORDAGENTS 的值时，启用连接集中器。如果不启用连接集中器，将产生意外事务行为。
Microsoft 日语 Windows Shift-JIS 代码页被注册为 IBM 编码字符集标识（CCSID）943。然而，该 Shift-JIS 代码页在 HP-UX 平台上被注册为 CCSID 5039。CCSID 5039 仅包含日本工业标准（JIS）中的字符，而不包括任何供应商定义的字符。在 HP-UX 上，可以使用 CCSID 5039 的 DB2 通用数据库（UDB）数据库来存储 Shift-JIS 字符，但是 CCSID 5039 与 CCSID 943 之间将存在代码页转换。如果使用 Microsoft ODBC 应用程序，在将 CCSID 5039 格式的数据转换为 Unicode 时可能会遇到问题，这是由于 IBM 的代码页转换表与 Microsoft 的代码页转换表之间存在差异造成的。
当从 CCSID 5039 转换为 Unicode 时，以下字符列表可能会产生不同的代码点，这取决于所使用的转换表（IBM 或 Microsoft）。对于这些字符，IBM 转换表遵守日本工业标准 JISX0208 和 JISX0221。
| Shift-JIS 代码点（字符名称） | IBM 主要代码点（Unicode 名称） | Microsoft 主要代码点（Unicode 名称） |
|---|---|---|
| X'815C'（长破折号） | U+2014（长破折号） | U+2015（横杠） |
| X'8160'（波浪号） | U+301C（波浪号） | U+FF5E（全角代字号） |
| X'8161'（双竖线） | U+2016（双竖线） | U+2225（平行线） |
| X'817C'（减号） | U+2212（减号） | U+FF0D（全角减号短划线） |
例如，当使用 IBM 转换表时，CCSID 5039 代码点为 X'815C' 的长破折号字符被转换为 Unicode 代码点 U+2014，但当使用 Microsoft 转换表时，却被转换为 U+2015。这对于 Microsoft ODBC 应用程序可能会产生潜在问题，因为这些应用程序会认为 U+2014 是无效的代码点。为了避免这些潜在问题，除了缺省 IBM 转换表之外，DB2 UDB 还提供了从 CCSID 5039 转换为 Unicode 的备用 Microsoft 转换表。需要将缺省 IBM 转换表替换为备用 Microsoft 转换表。注意，从 Unicode 转换为 CCSID 5039 的缺省 IBM 转换表要与 Microsoft 版本相匹配。
当从 CCSID 5039 转换为 Unicode 时，会使用 DB2 通用数据库（UDB）缺省代码页转换表。如果您希望使用另一版本的转换表（如 Microsoft 版本），则必须手工替换缺省转换表（.cnv）文件。
在替换 sqllib/conv 目录中的现有代码页转换表文件时，应备份该文件以备您想要将它改回来。在 UNIX 和 Linux 上，sqllib/conv 目录链接至 DB2 UDB 安装路径。
要使转换表替换生效，连接至同一数据库的每个 DB2 UDB 客户机必须更改其转换表。否则，不同的客户机可能会使用不同的代码点存储同一个字符。
要替换用于从 CCSID 5039 转换为 Unicode 的 DB2 UDB 缺省转换表，遵循下列步骤：
日语 EUC 代码页的 IBM 编码字符集标识（CCSID）被注册为 CCSID 954。CCSID 954 是日语 UNIX 和 Linux 平台的公共编码。当使用 Microsoft ODBC 应用程序来连接至 CCSID 为 954 的 DB2 通用数据库（UDB）数据库时，在将数据从 CCSID 954 转换为 Unicode 时会遇到问题。潜在问题是由于 IBM 的代码页转换表与 Microsoft 的代码页转换表之间的差异造成的。IBM 转换表遵守在“日本工业标准”（JIS）JISX0208、JISX0212 和 JISX0221 中指定的字符名称。
当从 CCSID 954 转换为 Unicode 时，根据使用的是 IBM 转换表还是 Microsoft 转换表，下列字符将产生不同的代码点。
| EUC-JP 代码点（字符名称） | IBM 主要代码点（Unicode 名称） | Microsoft 主要代码点（Unicode 名称） |
|---|---|---|
| X'A1BD'（长破折号） | U+2014（长破折号） | U+2015（横杠） |
| X'A1C1'（波浪号） | U+301C（波浪号） | U+FF5E（全角代字号） |
| X'A1C2'（双竖线） | U+2016（双竖线） | U+2225（平行线） |
| X'A1DD'（减号） | U+2212（减号） | U+FF0D（全角减号短划线） |
| X'8FA2C3'（短划线） | U+00A6（短划线） | U+FFE4（全角短划线） |
例如，当使用 IBM 转换表时，CCSID 954 代码点为 X'A1BD' 的长破折号字符被转换为 Unicode 代码点 U+2014，但当使用 Microsoft 转换表时，却被转换为 U+2015。由于转换映射的这种差异，对于 DB2 UDB Unicode 数据库或 DB2 UDB 954 数据库的图形列中的同一个字符可能有两个不同的代码点。这对于 Microsoft ODBC 应用程序可能会产生潜在问题，因为这些应用程序会认为 U+2014 是无效的代码点。为了避免这些潜在问题，除了缺省 IBM 转换表之外，DB2 UDB 还提供了从 CCSID 954 转换为 Unicode 的备用 Microsoft 转换表。需要将缺省 IBM 转换表替换为备用 Microsoft 转换表。注意，从 Unicode 转换为 CCSID 954 的缺省 IBM 转换表要与 Microsoft 版本相匹配。
当从 CCSID 954 转换为 Unicode 时，会使用 DB2 通用数据库（UDB）缺省代码页转换表。如果您希望使用另一版本的转换表（如 Microsoft 版本），则必须手工替换缺省转换表（.cnv）文件。
在替换 sqllib/conv 目录中的现有代码页转换表文件时，应备份该文件以备您想要将它改回来。在 UNIX 和 Linux 上，sqllib/conv 目录链接至 DB2 UDB 的安装路径。
为了使替换生效，连接至同一个 CCSID 954 数据库的每个 DB2 UDB 客户机都必须更改它们的转换表。如果客户机是日语 Windows（其 ANSI 代码页是 Shift-JIS（CCSID 943）），则还需要将 CCSID 943 与 Unicode 之间的 DB2 缺省转换表更改为 Microsoft 版本。否则，不同的客户机可能会使用不同的代码点存储同一个字符。
要替换用于从 CCSID 954 转换为 Unicode 的 DB2 UDB 缺省转换表，遵循下列步骤：
要替换用于在 CCSID 943 与 Unicode 之间转换的 DB2 UDB 缺省转换表，遵循下列步骤：
当使用被注册为 IBM 编码字符集标识（CCSID）943 的 Microsoft 日语 Windows Shift-JIS 代码页时，在 CCSID 943 与 Unicode 之间转换字符时可能会遇到下面两个问题。潜在问题是由于 IBM 与 Microsoft 代码页转换表之间的差异造成的。为了避免这些潜在问题，除了缺省 IBM 转换表之外，DB2 通用数据库（UDB）还提供了 CCSID 943 与 Unicode 之间的备用 Microsoft 转换表。
由于历史原因，CCSID 943 代码页中有超过 300 个字符存在每个字符被表示为两个或三个代码点的情况。使用输入方法编辑器（IME）和代码页转换表导致只有其中一个等效代码点被输入。例如， 对应罗马数字一“i”的小写字符有两个等效代码点 X'EEEF' 和 X'FA40'。Microsoft Windows IME 在输入“i”时总是生成 X'FA40'。通常，IBM 和 Microsoft 使用同一主要代码点表示该字符，但是下列 13 个字符除外：
| 字符名称（Unicode 代码点） | IBM 主要 Shift-JIS 代码点 | Microsoft 主要 Shift-JIS 代码点 |
|---|---|---|
| 罗马数字一（U+2160） | X'FA4A' | X'8754' |
| 罗马数字二（U+2161） | X'FA4B' | X'8755' |
| 罗马数字三（U+2162） | X'FA4C' | X'8756' |
| 罗马数字四（U+2163） | X'FA4D' | X'8757' |
| 罗马数字五（U+2164） | X'FA4E' | X'8758' |
| 罗马数字六（U+2165） | X'FA4F' | X'8759' |
| 罗马数字七（U+2166） | X'FA50' | X'875A' |
| 罗马数字八（U+2167） | X'FA51' | X'875B' |
| 罗马数字九（U+2168） | X'FA52' | X'875C' |
| 罗马数字十（U+2169） | X'FA53' | X'875D' |
| 用括号括起来的表意文字符号（U+3231） | X'FA58' | X'FA58' |
| 号码符号（U+2116） | X'FA59' | X'8782' |
| 电话符号（U+2121） | X'FA5A' | X'8754' |
诸如 DB2 UDB 这样的 IBM 产品主要使用 IBM 代码点（例如，X'FA4A'）来表示大写罗马数字一“I”，但是 Microsoft 产品使用 X'8754' 来表示同一字符。Microsoft ODBC 应用程序可以将“I”字符作为 X'8754' 插入到 CCSID 943 格式的 DB2 UDB 数据库中，而 DB2 UDB 控制中心可以将同一字符作为 X'FA4A' 插入到同一 CCSID 943 数据库中。但是，ODBC 应用程序只能找到将“I”编码为 X'8754' 的那些行，而 DB2 UDB 控制中心只能找到将“I”编码为 X'FA4A' 的那些行。为了使 DB2 UDB 控制中心能够选择“I”作为 X'8754'， 需要将 CCSID 943 与 Unicode 之间的缺省 IBM 转换表替换为备用 Microsoft 转换表。
当从 CCSID 943 转换为 Unicode 时，以下字符列表将产生不同的代码点，这取决于使用的是 IBM 转换表还是 Microsoft 转换表。对于这些字符，IBM 转换表遵守日本工业标准 JISX0208、JISX0212 和 JISX0221。
| Shift-JIS 代码点（字符名称） | IBM 主要代码点（Unicode 名称） | Microsoft 主要代码点（Unicode 名称） |
|---|---|---|
| X'815C'（长破折号） | U+2014（长破折号） | U+2015（横杠） |
| X'8160'（波浪号） | U+301C（波浪号） | U+FF5E（全角代字号） |
| X'8161'（双竖线） | U+2016（双竖线） | U+2225（平行线） |
| X'817C'（减号） | U+2212（减号） | U+FF0D（全角减号短划线） |
| X'FA55'（短划线） | U+00A6（短划线） | U+FFE4（全角短划线） |
例如，在使用 IBM 转换表时，CCSID 943 代码点为 X'815C' 的字符全角横杠被转换为 Unicode 代码点 U+2014。但是，在使用 Microsoft 转换表时，它会被转换为 U+2015。由于这一转换映射差异，DB2 UDB Unicode 数据库中可能存在两个不同代码点对应同一字符的情况。这对于 Microsoft ODBC 应用程序可能会产生潜在问题，因为这些应用程序会认为 U+2014 是无效的代码点。为了避免这一潜在问题，需要将 CCSID 943 与 Unicode 之间的缺省 IBM 转换表替换为备用 Microsoft 转换表。
使用 CCSID 943 与 Unicode 之间的备用 Microsoft 转换表应仅限于封闭环境，其中 DB2 UDB 客户机和 DB2 UDB 数据库都具有代码页 CCSID 943 且都使用同一备用 Microsoft 转换表。如果 DB2 UDB 客户机使用缺省 IBM 转换表，而另一 DB2 UDB 客户机使用备用 Microsoft 转换表，且两个客户机都将数据插入至 CCSID 943 格式的同一 DB2 UDB 数据库，则同一字符在该数据库中可能被存储为不同的代码点。
在 CCSID 943 与 Unicode 之间进行转换时，会使用 DB2 通用数据库（UDB）缺省代码页转换表。如果您希望使用另一版本的转换表（例如，Microsoft 版本），则必须手工替换缺省转换表（.cnv）文件。
在替换 sqllib/conv 目录中现有代码页转换表文件之前，应备份这些文件以防您想要将它们更改回来。在 UNIX 和 Linux 上，sqllib/conv 链接至 DB2 UDB 安装路径。
要使转换表替换生效，连接至同一数据库的每个 DB2 UDB 客户机必须更改其转换表。否则，不同的客户机可能会使用不同的代码点存储同一个字符。
要替换用于在 CCSID 943 与 Unicode 之间转换字符的 DB2 UDB 缺省转换表：
尽管在文档中提到了 MVS(TM) 操作系统，但是 DB2 通用数据库已不再支持它。MVS 已替换为 z/OS。
如果使用 Linux 390 操作系统，则可能无法对多个磁带设备进行备份和复原。
在 UNIX 上使用 Hummingbird(R) Exceed 访问开发中心时，必须先启用 XTEST extension V2.2 才能移动和悬停视图（通过在开发中心内拖动它们的标题栏）。
要启用 XTEST extension：