在 Pace Analytical Services, Inc.，我们生产的产品是数据。Pace Analytical 位于环境测试行业，这意味着我们的客户将空气、水和土壤样本带给我们，并要求我们测试它们是否含有污染物。我们回馈给客户的是一份报告，包括电子版和纸质版，告知他们在样本中发现的化合物类型和浓度。

我们公司的关键任务应用是我们的实验室信息管理系统 (LIMS)。该系统的主要目标是为我们的客户提供快速、准确和及时的信息；它基于 Oracle 关系数据库。LIMS 通过模拟实验室操作，处理从样品登记到发票开具的一切事务。LIMS 消除了冗余流程和数据输入，并在整个系统中实现了质量控制批次、数据报告和计费等领域的更高标准化。

我们 Y2K 计划的一个方面是更新 LIMS 以符合 Y2K 标准。这意味着从 Oracle RDBMS 的 7.0.16 版本升级到 7.3.4，将所有 Oracle Forms 3.0 代码转换为 4.5 版本，并将 C 代码转换为正确处理日期。这个项目中真正的工作结果不是 Y2K 问题，而是将所有 Oracle Forms 代码转换为在新版本的 Oracle Forms 工具中工作。

与 Y2K 开发同时，我们面临的另一个问题是 LIMS 服务器上的响应时间和吞吐量。随着时间的推移，由于用户数量增加以及同一服务器上运行多个数据库实例，系统负载增加。当时，Pace Analytical 有三台服务器，全部是 HP-UX 系统：一台 HP9000-H70、一台 HP9000-I70 和一台 HP9000-K200，所有这些都已使用了三年多。我们运行的是旧硬件，我们的需求超出了其交付能力。

我们研究了从硬件获得改进响应的选项。鉴于现有配置，例如磁盘条带化，我们已经解决了我们能解决的一切问题。一个主要的瓶颈是整个 SCSI 通道的总吞吐量限制为 20MB/秒。一个选项是添加更快的通道。HP 有一张可以与 SCSI 子系统 (RAID) 通信的卡，但价格似乎很高，即使在二手市场上也是如此；我们能找到的最佳报价约为 10,000 美元。另一个选择是添加更多卡以获得更多 20MB/秒的通道。经过仔细分析，我们清楚地认识到，除了 SCSI 通道外，硬件还受到 CPU 和 RAM 的限制。

讨论的另一个选项是购买新的 HP-UX 服务器。这代表着一笔可观的投资——三台服务器超过六位数。大约在这个时候，Pace Analytical 数据库管理员 Michael Lester 提出了一个替代方案。他提议购买基于 Intel 的硬件（PC 兼容）并在 Linux 上运行 Oracle 8，使用 Oracle SQL*Net 在当前的 HP-UX 服务器和 Linux 数据库服务器之间进行通信。Michael 的提议在很多方面都很有意义。首先，如果我们能够转向基于 Intel 的硬件平台，那么随着需求超出硬件容量，升级硬件将更容易且更便宜。基于 Intel 的硬件要便宜得多，并且在组件出现问题时可以很容易地在本地获得。随着硬件的升级，旧服务器可以作为基于 Windows 的桌面系统投入使用，但旧的 HP 硬件对我们毫无用处。

新硬件使用 SCSI Ultra2，也是一种宽格式，每个通道的吞吐量为 80MB/秒。由于成本较低，我们可以负担得起安装四个通道：一个用于操作系统和存档驱动器，一个用于较慢的磁带和 CD 驱动器，两个用于数据库。数据库的六个驱动器配置为 RAID 并拆分——两个数据库通道上各三个驱动器。在这种配置中，数据库驱动器的最大吞吐量约为 160MB/秒，比旧硬件快八倍。CPU 是 600MHz 双 Pentium III 处理器。在基准测试中，这仅比旧硬件上的 HP RISC 处理器快大约两倍。

一台服务器的总成本，包括 512MB RAM，约为 10,000 美元。我们能够以与升级现有服务器上的 SCSI 子系统相同的成本构建一台全新的服务器，其 SCSI 通道上的吞吐量是原来的八倍，处理器速度是原来的两倍。我们保守地估计，性能比旧硬件提高了五到十倍。然而，真正的考验始终是系统在实际生产环境中的表现。我们没有失望。几个在旧硬件上会在后台运行 45 到 80 分钟的报告程序现在在六分钟或更短的时间内完成。一位实验室主管真的跑到 IS 区域问：“LIMS 怎么了？它飞快！”

该项目不像仅仅构建一台 Linux 服务器那么简单。正如我在开头提到的，最初的计划是在 HP 硬件上升级到 Oracle 版本 7.3.4。为了在 Linux 操作系统上运行 Oracle，我们被迫升级到 Oracle 数据库的第 8 版。在 Linux 上安装 Oracle 8 没有真正的问题，只有一个小补丁需要安装才能重新编译它。我们发现 Oracle8 的主要问题是它使用了一个较新的“rowid”概念。

无论硬件平台如何，都必须进行到 Oracle*Forms 4.5 的软件转换，因为数据库的 7.3 及更高版本不再支持版本 3。我们选择使用基于字符的 Oracle*Forms 4.5 版本。切换到基于事件的 GUI 界面将意味着对 100 多个 Forms 程序进行全面重组。起初，大多数问题是语法错误，这些错误在 Forms Version 3 中有效，但在新 Forms 版本中不再合法。一些命名约定发生了变化，我们恰好使用了新 Forms 不允许的对象（字段/触发器/变量）的名称。然后出现了将所有表单“集成”回 LIMS 产品的问题。例如，许多表单检查以查看哪个表单/菜单调用了它们，因此以不同的模式运行。在 Version 3 下，返回调用名称的函数以小写形式返回，而在 Version 4.5 中以大写形式返回，因此 IF 语句失败。我们添加了 lower(xxxxx) 函数以强制其小写。此外，还有许多表单作为弹出窗口从其他表单调用，并且许多屏幕布局都被搞乱了。

我们还遇到了 HP 字符模式终端仿真问题，这导致 Oracle/HP 资源文件损坏。最终，我们不得不切换到 VT220 仿真，并遇到了终端仿真的一些问题。VT220 终端有一种奇怪的“屏幕”内存。可以显示两个文本屏幕，用户通过向屏幕发送代码在它们之间切换。终端仿真器添加了一个垂直滚动条，从而可以滚动返回以查看之前屏幕上的内容。这不断地搞乱屏幕上的滚动区域，这正是 vi 和 Oracle 用于显示弹出窗口的方式。仿真器供应商 Minisoft (http://www.minisoft.com/) 反应非常迅速，并纠正了我们在使用其 VT220 产品时遇到的不兼容性。

另一个软件复杂性是 Forms 代码中的许多函数实际上是从 Forms 会话内部调用的 Pro-C 例程，称为“用户出口”。这些函数是专门为在 HP-UX 上运行而编写的。由于破译、转换和测试用户出口的复杂性，以及 1 月 1 日截止日期的不可动摇性，Michael 建议维护 HP-UX 服务器作为 Forms 程序的客户端服务器，并使其使用 Oracle SQL*Net 与数据库通信。我们的最终目标是消除用户出口，并用原生 SQL 编写它们，并将基于字符的界面转换为 GUI 界面。这将使在所有 Linux 服务器上运行三层客户端-服务器成为可能，从而消除我们老化的 HP-UX 硬件。

我已经讨论了该项目成功的一个衡量标准，即系统速度的显着提高。必须考虑的另一个衡量标准是正常运行时间。对于那些质疑 Linux 是否应该用于关键任务应用程序的人来说，我们的项目证明 Linux 能够胜任这项任务。我们在 1999 年 8 月安装了第一台服务器，另外两台服务器在一个月后安装，因此一台服务器已运行五个月，一台运行四个月，一台运行三个月。在这十二个月的运行中，由于 Linux 操作系统，我们绝对没有停机时间。Oracle 数据库配置出现了一些问题，但这在任何新安装中都是意料之中的。我们还在其中一台服务器的网络接口卡上遇到了问题，但我们将其更换为 Linux 支持的卡，并且该问题没有再次出现。

在重读这篇文章时，我突然想到很少提及 Linux。实际上，情况确实如此。衡量有效且健壮的操作系统真正标准是它应该对操作相当透明，这在我们应用中确实如此。如果没有迁移到 Linux 操作系统的选项，我们的选择要么是在新的 RISC 系统上花费五倍的钱，要么以相当于我们最终花费在最先进硬件上的成本，勉强维持远低于最佳性能的运行。就本项目而言，Linux 是构建一切的中心环节，并且它表现出色。