使用DB2 UDB V8.2进行32位和64位应用程序开发(1)

发表于:2007-07-13来源:作者:点击数: 标签:
术语 在讨论 DB2 对 32 位和 64 位的支持之前,首先将查看并理解本文的上下文中牵涉到的一些术语和重要概念,这十分重要: 平台: 计算机硬件和操作系统的基本技术,定义了计算机如何运行,以及可以在它上面运行什么样的软件。 硬件: 计算机以及它的相关架

术语

在讨论 DB2 对 32 位和 64 位的支持之前,首先将查看并理解本文的上下文中牵涉到的一些术语和重要概念,这十分重要:

  • 平台:计算机硬件和操作系统的基本技术,定义了计算机如何运行,以及可以在它上面运行什么样的软件。
  • 硬件:计算机以及它的相关架构。
  • 操作系统: 控制计算机硬件并允许其他应用程序和用户使用计算机的软件。操作系统由一个内核和一组操作系统库组成,其中内核直接与硬件打交道,而那些操作系统库则是构建和运行应用程序所必需的。
  • DB2 实例:一个逻辑数据库服务器环境,DB2 数据库就是在该环境中创建的。
  • 数据库客户机:向数据库服务器请求访问数据库对象和数据、运行应用程序或者请求基于应用程序的服务的计算机或软件程序。
  • 数据库服务器:计算机或程序,包含并管理数据库,同时处理客户机发出的对数据库数据的请求。
  • 32 位:一台计算机可以并行处理的二进制数字的个数(bit),或者表示内存寻址。例如,一台 32 位的计算机有 32 位宽的数据寄存器,并使用 32 位来标识内存中的每个地址。
  • 64 位:参见 32 位。一台 64 位的计算机有 64 位宽的数据寄存器,并使用 64 位来标识内存中的每个地址。

简介

您是否计划将数据库客户机或服务器迁移到 64 位平台,或者只是想构建和部署适合 64 位 DB2 实例的应用程序或例程,那么理解 DB2 对 32 位和 64 位应用程序开发的支持十分重要。同样重要的是,采用一些最佳实践有助于应用程序和例程的部署,并确保它们在目标环境中的功能与预期的一致。

本文分为三部分:首先将向您介绍 32 位和 64 位对象的概念,然后帮助您了解有关 32 位和 64 位 DB2 配置和特性支持的信息,最后帮助您制定出用于开发和部署适合 64 位 DB2 实例的应用程序的策略。

  • 第 I 部分:32 位和 64 位对象概述
  • 第 II部分:DB2 32 位和 64 位 应用程序和例程支持
  • 第 III 部分:开发和部署可移植的 32 位和 64 位 DB2 应用程序

第 I 部分:32 位和 64 位对象概述

广泛理解 32 位和 64 位对象在计算环境中的相关性十分重要,因为它们之间的某些依赖性可能影响到各个方面,包括所需购买的硬件,部署应用程序的方式等。

32 位和 64 位硬件

32 位计算机硬件使用 32 位来表示内存地址以及处理指令和数据。64 位硬件使用 64 位来做同样的事情。通常,32 位操作系统运行在 32 位的硬件上,而 64 位操作系统则运行在 64 位的硬件上,不过在某些 64 位的硬件上运行 32 位操作系统也是可能的。

32 位和 64 位操作系统

操作系统由一个内核和一组操作系统库组成,其中内核直接与硬件打交道。操作系统要么带有 32 位的内核,要么带有 64 位的内核,或者,在某些情况下同时带有这两种内核。通常,32 位操作系统内核可以使用 4 GB 的实际内存(即操作系统和正在运行的应用程序共享的物理 RAM),而 64 位操作系统内核可以使用更多的实际内存。当然,有些 32 位操作系统内核可以使用多于 4 GB 的内存,但是在这一点上仍然不如 64 位的内核。在某些操作系统上,可能必须有 64 位内核来运行 64 位应用程序,因为这种应用程序在使用 32 位内核的情况下是不能运行的。所有 UNIX® 操作系统都属于这种情况,只有 AIX® 例外。在 AIX 上,情况十分特殊,您可以任意使用 32 位或 64 位内核来运行 32 位和 64 位应用程序。然而,为了防止可伸缩性问题,在运行 32 位应用程序时最好使用 64 位内核。

操作系统库很重要,因为有了这些系统库才能构建和运行应用程序。为了构建 32 位应用程序,必须链接 32 位系统库。同样,为了构建 64 位应用程序,必须有 64 位系统库。不过,在一个特定的操作系统中,即使提供了 64 位系统库,也不一定意味着这个系统真正可以运行 64 位应用程序。这种情况对于 32 位 Windows® 操作系统更是常见,在 32 位 Windows 上,虽然有些 64 位应用程序不能运行,但是可以编译和链接它们。对于 UNIX 平台也是如此,因为在某些情况下,您可以在 32 位的硬件上安装带 64 位支持的操作系统,还有一些情况下,32 位内核不能运行 64 位应用程序。实际上,可以把 32 位操作系统看作只能运行 32 位应用程序的操作系统,尽管 64 位操作系统也能运行 64 位应用程序,但需要使用 64 位硬件,而且可能还需要使用 64 位操作系统内核。

32 位和 64 位应用程序

32 位应用程序是按照内存地址的大小为 32 位(4 个字节)来编译的。这些应用程序可以直接使用至多 4 GB 的虚拟内存 —— 即一台计算机上可以提供的潜在内存。不管系统上可用于操作系统和其他应用程序之间共享的实际内存(RAM)有多少,这一虚拟内存限制始终存在。另一方面, 64 位应用程序按照内存为 64 位(8 个字节)来编译,可以使用多于 4 GB 的虚拟内存,这不受限制。操作系统通常还会对应用程序施加更多的虚拟内存限制,因此,虽然应用程序具有 32 位的寻址能力,但理论上每个应用程序的最大虚拟内存可能只有 1-2 GB。

当您在 32 位或 64 位平台上编译应用程序时,默认情况下应用程序被编译为在某种特定平台上运行。通过使用特殊的特定于编译器的编译选项,并适当地链接到合适的 32 位或 64 位库,也可以在带有某些编译器的 32 位操作系统上创建 64 位应用程序,或者在 64 位操作系统上创建 32 位应用程序。

32 位应用程序通常可以同时在 32 位和 64 位操作系统上运行,不过在很多采用 32 位内核的操作系统上不能运行 64 位应用程序。

DB2 32 位和 64 位对象概述

从 DB2 的角度来看,当然也存在 32 位和 64 位的 DB2 对象。32 位和 64 位 DB2 实例就是其中的一个例子。您可以在 32 位或 64 位操作系统上创建 32 位 DB2 实例,但是只能在 64 位操作系统上创建 64 位 DB2 实例。有些混合 32 位和 64 位操作系统,例如 AIX Version 5.1,便支持这两种类型的 DB2 实例。同一个数据库服务器上可以存在多个 DB2 实例,以服务不同的用户需求测试实例与生成实例),并且不一定要有相同的位数。

DB2 应用程序可以同时在具有大多数编译器的 32 位和 64 位 DB2 实例中创建为 32 位或 64 位的对象,但是为了得到应有的功能,必须将 32 位或 64 位 DB2 应用程序分别链接到 DB2 的 32 位和 64 位库,两种 DB2 实例都提供了这样的库。

32 位 DB2 外部例程是在被调用时装载和运行 32 位外部库的 DB2 外部例程(过程,用户定义函数)。在调用 64 位外部例程时,则装载和运行 64 位外部库。

对 32 位和 64 位对象之间的关系有了基本的理解之后,就更容易明白必须如何管理 DB2 应用程序开发实践,以便系统可以支持 32 位和 64 位应用程序的开发和部署。

第 II 部分:DB2 32 位和 64 位应用程序和例程支持

就 32 位和 64 位跨平台开发而言,DB2 UDB 确实是一种通用的数据库。没有哪种数据库像 DB2 那样,为在如此多的平台上开发和部署应用程序提供了如此多的支持。谈到 32 位和 64 位应用程序的开发支持,DB2 走在了前列。下面的小节将介绍 DB2 的关键 32 位和 64 位平台和应用程序开发支持。

受支持的 32 位和 64 位 DB2 UDB 产品

下面的 Linux、UNIX 和 Windows 平台上的 DB2 Universal Database 产品在 32 位和 64 位平台上都可以使用:

表 1. DB2 受支持的 32 位和 64 位软件

clearcase/" target="_blank" >cc33>DB2 产品
DB2 UDB Express Edition
DB2 UDB Personal Edition
DB2 UDB Personal Developer’s Edition
DB2 UDB Developer’s Edition
DB2 UDB Workgroup Server Edition
DB2 UDB Workgroup Server Unlimited Edition
DB2 UDB Enterprise Server Edition

您可以使用 Personal Developer’s Edition 或任何其他产品开发数据库应用程序,前提是在客户机上安装了 DB2 Application Development Client。

要了解更多关于 DB2 产品、扩展器、工具以及其他信息管理软件产品的信息,请参阅 http://www.ibm.com/software/data/db2/udb。

受支持的 32 位和 64 位平台

一旦确定了哪种 DB2 产品能满足您的需要,就必须为数据库系统选择硬件。下面的表列出了可用作 DB2 数据库服务器或 DB2 客户机的受支持的 32 位和 64 位平台。.

表 2. 受支持的平台

32 位平台 64 位平台 混合平台
AIX AIX AIX hybrid (5.1)
HP PARSIC HP PARSIC
HP IPF HP IPF
Linux Intel 32 位 Linux AMD
Linux PPC Linux EMt64
Linux zSeries Linux Itanium 64 位 (IA64)
Solaris Linux PPC
Windows 32 位 Linux zSeries
Solaris
Windows IA64

有很多因素可能影响对用于开发和测试系统或生产系统的平台的选择。通常,这种决定最终归结为价格、性能、可伸缩性和可靠性。当需要为了数据库服务器在 32 位或 64 位硬件平台作出选择时,应该考虑使用 64 位平台的以下优点:

  • 可以有更多的内存用于构建和运行更大的应用程序。
  • 更有效的数据处理和更好的应用程序性能。

通常,生产系统的效率对于数据管理策略的成功十分关键,这就是为什么常常在生产系统中使用更快的 64 位硬件作为数据库服务器的原因。

如果单独运行开发、测试和生产系统,那么显然当开发和生产系统在相同的平台上,或者至少运行相同的操作系统时,应用程序的部署是最容易的。

DB2 32 位和 64 位数据库连接支持

您可以混合和匹配选作 DB2 数据库客户机和服务器的平台,因为 DB2 支持从 32 位和 64 位客户机到数据库服务器的本地和远程连接。

本地数据库连接用于将 DB2 客户机或客户机应用程序连接到与客户机驻留在同一台计算机上的 DB2 数据库服务器,而不需要网络协议。另一方面,远程数据库连接是连接到驻留在不同计算机上的 DB2 数据库服务器,因而需要 TCPIP 之类的网络协议。下面的表展示了 DB2 对 32 位和 64 位客户机与 32 位和 64 位 DB2 数据库服务器之间本地和远程连接的全部支持。

表 3. DB2 对从 32 位和 64 位客户机到 32 位和 64 位服务器的支持

DB2 客户机 32 位 DB2 服务器(本地和远程) 64 位 DB2 服务器(本地和远程)
32 位客户机 支持 支持 (1)
64 位客户机 支持 支持

如果 DB2 客户机和 DB2 数据库服务器在不同类型的平台上,那么这种广泛的支持是一个重要特性。这还意味着 32 位和 64 位应用程序可以连接 32 位和 64 位数据库服务器上的数据库并与这些数据库通信。

要获得对 DB2 受支持的 32 位和 64 位硬件以及用于 DB2 Versions 7 和 8 的客户机-服务器配置的详细描述,请参阅主题 “Supported and non-supported client configurations”,在 DB2 Quick Beginnings Guide (PDF) 和 Information Center (HTML) 中都可以找到这个主题。

DB2 的 32 位和 64 位客户机应用程序支持

DB2 支持用于各个受支持平台的多种编译器、解释器和相关开发软件。您可以在 32 位或 64 位 DB2 实例中的任何一种 DB2 实例中构建 DB2 32 位和 64 位应用程序,只要该 DB2 实例中带有前面提到的差不多所有 DB2 都支持的编译器,这些编译器提供了 32 位和 64 位应用程序编译支持。

在开始编写应用程序之前,应确认您所想要的编译器或开发软件能够支持 32 位和 64 位应用程序的开发需要。要获得关于用于各种硬件平台的 DB2 受支持的开发软件的详细描述,请参阅主题 “Supported development software”,在 DB2 Application Development Guide: Building and Running Applications (PDF) 和 Information Center (HTML) 中都可以找到这个主题。

在构建和链接 32 位或 64 位 DB2 应用程序之前,最好要确切地知道将来可以在哪里运行这些应用程序。下面的表展示了可以在其上运行 DB2 32 位和 64 位客户机应用程序的硬件和操作系统,这里假设这些应用程序被正确地编译和链接:

表 4. DB2 对于 32 位和 64 位平台上 32 位和 64 位应用程序的运行时支持

客户机应用程序 32 位硬件 + 操作系统,带有 32 位 DB2 实例 64 位硬件 + 操作系统,带有 32 位或 64 位 DB2 实例
32 位客户机应用程序 支持 支持 (1)
64 位客户机应用程序 不支持 支持

(1) Windows 32 位应用程序可以在 Windows 64 位平台上运行,而不需要对环境作任何改变。在 UNIX 上,通过重新绑定应用程序并以适当的库路径设置运行应用程序,便可以将已有的 32 位应用程序部署到所有 64 位平台上,只有 Linux IA64 和 Linux for zSeries® 例外。

关于如何正确地构建、链接和链接要部署到不同平台的应用程序的建议,将在本文的 第 III 部分 中详细讨论。

DB2 的 32 位和 64 位例程支持

例程(存储过程、UDF 和方法)不同于应用程序。例程 – 封装了数据库和编程逻辑的数据库对象 - 运行在数据库服务器上,是通过执行特定于例程的 CREATE 语句创建的,该语句定义了例程的一些特征。

SQL 例程支持

对于 DB2 Version 8.2,SQL 过程定义像 SQL 函数、表、触发器和其他数据库对象定义一样,完全保存在数据库中。SQL 过程不再与任何驻留在数据库服务器上的可执行代码产生关联,这意味着不存在与 SQL 例程的创建、调用、部署或迁移有关联的 32 位或 64 位相关因素。

外部例程支持

外部例程的例程体是以一种编程语言编写的,它被编译成一个库,当例程被调用时,就要装载并运行这个库。在 CREATE 语句中有两个子句用于外部例程,它们是 FENCED 和 NOT FENCED,这两个子句将决定外部例程是在一个不同于数据库管理器的 fenced 环境中运行,还是在与数据库管理器相同的寻址空间中运行。通常,unfenced 例程比 fenced 例程执行起来要更好一些,因为它们通过共享内存与数据库管理器通信,而不是通过 TCPIP 通信。默认情况下,不管 CREATE 语句中使用了哪些其他的子句,例程总是被创建为 fenced 例程。

下面的表说明了 DB2 对在运行相同操作系统的 32 位和 64 位数据库服务器上运行 fenced 和 unfenced 32 位和 64 位例程的支持:

表 5. DB2 对在 32 位和 64 位服务器上运行过程和 UDF 的支持

例程类型 32 位服务器 64 位服务器
32 位 fenced 过程或 UDF 支持 支持 (1)(2)(3)
64 位 fenced 过程或 UDF 不支持(4) 支持
32 位 unfenced 过程或 UDF 支持 不支持 (2)
64 位 unfenced 过程或 UDF 不支持 (4) 支持

(1) 在 64 位服务器上运行 32 位例程不如在 64 位服务器上运行 64 位例程那么快。
(2) 32 位例程必须创建为 FENCED 和 NOT THREADSAFE 才能在 64 位服务器上运行。
(3) 在 Linux IA 64 位数据库服务器上不能调用 32 位例程。
(4) 64 位应用程序和例程不能在 32 位寻找空间中运行。

在表 5 中要注意的重要一点是,32 位 unfenced 过程不能在 64 位 DB2 服务器上运行。如果必须将 32 位 unfenced 例程部署到 64 位平台,那么应该在编目这些例程之前将 NOT FENCED 子句从用于这些例程的 CREATE 语句中去掉。

32 位和 64 位外部例程解析

当执行引用例程的 SQL 语句(例如用于调用过程的 CALL 语句或者可以在 select 列表中包含列函数的 SELECT 查询)时,DB2 根据 DB2 系统编目表中的例程定义解析例程引用,并在 SQL 语句的执行过程中调用例程。

当调用外部例程时,DB2 根据名称在数据库服务器上找到例程的外部类或库文件,然后装载并运行外部类或库文件。在 32 位平台上,外部例程总是作为 32 位对象来装载和运行。在 64 位平台上,出于性能考虑,DB2 假设例程调用的目标库是 64 位的对象。因此,DB2 首先尝试作为 64 位的对象来执行例程的外部库或类。如果不行的话,DB2 便自动尝试作为 32 位 fenced 例程库来装载和运行该库。

如果在数据库服务器的文件系统中同时具有一个例程的库或类的 32 位和 64 位版本,那么为了得到最佳性能,应该确保该例程的 CREATE 语句标识了正确的外部库或类文件,而不是让 DB2 去搜索正确的版本来运行。

要了解关于例程解析和调用的更多信息,请参阅 Routine invocation —— 一个 IBM DB2 文档主题。

64 位数据库服务器上 32 位外部例程的性能

由于对实现外部例程的选择常常基于提高客户机应用程序性能的需要,因此从外部例程中获得最大性能通常被优先考虑。在 64 位数据库服务器上,外部例程的性能部分上是由外部例程是装载 32 位还是 64 位外部例程库来决定的。

除了 Java™ 例程以外,在 64 位服务器上调用 32 位例程在性能上不如在 64 位服务器上调用 64 位例程,因为出于性能考虑,DB2 首先尝试将例程当作 64 位对象来执行,然后才尝试将例程作为 32 位对象来执行,而后者要求特殊的 32 位 fenced 模式处理。对于单独的 32 位例程调用,其开销显得微不足道,但是当这个例程被调用很多次时,开销就变得比较显著了。如果您关心性能的话,那么建议您重新构建(编译、绑定和链接)例程源代码来创建 64 位例程库。




  

原文转自:http://www.ltesting.net