在数据库系统升级的过程中，数据库配置文件、日志、系统编目表、缓存池文件、索引页以及历史文件都会做相应的转换。其中系统编目表中保存着关于数据库中数据信息的元数据，它描述了数据的逻辑和物理结构。将联邦数据库升级到新版本，数据源的版本、位置、连接认证方式都可能发生变化；与此同时，新版本联邦数据库系统可能提供了对新的数据类型、函数、以及包装器模块功能的支持。因此，尽可能保证现有系统编目中的元数据在升级之后的数据库系统中仍然可用是联邦数据库升级的重点。

系统升级要点分析

在 DB2 数据库升级的同时，联邦数据库也随之升级到新的版本。但是联邦数据库系统作为相对独立的产品，有其自身的一系列特点，在升级的整个过程中也有需要特殊处理的地方。比如：

1. 拥有自己的数据库对象。
2. 拥有自己的系统编目表。
3. 拥有自己的工作引擎以及包装器模块。
4. 需要通过额外配置连接远程数据源。

清楚了解联邦数据库系统的构成以及工作方式，有助于对联邦数据库系统升级的深入理解。图 1 显示了 IBM 联邦数据库系统的体系结构。

联邦数据库系统 (Federated Database System) 包括联邦数据库服务器 (Federated database Server)，联邦数据库 (Federated Database)，一个或多个数据源 (Data Source)，以及使用该数据库或数据源的客户端应用程序 (Client) 。其中联邦数据库服务器构建于 DB2 实例 (DB2 instance) 之上，增加了自身的工作引擎和包装器模块文件；联邦数据库由 DB2 实例所创建，除依赖 DB2 现有的系统编目表外，还拥有特有的系统编目表；数据源可划分为关系型数据源和非关系型数据源，每种数据源对应的包装器 (Wrapper) 作为接口层实现联邦数据库服务器同数据源的具体交互；客户端应用程序仅通过与联邦数据库服务器的交互即可实现使用单一的 SQL 语句向多个数据源发出分布式请求。

在这里只对联邦数据库系统相关的升级要点进行分析。如果 DB2 环境中有其它组件，如 DB2 服务器、客户端、数据库应用等需要升级，请参考 DB2 相关升级文档。

升级内容分析

联邦数据库服务器

联邦数据库服务器的升级依赖于 DB2 数据库系统的升级。联邦数据库服务器升级有两种方式：

1. 将数据库备份后恢复到新的服务器上，属于隐式升级方式。
2. 使用 db2iupgrade 命令调用 DB2 实例升级，属于显式升级方式。

联邦数据库

对应联邦数据库服务器的两种升级方式，数据库的升级分别为：

1. 调用 RESTORE DATABASE 命令隐式升级。
2. 显式的调用 UPGRADE DATABASE 命令。

联邦数据库系统编目表中包含了联邦数据库对象的信息和数据源对象的信息，因此通常也被称为全局系统编目表。保存在全局编目表中的信息既有本地的，也有远程的。比如表列名，列数据类型，列缺省值，以及索引定义等。全局编目表中也保存着其它关于数据源的信息，比如连接数据源的方式，联邦用户认证到数据源用户认证的映射。下面的表格详细分析了联邦数据库系统编目中各个数据对象对系统功能的影响，对应的系统编目表以及升级内容的描述。其中升级描述中仅说明了用户可见的，直接影响使用功能的内容。

数据源

数据库系统升级时如果有环境配置的变化，升级程序并不能对其进行自动更新。对数据源进行重新配置可能有以下两种情况：

1. 联邦数据库系统全新安装。数据源客户端需要完全重新配置。
2. 在同一机器上升级 DB2 实例。首先需要确认数据源，数据源客户端是否发生变化，以便修改对应的环境变量。对于大多数数据源的包装器，如 Oracle、 Informix 等，提供给客户的包装器安装文件是静态库，需要运行 djxlink 脚本对这些库文件与数据源客户端库文件重新连接。而对于 DRDA 和 ODBC 包装器，为客户提供的是动态链接库，因此不需要运行 djxlink 脚本；但是需要保证其客户端库文件路径定义选项正确。

升级的局限性

联邦数据库升级着重对数据库内在变化的更新，在升级过程中体现尽力服务原则。它存在如下局限性：

1. 联邦数据库对象中与数据源配置相关的选项不能自动修改。如数据源客户端库文件路径等。
2. 联邦服务器对数据源元数据的命名发生变化。在 V95 版本中，生成列名和索引名的方法发生改变。如果从 V95 以前的版本升级到 V95 及以后，表别名删除重建后，其列名可能会发生改变，并影响 SQL 应用程序。在这种情况下，需要对该列重命名以保证应用程序仍然可用。
3. 包装器对数据源数据类型的支持发生变化，如 Cobra 版本中 Teradata 包装器增加了对数据源 LOB 数据类型的支持。升级程序并不将这一新特性更新到别名的定义中。
4. 包装器对数据源自定义函数的支持发生变化，如在 Cobra 版本中 MQ 包装器对 UDF 进行了简化。数据库升级后需要应用程序做相应的修改。

升级的建议

新版本联邦数据库系统可能支持新的数据类型，对数据源对象元数据的获取方式和内容也可能发生变化；同时，用户在升级计划中可能需要更改访问数据源的包装器以获取新的包装器功能。因此在对联邦数据库升级之前，建议通过 db2look 工具获取并保存数据库对象的定义脚本。它将会是对升级之后的数据库对象进行修改或重建的重要依据。

制定升级计划

在对数据库系统进行升级之前，必须制定一个周密详细的可以逐步执行的升级计划。联邦数据库系统设计在 DB2 之上，其升级过程也依赖于对 DB2 的升级。关于 DB2 升级计划的详细制定我们可以参考DB2 升级计划。

联邦数据库系统升级的一般步骤如图 2 所示。与 DB2 数据库系统升级不一样的步骤在于升级的准备阶段和升级后的任务阶段。其中升级准备阶段包括：分析目标系统是否支持现有数据源，若不匹配则需要做升级数据源的准备；以及保存数据源配置信息。升级后任务阶段包括检查 / 配置数据源，故障诊断与修改，以及更新统计信息 3 个步骤。

升级前的准备

1. 检查将要更新的数据库版本是否支持当前数据源的版本。如果不支持，那么就需要对数据源和数据源相应的客户端做相应的更新。
2. 在将数据库系统安装升级到全新环境时，为了避免升级以后对包装器进行重复的配置，我们需要把这些配置文件以及环境变量保存下来。详细内容如下：

1. 联邦数据库配置文件 db2dj.ini， 其位置为：

   UNIX/Linux®: instancehome/sqllib/cfg/db2dj.ini

   Windows®: %DB2PATH%\cfg\db2dj.ini

2. 包装器相关配置文件：

   
   
   

   包装器	配置文件
   Sybase	interfaces
   Informix	interfaces
   ODBC	odbc.ini
   Oracle	tnsname.ora

   
   
   

执行数据库系统升级

完成配置文件的备份并保存环境变量后，可执行联邦数据库系统的升级。具体步骤如下：

1. 隐式升级：

   1. 备份原有数据库：

      db2 backup database <database name>

      
      

   2. 检查数据库备份文件的完整性：

      db2ckbkp <backup image>

      
      

   3. 执行恢复命令，将数据库更新到新版本数据库系统中：

      db2 restore database <database name>

      
      

2. 显式升级：

   1. 首先升级数据库实例：

      db2iupgrade <database instance name>

      
      

   2. 然后升级数据库：

      db2 upgrade database <database name>

      
      

升级之后的任务

检查配置数据源

1. 复原联邦数据库系统配置

   将升级之前创建的 db2dj.ini 文件副本拷贝到 DB2 注册变量 DB2_DJ_INI 指定的目录或

   缺省目录下。

2. 恢复访问数据源

   各个数据源包装器具有不同的访问配置方式。如 Oracle, Informix, SqlServer, Teradata 等数据源包装器需要以下几个步骤重新连接生成：

   1. 根据升级后环境确认数据源环境变量设置正确。

   2. 运行 djxlink 脚本。

   3. 重新启动 DB2 实例。

不同数据源环境变量详细设置说明请参考环境变量配置。

故障诊断与处理

在执行数据库升级命令以及检查配置数据源之后，需要检查联邦数据库对象是否能够正确运行，通常步骤如下：

1. 使用 CLP 工具连接至联邦数据库。

2. 使用 PASSTHRU 模式，检查联邦服务器是否能够访问数据源，并确认数据源对象正常。

   SET PASSTHRU <datasource_server<; SELECT * FROM <remote_table<;

   
   

3. 对表别名执行 SELECT、INSERT、UPDATE 和 DELETE 语句来验证是否可以查询和修改数据。若发现不能正常运行的情况，从分析各个联邦数据库对象的功能入手，确定可能出现问题的环节。下面的脚本可以帮助我们查询各个数据库对象的定义信息：

			
 SELECT WRAPNAME, WRAPTYPE, WRAPVERSION, LIBRARY FROM SYSCAT.WRAPPERS; 
 SELECT WRAPNAME, OPTION, SUBSTR(SETTING, 1, 50) AS SETTING FROM SYSCAT.WRAPOPTIONS; 

 SELECT WRAPNAME, SERVERNAME, SERVERTYPE, SERVERVERSION FROM SYSCAT.SERVERS; 
 SELECT WRAPNAME, SERVERNAME, SERVERTYPE, SERVERVERSION, OPTION, SUBSTR(SETTING, 1, 50)
AS SETTING FROM SYSCAT.SERVEROPTIONS; 

 SELECT TABNAME,TYPE FROM SYSCAT.TABLES WHERE TYPE='N'; 
 SELECT t.TABNAME, t.TABSCHEMA, OPTION, SUBSTR(SETTING, 1, 50) AS SETTING
FROM SYSCAT.TABOPTIONS to, SYSCAT.TABLES t where to.TABNAME = t.TABNAME AND t.TYPE='N'; 

 SELECT t.TABNAME, COLNAME, TYPENAME, LENGTH, SCALE FROM SYSCAT.COLUMNS c, SYSCAT.TABLES t
where c.TABNAME = t.TABNAME AND t.TYPE='N'; 
 SELECT t.TABNAME, COLNAME, OPTION, SUBSTR(SETTING, 1, 50) AS SETTING
FROM SYSCAT.COLOPTIONS c, SYSCAT.TABLES t where c.TABNAME = t.TABNAME AND t.TYPE='N'; 

 SELECT TYPE_MAPPING, MAPPINGDIRECTION as direction, UPPER_LEN, LOWER_LEN, UPPER_SCALE,
LOWER_SCALE, REMOTE_UPPER_LEN, REMOTE_LOWER_LEN, REMOTE_UPPER_SCALE, REMOTE_LOWER_SCALE
from SYSCAT.TYPEMAPPINGS; 

 SELECT FUNCTION_MAPPING, OPTION, SUBSTR(SETTING, 1, 50) AS SETTING
FROM SYSCAT.FUNCMAPOPTIONS; 
 SELECT FUNCTION_MAPPING, ORDINAL, LOCATION, OPTION, SUBSTR(SETTING, 1, 50) AS SETTING
FROM SYSCAT.FUNCMAPPARMOPTIONS; 
  
 SELECT INDNAME, t.TABNAME, USER_DEFINED, SYSTEM_REQUIRED FROM SYSCAT.INDEXES i,
SYSCAT.TABLES t where i.TABNAME = t.TABNAME AND t.TYPE='N'; 
 SELECT INDNAME, OPTION, SUBSTR(SETTING, 1, 50) FROM SYSCAT.INDEXOPTIONS;

在确定数据库对象定义出现问题后，可对数据库编目表做相应更改。有两种修改方式：

对联邦数据库对象部分修改

1. 包装器

   可以对包装器的选项定义做出修改。比如对其防护模式进行修改的语句如下：

   ALTER WRAPPER <wrapper_name> OPTIONS (SET DB2_FENCED ‘ Y ’ )

   
   

   对于 ODBC 包装器，可对其 MODULE 选项修改以指定正确的库文件路径：

   ALTER WRAPPER <wrapper_name> OPTIONS (SET MODULE '/opt/odbc/lib/libodbc.a(odbc.so)')

   
   
2. 服务器

   对服务器定义的修改包括：数据源版本，类型，所属包装器，以及其它定义选项。比如升级过程中数据源版本发生变化，那么就需要对服务器中的数据源版本定义修改。其语句如下：

   ALTER SERVER <server_name> VERSION <new_version>

   
   

   也可以更改服务器所对应的数据库名称：

   ALTER SERVER <server_name> OPTIONS (SET DBNAME ‘ <alias1> ’ )

   
   
3. 用户映射

   对用户映射定义的修改包括访问数据源用到的用户 ID 和密码。比如数据源的密码发生了变化，对用户映射中 REMOTE_PASSWORD 选项修改的语句如下：

   ALTER USER MAPPING FOR USER SERVER <server_name> OPTIONS ( SET REMOTE_PASSWORD ‘ <new_password> ’ )

   
   

4. 表别名

   新版本联邦数据库系统对数据类型的映射可能发生变化，其直接反映就是表别名列的数据类型定义。联邦数据库系统升级命令会自动为数据类型的变化进行修改。

5. 索引清单

   对表别名增加新的索引清单语句如下：

   ALTER NICKANME <nickname> ADD CONSTRAINT <constraint_name> UNIQUE(<column1>) NOT ENFORCED

   
   

6. 函数映射

   联邦数据库系统升级命令会自动为其参数数据类型的变化进行修改。

7. 数据类型映射

   联邦数据库系统升级命令会自动为本地数据类型的变化进行修改。

对联邦数据库对象删除重建

对联邦数据库对象的删除并不会影响位于数据源的数据。用户重新建立数据库对象的步骤如下：

1. 运行 db2look 命令从数据库系统编目中获取部分或全部数据库联邦对象定义脚本。例如：

   db2look – d <database_name> – fedonly – wrapper <wrapper_name> – e – o fsddl.sql

   
   

   此命令输出指定包装器相关的联邦对象的 DDL 语句到 fsddl.sql 文件中。若需要创建所有联邦对象的 DDL 语句，运行下面命令：

   db2look – d <database_name> -fedonly – e – o fsddl.sql

   
   
2. 编辑 fsddl.sql 文件中的 DDL 语句。
   1. 更改包装器的定义。根据需要更换包装器；并指定正确的包装器模块库文件名。
   2. 为 CREATE SERVER 语句添加正确的 AUTHORIZATION 和 PASSWORD 参数。根据实际情况更改服务器中数据源的版本信息。
   3. 在 CREATE USER MAPPING 语句中插入正确的密码。
   4. 检查通过使用 WITH CHECK OPTION 子句创建的任何本地视图的 SQL 语 句。因为此子句不再受支持，应从 fsddl.sql 文件中除去创建这些本地视图的 SQL 语句。
3. 删除包装器。和该包装器关联的服务器，用户映射，数据类型映射，函数映射以及 表别名都将自动删除。

4. 运行 fsddl.sql 脚本，重新定义对数据源的访问：

   db2 – tvf fsddl.sql

   
   

5. 重新绑定由删除包装器导致的任何变得无效的应用程序包。引用删除后重建表别名的静态 SQL 所属的包装器都应当重新绑定。如果未重新绑定程序包，则在运行这些程序包时可能会接收到错误的消息。重新绑定程序包命令如下：

   db2 rebind package_name

   
   
6. 重新创建在删除包装器时所有变得无效的联邦视图。引用删除后重建表别名的所有视图都应当重新创建。

更新统计信息

联邦数据库在创建表别名时自动提取数据源的统计信息并保存在全局编目中以便优化查询。若升级过程中表别名不需要重建并且数据源发生变化，利用 nnstat 存储过程对数据源统计信息更新，可使得升级过程更加完善。如更新 ORACLESERV 服务器下所有表别名统计信息命令如下：

CALL SYSPROC.NNSTAT('ORACLESERV',NULL, NULL, NULL, NULL, 0, NULL, ?)

下面的命令可以更新 IIDEV22 模式中所有表别名统计信息，并将日志保存在 <nnstat_logfilename.log> 文件中：

CALL SYSPROC.NNSTAT(NULL, 'IIDEV22', NULL, NULL, NULL, 0, '<nnstat_logfilename.log>', ?)

结束语

联邦数据库系统升级的最大问题在于数据库对象的定义不能随着升级环境的变化而更改。深入理解联邦数据库系统的体系结构，分析各个数据库对象的功能以及定义，有助于我们定位并解决升级过程中的问题。

参考资料

学习

• 通过developerWorks Information Management 专区：在这里可以学到更多关于 Information Management 的知识。还可以找到技术文档、how-to 文章、培训、下载、产品信息等。
  
  
• 参考“IBM DB2 V9.7 信息中心（联合）”，了解更多 DB2 V9.7 及 InfoSphere Federation Server 安装、升级、管理和诊断的相关内容。
  
  
• 通过访问 InfoSphere Federation Server 产品站点，了解更多有关 InfoSphere Federation Server 的更多产品和技术资源。
  
  

获得产品和技术

• 使用可直接从 developerWorks 下载的 IBM 试用软件 构建您的下一个 Linux 开发项目。
  
  

讨论

• 参与 developerWorks blogs 并加入 developerWorks 社区。
  
  

作者简介

为本文评分

评论

回页首

内容

• 系统升级要点分析
• 制定升级计划
• 升级前的准备
• 执行数据库系统升级
• 升级之后的任务
• 参考资料
• 作者简介
• 建议