搜索文章：

首页  |  Java技术  |  Asp.net  |  Asp编程  |  VC/C++  |  Delphi  |  VB编程
上一篇：从 Microsoft SQL Server 2000 移植 >>

升级到 Informix Dynamic Server 9.40FC1

一次成功的经历

级别: 初级

Jianing Fan
Software Engineer, Motorola
2004 年 7 月

升级数据库不是一项简单任务，但也不必对它感到头痛。本文详细列出了成功进行 IDS 9.4 家族升级的每一个步骤。

简介
我们部门最近成功地完成了到 Informix ®Dynamic Server (IDS) 9.40FC1X1 （64 位版本）的升级。这是一次美好经历。本文详细描述了我们采取的每一个步骤，希望这对那些打算在不久的将来升级到 IDS 9.4 产品家族的人有所帮助。

升级数据库并非易事，不像在老版本上安装一个新版本，然后运行它那么简单，它涉及大量的调查、仔细的评估、密集的测试和考虑周详的决策。

我们以前使用的是 IDS 9.21FC5，但是这个版本到 2003 年 12 月份的时候将面临 Informix 所谓的 EOM（即“end of marketing”，退出市场）。这意味着 IDS 9.2 产品即将寿终正寝，我们再也无法获得对 IDS 9.2 产品的全力支持。这是一个极为严重的问题，因为我们的应用程序完全是以数据库为中心的（database centric）。从体系结构到设计，从测试到发布，几乎产品开发周期中的每一个阶段都离不开全面的技术支持。

我们面临两个选择，要么暂时先升级到 IDS 9.3 产品家族，要么直接升级到 IDS 9.4 产品家族。一开始我们把目光投向 IDS 9.30FC1，并且对该产品做了大量的测试。测试的结果表明，IDS 9.30FC1 会导致应用程序的性能严重下降。通过 Informix 技术支持我们发现，导致上述问题的主要原因是在 B-tree 清理器线程中有一个 bug。但是，得到能修复这个 bug 的补丁得花大约两个月的时间。而我们不能等，因为我们必须在生产期限前交出我们的产品，而且，IDS 9.3 产品家族同样很快也会面临 EOM 的问题（也就是在 2004 年的 1 月份）。

于是我们又评估了 IDS 9.4 产品，希望能在升级到 IDS 9.4 产品之后，解决在 IDS 9.30FC1 中发现的 B-tree 清理器线程 bug，并得到全面的 Informix 技术支持。我们选择了 IDS 9.40FC1，这是当时最新的也是最好的 IDS 9.4 产品，并开始对它进行评估。

预期的好处与风险
升级到 IDS 9.40FC1 的最大好处当然是可以获得对该产品的全面技术支持，这确保了在应用程序开发周期的所有阶段都能得到最大的 Informix 支持。

另一个优势是，新版本的 Informix（即 IDS 9.40FC1）提供了相当多的共享内存方面的 bug 修复程序。在以往的版本当中，存在与 Informix 共享内存有关的许多问题，其中包括：

  • 运行 SQL 查询时出现内存泄漏。
  • 多线程 ESQL/C 程序经常崩溃。
  • 头文件内存块莫名其妙地毁坏。
  • 执行 SQL 语句时共享内存出现崩溃。

 

所有这些问题都可以追溯为一个或多个 Informix bug，这些 bug 最终导致 Informix 引擎挂起或崩溃。这大大增加了产品系统的停机时间，并对我们在客户心目中的形象造成负面影响。而一旦有了这些 bug 的修复程序，我们预计 IDS 9.40FC1 共享内存将更稳定、更可靠。

此外，我们预计可以从 IDS 9.40FC1 的新特性中获得一些好处，比如：

  • 通过 B-tree 扫描器获得改进的事务处理能力。B-tree 扫描器是一种机制，能够在更新或者作废事务提交后删除被删除的索引条目，重新平衡索引节点。IDS 9.4 改进了这一机制，它创建一个热点清单（hot list），跟踪记录每个索引项引发问题的次数，并计算将那些索引项保存在 B-tree 中所需的代价。在以前的版本中，B-tree 扫描器必须检查索引中的所有节点，找出需要删除的项。而在现在这个版本中，B-tree 扫描器可以通过检查热点清单，自动地决定需要删除的索引项。这无疑可以提高整体性能。请参阅 Performance Guide以了解更多细节。
  • 缓冲区管理器改进的 Priority 管理。为了更有效地管理缓冲区，新版本将缓冲区分为两类：一类是高优先级的缓冲区，一类是低优先级的缓冲区。高优先级缓冲区是用户和查询访问最频繁的缓冲区。这种优先级分类是动态的，是根据观察到的对每个缓冲区的访问率而定的。IDS 9.4 会将那些高优先级的缓冲区尽可能长时间地保留在内存中，以避免缺页，这的确减少了整个系统 CPU 的使用。请参阅 Performance Guide 以了解更详细的信息。

 

有了这两个新特性，IDS 9.40FC1 现在就已经更有效地使用系统资源，并且可以使用有限的系统资源获得性能的提高。

  • 支持 2.81 Client SDK 包。这对于我们的开发小组来说是一个很棒的特性。目前我们使用的是 2.70 Client SDK。这个版本在多线程编程方面存在一些 Informix bug。新的 Client SDK 版本修复了那些 bug，此外，还为我们提供了大量的新特性，这些新特性使得 ESQL/C 编程更加顺利，同时也更加可靠。
  • 在数据库管理工具方面的加强。 在这一类中有很多新特性，不过我们最感兴趣的还是下面一些新特性：
    • 在数据库恢复期间重命名 chunk。这是一次革命性的改进。之前的 IDS 版本在 ontape 备份和恢复当中对 chunk 的路径限制得非常严格。如果 chunk 路径或 chunk 偏移量在备份之后遭到更改，那么就无法进行恢复了。而现在这种限制将被取消，我们可以在完成备份之后随心所欲地改变 chunk 偏移量的 chunk 路径，几乎可以在任何地方使用 ontape 备份和恢复，而且没有任何实际意义上的限制。
    • 显示环境变量。这在调试过程中非常有用。现在，当 IDS 环境崩溃或挂起时，我们就可以识别出 IDS 的初始环境。通常这可以为我们提供发现问题根源的线索。
    • 装载和卸载更大的文件。在我们的应用程序中，我们需要做大量的装载和卸载工作，随着版本的变迁，文件也变得越来越大。因此这一特性十分有用。
    • 动态逻辑日志文件。在之前的版本中，所有新增的逻辑日志在使用之前必须进行备份。有了这个新特性，我们就不必担心在添加逻辑日志之后对它们的备份。一旦将这些逻辑日志添加到 Informix 引擎中，就可以马上使用它们。更妙的是，当 IDS 识别到需要长时间事务和回滚的时候，它会动态地添加逻辑日志。
  • 在 SQL 方面的增强。 在这一类中有很多好的特性，不过我们最感兴趣的是下面一些特性：
    • 支持 hold 游标的 PDQ 功能。在新的 IDS 版本中，以 WITH HOLD 关键字声明的任何游标都将是并行处理的。这将大大提高游标性能。
    • From 子句中的函数。在新版本中，我们可以使用由 FROM 子句和 SELECT 语句中的用户定义函数创建的虚表。这为开发人员在构造 SQL 语句的过程中提供了更多的灵活性。
    • 增强的 Select 语句。新版本在 SELECT 语句方面有很多增强。其中对我们最有用的是对 ORDER BY 子句的增强，现在 ORDER BY 子句可以包括在 SELECT 子句中没有出现的列名或表达式。在之前的版本中，必须先在 SELECT 子句中列出这些列来，才能对它们进行排序，但是现在就不必这样做。
    • 增强的动态查询支持。在 IDS 9.4 中，DESCRIBE 语句可以提供关于准备好的 DML 语句（prepared DML statement）的动态参数的信息。如果在 DESCRIBE 语句中指定了 INPUT，那么该语句将返回有关准备好的 DML 的每个输入参数的信息，其中包括数据类型、标识符和参数长度。对于 OUTPUT 参数也是如此。如果在 DESCRIBE 语句中指定了 OUTPUT，那么该语句将提供有关每个输出参数的信息。这对于 ESQL/C 开发人员来说是一个很大的帮助。
    • 动态查询监控。新的 IDS 能够为任何查询动态地设置 explain plan。这是通过执行 onmode –Y 命令来实现的。例如，如果发现一个长时间挂起的查询，又想知道该查询的细节，便可以执行 onmode –Y，它会为该查询设置解释计划，这样您就可以分析主目录中的 sqlexplain.out 文件，查看该查询的所有输入和输出。这对于调试有问题的查询非常有帮助。

 

另外，在安全性、性能、可靠性和可扩展性方面也有很多其他的新特性，这些新特性同样可以在将来为我们带来诸多好处，例如文件或 chunk 的大下限变得更大，增加了数据库别名等。要查看 IDS 9.4 新特性的完整列表，请参阅 Chapter 2 of Getting Started 。

IDS 9.40FC1 是 IDS 的主要版本，它在代码和功能性方面有了很多改变，更重要的是，它在整体体系结构上也作出了大量的改动，这使得它与其他 IDS 版本有很大的不同。这些为我们的升级敲响了警钟，我们必须非常小心。以下是我们非常关心的一些问题：

  • 我们的应用程序可能与 IDS 9.40FC1 不兼容，换句话说，应用程序的某些功能在升级后可能无法运行。
  • IDS 9.40FC1 可能会带来其他新的 bug，这些 bug 可能损害一定的功能或者降低应用程序的性能。
  • 其他第三方软件也可能与 IDS 9.40FC1 不兼容。我们使用的是 Bio Query 和其他 API。所有软件在升级之后都可能无法工作。
  • 升级之后我们应用程序的总体性能可能会降低。

 

在作出最终是否采纳的决定之前，我们需要仔细地评估上述每一项风险，全面地对新的 IDS 版本进行测试。

测试计划
我们的目标是在不损害应用程序现有的任何功能或者降低系统和应用程序性能水平的前提下升级到 IDS 9.40FC1。为了达到这个目标，我们需要一个周详的测试计划，以便严格地测试系统和应用程序的每一个方面。经过一些会议和讨论之后，我们得出了如下测试计划：

  • 评估 9.40FC1 每个遭到反对和未获得支持的特性，确保那些特性不会妨碍我们的升级。具体的行动计划是检查 IDS 9.40FC1 的产品说明（release notes），并与开发人员进行讨论，同时还要查看我们的应用程序代码，看一看应用程序代码是否包含任何 9.40FC1 反对和不支持的特性。
  • 验证应用程序代码是否包含 IDS 9.40FC1 保留关键字。行动计划是检查产品说明，找出 9.40FC1 保留关键字清单，然后查看应用程序代码，看一看在代码中是否存在这些保留关键字。
  • 验证那些已知的有关 Informix 共享内存和其他问题的主要 Informix bug 在新版本中是否得到了修复。行动计划包括：
    1. 检查由 Informix tech 发送的 bug fix 清单。对于每个版本，Informix 都有一个 bug fix 清单。我们需要请求 Informix 为我们提供这样的清单，看一看那些 bug 是否在清单中。
    2. 只检查 bug fix 清单是不够的，还需要设计一些测试来百分之百地确信这些 bug 在新版本中已得到了修复。
  • 测试我们使用了 9.4x Informix 的现有应用程序的功能和性能，来确保我们的应用程序与新版本兼容，不存在严重的功能和性能退化。我们还有一些子系统在使用该应用程序，因而也需要为每个这样的系统设计一套测试案例，以确保每个子系统在功能和性能上都没有问题。
  • 用 IDS 9.40FC1 所带的 2.81.UC1 Client SDK 编译我们的应用程序，然后测试其功能和性能，确保应用程序与新版本的 Client SDK 兼容。我们需要在测试机器上安装 2.81UC1 Client SDK 包，然后重新运行机器，对每个子系统的所有功能和性能进行测试，以验证功能和性能方面没有退化。
  • 测试并验证我们有足够的关键系统资源来运行 IDS 9.40.FC1。我所说的关键系统资源是指 CPU、内存和磁盘。这是为了测试，以确定我们当前可以使用的系统资源是否能够承受新版本的 Informix。
  • 在使用更大数据库的生产环境下测试我们的应用程序。在完成了所有初步测试之后，我们需要在测试机器上安装生产数据库，并重新运行所有测试，看一看我们的应用程序在生产环境下运行得怎样。

 

测试结果和问题
从测试结果可以得出结论：

  • 我们测试计划的第一项是验证遭反对和未获得支持的特性。下面的表展示了我们调查的结果：

 

遭反对和未获得支持的特性 测试结果
集合派生的（collection-derived）表的旧格式 无集合表
IFX_UPDDESC 环境变量 没有设置
CDR_QDATA_SBFLAGS 配置参数 没有设置
7.x 和 9.x 之间的远程查询 没有应用
DEFAULT_ATTACH 环境变量 没有设置
对每个存储过程的 341 个参数的限制 没有超出
INSTEAD OF 触发器不能与远程视图一起使用 无 INSTEAD 触发器
逻辑日志文件不能超出 1 G 没有超出
LOAD 和 UNLOAD 文件的 2G 的大小限制 没有超出

显然，在这方面我们不存在任何问题。

 

  • 下一项是验证应用程序代码是否包含 9.40FC1 保留关键字。我们查看了应用程序代码，结果表明我们的应用程序没有包含任何那样的保留关键字。因此这方面也没有任何问题。
  • 接下来是验证新版本的 Informix 是否真的修复了有关共享内存的 bug。测试表明，新版本的确修复了之前版本中那些已知的共享内存 bug。
  • 我们计划中的下一项是对每个子系统进行功能和性能测试。下面的表展示了测试的细节。

 

CM 子系统：

描述 功能 基准线 新版本
WS 创建 通过 4m50s 1m44s
WS 删除 通过 5m19s 1m19s
WS 验证 通过 6m02s 1m
影响 通过 46m21s 13m37s
发布 通过 66m04s 34m54s
下载 NE 通过 n/a n/a
WS 之后更新 Stats 通过 7m33s 1m06s
访问远程服务器 失败 n/a n/a

PM 子系统：

描述 功能 基准线 新版本
产生 4 天的数据 通过 n/a n/a
装载 4 天的数据 n/a 2h59m 2h19m

FM 子系统：

描述 功能 基准线 新版本
访问数据库 通过 n/a n/a

Platform 子系统：

描述 功能 基准线 新版本
执行 cutover 脚本 通过 n/a n/a

Brio Query 子系统：

描述 功能 基准线 新版本
提出 Brio Query 失败 n/a n/a
运行 CM Brio Query 失败 n/a n/a
运行 CM Brio Query 失败 n/a n/a

DBA 子系统：

描述 功能 基准线 新版本
开启/关闭服务器 通过 n/a n/a
执行 re-layout 脚本 通过 n/a n/a
执行 dbspace 检查 通过 n/a n/a
执行所有 onstat 通过 n/a n/a
导入 airgen 数据库 通过 1h30m20s 43m19s
导入 mso 数据库 通过 1m 5m
更新统计信息 通过 43m17s 9m44s

上面那些表表明大部分测试案例都完成得很成功，新版本的 Informix 比老版本要运行得好，但是仍然存在以下三个问题：

  • 对 CM 子系统的访问远程服务器测试遭到失败。该项测试是从本地 Informix 服务器调用一个远程存储过程。这对于我们来说是一个严重的问题，因为我们应用程序的大部分工作都要依赖于本地与远程 Informix 服务器之间的通信。
  • 导入 mso 数据库所花的时间太长，比以前长 5 倍。而实际上 mso 数据库是一个很小的数据库。这显然对性能有负面影响。
  • Brio Query 子系统在所有功能测试中都遭到失败。前面曾提到，Brio Query 是一个第三方的 GUI 软件。那么，这是否说明 Brio Query 与新版本的 IDS 不兼容呢？这是一个极其重要的问题，因为我们的客户必须使用这个 GUI 界面来查询我们的数据库。
稍后我们将讨论对这些问题的解决方案。

 

 

  • 下一项是使用 2.81UC1 Client SDK 重新编译应用程序，并重新对每个子系统的功能和性能进行测试，看一看用新的 Client SDK 包（2.81UC1）编译过的应用程序是否与 IDS 9.40FRC1 很好合作。下面的表展示了该项测试的结果：

 


遭反对和未获得支持的特性 测试结果
集合派生的表的旧格式 无集合表
IFX_UPDDESC 环境变量 没有设置
CDR_QDATA_SBFLAGS 配置参数 没有设置
7.x 和 9.x 之间的远程查询 没有应用
DEFAULT_ATTACH 环境变量. 没有设置
对每个存储过程的 341 个参数的限制 没有超出
INSTEAD OF 触发器不能与远程视图一起使用 无 INSTEAD 触发器
逻辑日志文件不能超出 1 G 没有超出
LOAD 和 UNLOAD 文件有 2G 的大小限制 没有超出

CM 子系统：

描述 功能 基准线 新版本
WS 创建 通过 4m50s 1m
WS 删除 通过 5m19s 1m
WS 验证 通过 6m02s 1m
影响 通过 46m21s 13m3s
发布 通过 66m04s 34m5s
下载 NE 通过 n/a n/a
WS 之后更新 Stats 通过 7m33s 1m
访问远程服务器 失败 n/a n/a

PM 子系统：

描述 功能 基准线 新版本
产生 4 天的数据 通过 n/a n/a
装载 4 天的数据 n/a 2h59m 2h11m

FM 子系统：

描述 功能 基准线 新版本
访问数据库 通过 n/a n/a

Platform 子系统：

描述 功能 基准线 新版本
执行 cutover 脚本 通过 n/a n/a

Brio Query 子系统：

描述 功能 基准线 新版本
提出 Brio Query 失败 n/a n/a
运行 CM Brio Query 失败 n/a n/a
运行 CM Brio Query 失败 n/a n/a

DBA 子系统：

描述 功能 基准线 新版本
启动/关闭服务器 通过 n/a n/a
执行 re-layout 脚本 通过 n/a n/a
执行 dbspace 检查 通过 n/a n/a
执行所有 onstat 通过 n/a n/a
导入 airgen 数据库 通过 1h30m20s 43m1s
导入 mso 数据库 通过 1m 5m
更新统计信息 通过 43m17s 9m40s

测试结果看上去与以前的那项测试颇为相似。这表明用新的 Client SDK 编译后的应用程序与新版本的 IDS 是兼容的。因此这对于升级来说不是问题。

 

  • 下一项是检查我们以当前所提供的系统资源是否能够运行新的 IDS。下面的表表明没有任何问题：

 

描述 基准线 新版本
最大 CPU 使用情况 25% 30%
最大内存使用情况 1.8 G 1.8 G
磁盘利用情况：
Dbspace1 50% 50%
Dbsapce2 55% 55%
Dbspace3 60% 60%
Dbspace4 40% 40%
Logspace 90% 90%
Indexspace 80% 80%

如上表所示，新版本的 Informix 在内存和磁盘的使用情况上与老版本差不多，只不过 CPU 的利用率增加了 5 个百分点。我们的系统有 6 个 CPU，可以在一定程度上承担这个增加量。因此，这不会成为升级到 IDS9.40FC1 的障碍。

 

  • 我们计划的最后一项是使用生产数据库进行进一步的测试。不过，在此之前，我们需要解决前面测试当中遇到的一些问题。

 

问题解决及最终决定
那么，我们怎样解决前面测试中遇到的那些问题呢？我们请求 Informix 技术支持部门给予帮助。Informix 技术支持部门在分析了我们发送给他们的数据之后，他们找出了两个新的 Informix bug：

  • 第一个问题，不能访问远处服务器，该问题由一个 Informix bug (#163194) 引起。这个 bug 表明程序在使用远程语法执行存储过程准备好的语句时将失败。例如，如果有一条像 "execute procedure dbname@otherinst:testproc( ?, ? )" 这样的准备好的语句，那么在执行过程中就会收到一个错误消息。对于这个 bug，没有变通方法，但是 Informix 将为我们提供这个 bug 的补丁。
  • 第二个问题，导入 mso 数据库花费太长的时间，这是由另一个新的 Informix bug (# 161340) 引起的。该 bug 表明，在创建存储过程的时候，dbimport 极慢。这个问题变通方法是将导出的模式文件分为两部分，即表部分和存储过程部分。然后使用 Informix dbimport 实用程序导入表部分，使用 Unix cat 实用程序创建和编译存储过程部分。
  • 至于第三个问题，即关于 Brio Query 的问题，Informix 技术部门建议我们在安装新的 Client SDK 时保留旧的 I-connect。这样就解决了这个问题。

 

我们请求 Informix 提供了补丁，并将其安装在测试机器上。我们还应用了导入数据库的变通办法，解决了 Brio Query 问题。然后我们将生产数据库放到测试机器上，重新对每个子系统进行测试，确保那些问题已经解决，同时在性能和功能上没有退化。下表展示了测试每个子系统的测试结果：

CM 子系统：

描述 功能 基准线 新版本 使用补丁
WS 创建 通过 4m50s 1m44s 1m
WS 删除 通过 5m19s 1m19s 1m1s
WS 验证 通过 6m2s 1m 56s
影响 通过 46m21s 13m37s 11m3s
发布 通过 66m4s 34m54s 30m20s
下载 NE 通过 n/a n/a n/a
在 WS 之后更新 Stats 通过 7m33s 1m6s 53s
访问远程服务器 通过 n/a n/a n/a

PM 子系统：

描述 功能 基准线 新版本 使用补丁
产生 4 天的数据 通过 n/a n/a n/a
装载 4 天的数据 n/a 3h 2h19m 2h

FM 子系统：

描述 功能 新版本 使用补丁
访问数据库 通过 n/a n/a

Platform 子系统：

描述 功能 新版本 使用补丁
执行 cutover 脚本 通过 n/a n/a

DBA 子系统：

描述 功能 基准线 新版本 使用补丁
开启/关闭服务器 通过 n/a n/a n/a
执行 re-layout 脚本 通过 n/a n/a n/a
执行 dbspace 检查 通过 n/a n/a n/a
执行所有 onstat 通过 n/a n/a n/a
导入 airgen 数据库 通过 1h30m20s 43m19s 40m
导入 mso 数据库 通过 1m 5m 2m
更新统计信息 通过 43m17s 9m44s 8m

下表展示了与不带补丁的新版本 IDS 相比，关键系统资源的使用情况：

描述 新版本 使用补丁
最大 CPU 使用情况 25% 25%
最大内存使用情况 1.8 G 1.8 G
磁盘使用情况：
Dbspace1 50% 50%
Dbsapce2 55% 55%
Dbspace3 60% 60%
Dbspace4 40% 40%
Logspace 90% 90%
Indexspace 80% 80%

最后，是时候评审所有测试结果并作出最终决定了。在仔细地评审了所有测试结果之后，我们得出以下结论：

  • 有了 Informix 提供的补丁，IDS 9.40FC1 通过了所有子系统的所有功能测试。这意味着 IDS 9.40FC1 不会破坏任何应用程序功能，并且能与我们的应用程序兼容。
  • 性能测试表明，使用了补丁的新版本跟老版本相比差不多，或者略微强一些。我们按照以下标准仔细地评价了每一项性能测试：
    • S，意即相同，时间上的改进低于 30 %。
    • B，意即更好，时间上的改进介于 30-60% 之间。
    • M，意即好得多，时间上的改进大于 60%。

 

下表展示了我们的评价：

描述 基准线 新版本 使用补丁 提高 (%) 评价
CM 子系统：
WS 创建 4m50s 1m44s 1m 79% M
WS 删除 5m19s 1m19s 1m1s 80% M
WS 验证 6m2s 1m04s 56s 98% M
影响 46m21s 13m37s 11m3s 76% M
发布 66m4s 34m54s 30m20s 55% B
WS 之后更新 Stats 7m33s 1m06s 53s 85% M
PM 子系统：
装载 4 天的数据 2h59m 2h19m 2h 24% S
DBA 子系统：
导入 airgen 数据库 1h30m20s 43m19s 40m 45% B
导入 mso 数据库 1m 5m 2m -100
更新统计信息 43m17 9m44s 8m 81% M

显然，除了一个测试案例以外，大部分测试都证明新的 IDS 与老版本相比在性能水平上要高得多。这个例外的测试案例就是导入 mso 数据库。但是这对于我们来说不是十分重要，因为我们的应用程序不怎么导入 mso 数据库，只在作为内部维护例程和数据库安装时才导入这样的数据库。况且，时间上也只相差 1 分钟而已，我们完全可以承受得了。那些测试使我们澄清了对新版本的 IDS 的认识，所以我们最终决定让整个部门升级到带补丁（X1）的 IDS 9.40FC1。

结束语
最终，在 8 月份的时候，我们部门都升级到了 IDS 9.40FC1X1，从升级到现在已经过去 5 个月了，我们几乎已走到了产品开发周期的收尾阶段。到现在为止，还没有出现任何 Informix 缺陷报告，而且在 Informix 共享内存方面也没有碰到任何问题。正如我们所预期的那样，新版本的 IDS 与我们的应用程序相处得很好，比起老版本的 IDS 来要稳定和可靠得多。此外，在升级到新版本的 IDS 之后，性能方面也有所提高。我们感觉到对 IDS 9.40 家族产品充满信心。

关于作者
Jianing Fan是 Motorola 的一名软件工程师，专门从事关系数据库管理系统。他是 Informix 认证专家和 Oracle 认证专家，作为开发人员、系统管理员和 DBA，他有十多年的数据库和系统经验。Jianing 是 Informix 网站的一名忠实读者。您可以通过 fan@eis.comm.mot.com与 Jianing 联系。
下一篇：利用您的 Oracle 9i >>
相关文章：
© 2006   www.java-asp.net