理解 DB2 UDB JDBC 通用驱动程序：内部人士指南

核心提示：简介在 DB2 环境中的 Java 开发的演变过程中，最近的动向是 DB2 UDB JDBC 通用驱动程序，理解 DB2 UDB JDBC 通用驱动程序：内部人士指南，这种新的驱动程序提供了很多优点和改进，使它成为应用程序开发的最佳选择，更深入地理解 DB2 UDB JDBC 通用驱动程序，可以让您在 DB2 环境中进

简介

在 DB2 环境中的 Java 开发的演变过程中，最近的动向是 DB2 UDB JDBC 通用驱动程序。这种新的驱动程序提供了很多优点和改进，使它成为应用程序开发的最佳选择。在本文中，您将理解这种驱动程序的内部工作原理，并看它怎样匹配您的整个应用程序开发计划。

首先让我们来比较现有的两种驱动程序：

旧的 CLI 驱动程序

新的 JDBC 通用驱动程序

在第一节中，我们主要通过以下几个话题来展示这两种驱动程序之间的不同之处：

安装

连接

驱动程序初始化

特性

错误处理

事务管理

第二节将讨论问题诊断和对跟踪的分析。要理解如何做这件事，需要了解 SQLException，以及它与 JDBC 有怎样的关联。对于新的 JDBC 通用驱动程序，我们将讲解如何进行 JCC 跟踪，以及进行 JCC 跟踪时需要些什么。完成跟踪后，我们将深入了解跟踪由哪些部分组成，以及如何使用跟踪来帮助找到问题的根源。

旧的 JDBC 驱动程序与新的通用 JDBC 驱动程序的比较

要理解我们对 DB2 通用驱动程序的开发的讨论，需要理解 JDBC 规范如何定义用于 Java 的不同类型的驱动程序。

Type 1 驱动程序：

这类驱动程序的代码直接与高级本机 API 形成映射。JDBC 和 ODBC 是类似的 API，所以这种驱动程序常常与 JDBC-ODBC 桥联系在一起。

这类驱动程序与 DB2 UDB 产品没有太多的关联。

Type 2 驱动程序：

T2 驱动程序中有一个本机组件，该组件是驱动程序的一部分，但与数据访问 API 相分离。

这个本机组件和 Java 组件一起构成驱动程序。

对于 DB2 UDB，DB2 CLI 库包含本机组件。

Type 3 驱动程序：

这是一个 Java 客户机，使用独立于数据库的协议进行通信。

由于这种协议是独立于数据库的，这个优点使之适合于作为异构后端服务器的网关的中间件服务器。

Type 4 驱动程序：

这类驱动程序是纯 Java 的，它实现了用于特定数据源的网络协议。

客户机直接连接到数据源。

谈到 DB2 UDB，您只需关心 Type 2、3 和 4 驱动程序。有了前面介绍的知识，现在可以看看关于 Type 2 和 Type 4 驱动程序的一些专门信息，并考察在应用程序开发中使用 Type 4 驱动程序的优点。让我们来看旧的 CLI Type 2 驱动程序与 Type 4 通用 JDBC 驱动程序之间的比较。

安装

连接

驱动程序初始化

特性

错误处理

事务管理

安装

DB2 JDBC 支持包含在 DB2 UDB 客户机和服务器的 Java enablement 选项中。不需要专门安装 DB2 JDBC 驱动程序，您只需确保下载了适合于平台的 Java 开发工具箱（JDK）。DB2 Information Center 包含关于如何在 UNIX 和 Windows 上为 Java 设置环境的详细信息。

表 1. 安装比较

旧的 CLI 驱动程序	通用驱动程序
旧的 CLI 驱动程序的物理表示是 db2java.zip 文件。	通用 JDBC 驱动程序的物理表示是 db2jcc.jar 文件。
在 UNIX 环境中，只需在 CLASSPATH 中有 sqllib/java/db2java.zip，就可以使用旧的 Type 2 驱动程序。在 Windows 上也是如此。	在 UNIX 环境中，只需在 CLASSPATH 中有 db2jcc_license_cu.jar 和 sqllib/java/db2jcc.jar，就可以使用 Type 4 通用驱动程序。在 Windows 上也是如此。
支持这类驱动程序的有 JDBC 2.0 和部分 JDBC 3.0。	支持这类驱动程序的是大多数 JDBC 3.0 实现，只要安装了 JDK1.4.x 作为 Java 包的一部分，就提供了对这类驱动程序的支持。

连接

这两类驱动程序的不同之处表现在它们建立连接的方式上。JDBC 的基本功能是连接到数据库，并发送 SQL 语句到服务器。它能够处理结果集，并将其发送给请求者。

表 2. 连接比较

旧的 CLI 驱动程序	通用驱动程序
到数据库的连接是通过一个本机数据库接口进行的。在这里，DB2 使用 CLI。JDBC 层位于 CLI 之上，CLI 是与数据库服务器通信的本机组件。	一切都是纯 Java 的，与数据库的通信通过网络通信完成。DB2 UDB 使用分布式关系数据库架构（DRDA）来与服务器进行通信，并将请求传递给数据库服务器。
由于旧的 CLI 驱动程序需要公共客户机代码，所以它还需要一个 DLL/共享对象。为了使用这类驱动程序，必须安装 DB2 产品。	这是一种纯 Java 的驱动程序，所以可独立于它所在机器上安装的产品而运行。也就是说，可以将它看作一个单独的实体，它是独立于附带它的那个 DB2 产品的。

驱动程序初始化

在使用不同的驱动程序时，用于装载该驱动程序的代码也会有所不同。有两种建立连接的方式。和所有 JDBC 资源一样，在使用完连接时，要调用连接关闭方法。

表 3. 驱动程序初始化比较

旧的 CLI 驱动程序	通用驱动程序
为装载驱动程序和建立连接，需要三个基本步骤： 导入 JDBC 核心类（例如 import java.sql*）。 装载 JDBC 驱动程序 Class.forName (COM.ibm.db2.jdbc.app.DB2Driver)。 指定连接 URL: DriverManager getConnection jdbc:db2:coffebk。	通用驱动程序支持通过单个 driver.h 网络通信的 Type 2 和 Type 4 连接。DB2 UDB 使用分布式关系数据库架构（DRDA）来与服务器进行通信，并将请求传递给数据库服务器。 所使用的是 Type 2 还是 Type 4 驱动程序，是通过连接的形式来指定的。下面的连接形式表明使用的是 Type 2 还是 Type 4 驱动程序： jdbc:db2//server:port/database jdbc:db2//server/database 下面的连接形式意味着使用的驱动程序是 Type 2 驱动程序： jdbc:db2:database
如果愿意，也可以使用 Type 3 驱动程序，在这种情况下，驱动程序的初始化就是： COM.ibm.db2.jdbc.net.DB2Driver	可以通过所使用的连接级别在这两类驱动程序的物质层之间进行切换。

特性

随着 DB2 UDB, Version 8 的出现，Java 开发变得更加强大，而且编程工作也更具有独立性。现在，开发过程中的大部分精力都集中在添加新特性、改善新的 JDBC 通用驱动程序的内存管理和稳定性上。

表 4. 特性比较

旧的 CLI 驱动程序	通用驱动程序
这类驱动程序需要专门安装 DB2 UDB 产品，因为它依赖于该产品的本机代码。	这类驱动程序可以看作一个独立的产品。不需要安装产品，因为可以随很多 DB2 平台一起提供它。
旧的驱动程序版本是和 DB2 UDB 修复包相对应的，只能随一个修复包一起发布。	JCC 驱动程序的发布独立于修复包。JCC 驱动程序有它们自己的版本，它们是根据 DB2 产品不同发行版的需要发布的。例如，DB2 V8.20 fp9 可能附带 2.3.9 版的 JCC 驱动程序，而 DB2 V8.20 OS/390 PTF UQ72081 可能附带 2.3.11 版的 JCC 驱动程序。

错误处理

这两类 JDBC 驱动程序处理错误的方式大相径庭。新驱动程序的错误消息仍在开发中，但是对于通用驱动程序而言，版本越新，其错误处理功能越好。典型的 JDBC 异常通常由 SQLErrorCode、SQLState 和 SQLMessage 组成。

表 5. 错误处理比较

旧的 CLI 驱动程序	通用驱动程序
旧的驱动程序从 DB2 产品获得错误消息，然后将整个错误消息传递给应用程序。	通用驱动程序不会重新创建由旧的 CLI/JDBC 产品发出的、预先存在的 SQL 错误代码。通用驱动程序有它自己定义的错误代码，其范围为 +/-4200 和 +/-4299。
	由通用驱动程序发出的未定义的错误代码被指定为 -99999。
	如果收到来自一个 DB2 子系统（例如底层 DB2 客户机库的 DB2 服务器）的错误，那么 JCC 只是回显那条错误消息。

事务管理

事务是一条或多条语句的集合，这些语句作为一个工作单元（UOW）一起执行。使用事务是为了确保一个 UOW 中的所有处理要么一起执行，要么都不执行。对于这些驱动程序，J2EE 指定了简单的事务管理。

表 6. 事务管理

旧的 CLI 驱动程序	通用驱动程序
对于这类驱动程序，很早就已经提供了 XA 支持。	从 V8.20 开始，Type 4 JDBC 通用驱动程序有了 XA 支持。

诊断问题和分析跟踪

JDBC 跟踪的组成

在 DB2 中，无论何时收到任何类型的异常，接下来的一步就是找出那个错误的来源。在大多数情况下，要找出错误的起因，需要进行某种类型的跟踪，以便通过跟踪来揭示导致错误的调用序列。

让我们来看看在 Java 中导致错误的调用序列，并研究在通常的 Java 应用程序中处理错误的机制。

图 1. Java 运行时环境

在 图 1 中可以看到，Java 运行时环境（JRE）包含用 Java 实现的错误处理机制。JRE 就像汽车中的引擎一样，使所有组件能够运行起来。

各组件可以由实际代码来表示，这些用 Java 编写的代码总是包含 try( ) 和 catch( ) 这两个代码块。每当实际代码碰到任何类型的错误，它就抛出一个异常，然后该异常就进入调用栈。调用栈将异常传递给 catch( ) 块，异常正是通过这种方式被返回给用户的。

为了允许 JDBC 程序抛出 SQLException，在技术实现上要确保程序能访问 com.ibm.db2.jcc.DB2Diagnosable 接口和 com.ibm.db2.jcc.DB2Sqlca 类。可以使用它们的完全限定引用，也可以导入它们：

import　com.ibm.db2.jcc.DB2Diagnosable;　
import　com.ibm.db2.jcc.DB2Sqlca　

SQLException 的组成

让我们来看看 SQLException() 类的一些细节，并弄清这个类的组成部分。总可以看到以下几个部分：

SQLException(　
Description　of　the　error:　null,　string　
SQL　State:　null,　string　
Error　code:　int　value　
Next　SQLException:　null　or　pointer　
)　

通常可以通过调用 next SQLException 来返回链中的下一个异常。如果没有要返回的其他错误消息，则返回 null。

必要的存储过程

如果要使用通用 JDBC 驱动程序并连接到 OS/390，那么需要确保在主机上有一些必要的存储过程，这些存储过程将确保跟踪得以进行：

SQLCOLPRIVILEGES

SQLCOLUMNS

SQLFOREIGNKEYS

SQLGETTYPEINFO

SQLPRIMARYKEYS

SQLPROCEDURECOLS

SQLPROCEDURES

SQLSPECIALCOLUMNS

SQLSTATISTICS

SQLTABLEPRIVILEGES

SQLTABLES

SQLUDTS

SQLCAMESSAGE

这些存储过程是版本 6 的 PTF 附带的。需要 UQ72081 和 UQ72082。对于版本 7，PTF 号被定义为 UQ72083。如果需要关于如何安装这些 PTF 的具体信息，请参考 DB2 Information Center for z/OS，在那里可以获得详细的信息。

JCC 跟踪：概述

目前，JCC 驱动程序在跟踪和诊断问题方面的功能还不足以深入地诊断问题。目前的跟踪集还非常不稳定，主要是用于初步的分析。将来版本的 JCC 驱动程序将使跟踪功能更适合于问题诊断，并且更加面向问题。然而，JCC 跟踪中还是有几个关键的地方值得我们在后面加以讨论，它们有助于缩小问题的范围。

JCC 跟踪的实现有两种不同的方式，在接下来的两节中将详细讨论这两种方式。

如果您曾经见过 DRDA 格式的 DB2 跟踪，那么 JCC 跟踪看上去会非常熟悉。我们从 DRDA 跟踪中获取缓冲区，然后将它们放入实际的 JCC 跟踪中。别忘了，JCC 使用 DRDA 来与服务器进行通信。

如何进行 DB2 通用 JDBC 驱动程序跟踪

在跟踪一个 JCC 问题时，可以采取两种方法。根据环境的不同，可以使用以下两种方法之一：

把它作为一个独立的 JCC 应用程序来跟踪

在 WebSphere 中，嵌入 JCC 跟踪点

把 JCC 作为独立应用程序来跟踪

当把 JCC 组件作为独立应用程序来跟踪时，需要考虑与 DB2 通用 JDBC 驱动程序之间存在的连接的类型。

DataSource 接口
当为 JCC 连接使用数据源接口时，有两种方式来启用跟踪：

DB2DataSource > setTraceLevel > default TRACE_ALL

-javax.sql.DataSource.setLogWriter > TRACE_ALL only available

对于任何跟踪选项，除了 TRACE_ALL 属性外，还可以使用其他跟踪参数。根据所跟踪内容的不同，可以让 JCC 跟踪功能只跟踪以下属性：

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_NONE

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTION_CALLS

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_STATEMENT_CALLS

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_RESULT_SET_CALLS

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRIVER_CONFIGURATION

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTS

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRDA_FLOWS

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_RESULT_SET_META_DATA

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_PARAMETER_META_DATA

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DIAGNOSTICS

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_SQLJ

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_XA_CALLS （仅适用于 Universal Type 2 Connectivity for DB2 UDB for Linux、UNIX 和 Windows）

com.ibm.db2.jcc.DB2BaseDataSource.TRACE_ALL

如果想跟踪不止一个特定的 traceLevel 属性，那么可以使用位操作符（|）来分隔不同的属性。通常，如果不知道想跟踪哪个特定的组件，那么最好使用缺省属性，即 TRACE_ALL。实际上，在大多数情况下，只需要知道这么多。但是如果需要更详细地规定跟踪某些 JDBC 通用驱动程序组件，那么可以通过位操作符来做到这一点。

另外提醒一点，如果想跟踪除了某个组件之外的所有组件，还可以使用另一个位操作符。这个位操作符就是（~）。

DriverManager
进行跟踪的第二种方法是使用连接的 DriverManager 接口，可以通过以下两种方法之一来打开跟踪：

DriverManager.getConnection
设置 info 参数或 URL 参数中的 traceLevel 属性。

DriverManager.setLogWriter
当使用这种方法打开跟踪时，可以指定跟踪目标，然后打开跟踪。下面是关于如何做到这一点的一个好例子：

清单 1. 使用 DriverManager.setLogWriter 的示例代码清单
//　The　traceLevel　property　is　established　through　the　URL　syntax,　
//　and　driver　tracing　is　directed　to　file　"/temp/driverLog.txt"　
String　databaseURL　=　
"jdbc:db2://sysmvs1.stl.ibm.com:5021"　+　
"/sample:traceFile=/temp/driverLog.txt;traceLevel="　+　
"(com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRDA_FLOWS　"　+　
"|　com.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTS);";　

还有一种方法也可以进行 JCC 跟踪，这种方法不用修改应用程序。 如果在客户机上创建一个名为 DB2JccConfiguration.properties 的文本文件，该文件中只有一行文本：
db2.jcc.override.traceFile=c:\jcc.trc
然后将该文件添加到 CLASSPATH 中，那么 JCC 跟踪将被自动启用。在不能更改任何源代码或 JCC 驱动程序属性的时候（例如，使用在内部使用 JCC 驱动程序的第三方产品），这种方法非常有用。请参考 DB2 Information Center 中的以下链接，以获得更详细的信息：
http://publib.boulder.ibm.com/infocenter/db2help/topic/com.ibm.db2.udb.rn.doc/rn/r0012130.htm.

在 WebSphere 跟踪中嵌入 JCC 跟踪点

如果在 WebSphere 环境中碰到一个 DB2 通用 JDBC 问题，那么可以在 WebSphere 跟踪中嵌入 JCC 跟踪点。这样就可以很方便地知道 JCC 组件在 WebSphere 调用中所扮演的角色，从而可以清晰地了解应用程序中所发生的事情。

下面是在 WebSphere 跟踪中设置 JCC 跟踪点的步骤：

在 WebSphere Application Server 中为 JDBC 设置跟踪属性。
进入 Resources > JDBC Provider > Data Sources > Additional Properties > Custom Properties。
需要设置的属性是：
traceLevel（-1 表示完全跟踪 TRACE_ALL）

打开跟踪。
进入 Troubleshooting > Logs and Trace > pick the server > Diagnostic Trace > Trace Specification: RRA=all=enabled:WAS.database=all=enabled
注意，这里可以指定两个跟踪字符串，之间用 ‘:’ 隔开，一个用于 WebSphere Application Server 资源适配器，另一个用于数据库（JDBC 驱动程序）。

通过使 traceFileName 属性空白，就足以自动在 WebSphere 跟踪中嵌入 JCC 跟踪点。可以动态地启用和禁用这种跟踪，在缩小问题范围的时候这样做会有所帮助。

JDBC 通用驱动程序错误代码

JCC 驱动程序只能发出少数几种 DB2 通用驱动程序错误代码。如果错误代码是通用驱动程序还没有定义的，那么它将回显一个 -99999 错误代码。下面是 DB2 通用 JDBC 驱动程序当前可用错误代码的一个参考：

表 7. 错误代码

4200	在 XA 环境中，一个处在全局事务中的应用程序发出一个无效的提交或回滚
4498	出现故障转移或故障恢复，事务失败
4499	导致连接断开的严重错误
99999	DB2 通用 JDBC 驱动程序发出没有错误代码的错误

目前由 -99999 这个通用错误代码定义的错误代码大约有 2000 条。下一阶段的 JCC 产品将用 SQLSTATE 和 SQLCODE 来定义这些错误代码。

JCC 跟踪的组成

在使用 JCC 驱动程序时，无论碰到何种类型的问题，为了作进一步的诊断，通常的做法是进行一个 JCC 跟踪。前面已经给出了进行 JCC 跟踪时所采取的步骤。现在让我们来剖析一个 JCC 跟踪，看看如何通过分析跟踪和找出错误的来源来彻底把问题弄清楚。

图 2. JCC 跟踪

图片看不清楚？请点击这里查看原图（大图）。

现在，让我们将一个跟踪分成几个部分，看看哪些部分在需要查看该诊断工具的各组件时会有用。在跟踪头中可以发现一些重要信息，这些信息对于理解环境非常有用。下面的编号对应 图 2 中的数字。

1. 所使用的 DB2 通用 JDBC 驱动程序版本
实际驱动程序版本是独立于修复包版本的。在 Java 应用程序开发支持页面上有一个详细的对照表，其中说明了每个 DB2 UDB 修复包所附带的 JCC 驱动程序的版本。

了解所使用的 JCC 驱动程序版本的另一种方法是在命令行中发出命令 db2jcc -version，该命令将显示当前使用的驱动程序的版本。

2. JDK 级别
表明和该 JCC 驱动程序一起使用的 Java 开发工具箱的版本。尽量使之与所使用的相应修复包保持同步。

跟踪头中包含的其他重要信息有：

操作系统的级别

路径信息

获得最新版本的 DB2 通用 JDBC 驱动程序的最好方法是下载最近用于 DB2 UDB for Linux、Unix 和 Windows 的修复包。

之所以要为 JDBC 驱动程序和相应的修复包使用不同的版本控制系统，是为了允许在所有 DB2 平台（包括 zSeries®、iSeries™ 等）上发布同一个驱动程序。这个驱动程序在所有 DB2 平台上是一致的。

现在让我们来看看 JCC 跟踪的主体，并试着将一些关键的元素拼接起来。

3. 跟踪标记
通过查看 JCC 跟踪中的标记，总可以确定所使用的通用驱动程序是 Type 4 风格的还是 Type 2 风格的：

[ibm][db2][jcc][t4] = 表明所使用的是 type 4 版本的驱动程序。

[ibm][db2][jcc][t2] = 表明所使用的是 type 2 版本的驱动程序。

4. DRDA 缓冲区
由于 JCC 规范是建立在 DRDA 协议之上的，我们将 DRDA 缓冲区嵌入在 JCC 跟踪中。这些缓冲区包含诸如 PreparedStatement 对象或 ResultSet 对象之类的项。如果熟悉 DB2 跟踪中常见的 DRDA 缓冲区，那么 JCC 跟踪中的 DRDA 缓冲区的感观看上去会很熟悉。如果在查看 DRDA 信息时有些迷惑，那么可以抓住关键的一点，那就是要执行的 SQL 语句。这条语句应该就嵌入在缓冲区中，并和 DB2 通用驱动程序将它发送到服务器进行处理时是一样的。

5. 使用的方法
如果您知道导致发生问题的 Java 方法，或者想在跟踪中看看一个特定的方法是如何使用的，那么可以从 JCC 跟踪中找到它。

如果您知道一个特定的语句或方法正在导致问题，那么总可以在 JCC 跟踪中搜索它，然后再对它进行上下搜索，从而发现任何值得怀疑的行为或错误消息，通过它们就可能找到能指示出问题所在的线索。

如果对错误感到没把握，那么可以从 DB2 UDB Technical Support 站点开始着手。

现在让我们来看一个有问题的跟踪的例子，该跟踪显示一个 -4499 错误，这是由 DB2 通用 JDBC 驱动程序定义的一个错误代码。

通常，当碰到任何与通用 JDBC 驱动程序有关的问题时，都将以某种类型的异常的形式来报告这个问题。

图 3. 跟踪例子

图片看不清楚？请点击这里查看原图（大图）。

从上面的跟踪中可以看到 -4499 这个返回代码。异常中还显示了通信错误，可以看到，在这种特定情况下，这就是要返回给应用程序的内容。

一个很好的技巧就是上下搜索这个异常，掌握在实际应用程序中所发生的情况。通过搜索发现这是否是与驱动程序有关的缺陷，如果是，那么试着使用最新版本的 JCC 驱动程序，在最新版本中这个问题可能已经被修复了。

结束语

通过比较基于 CLI 的旧 JDBC 驱动程序和新的 JDBC 通用驱动程序，我们看到，使用纯 Java 的 type 4 驱动程序有很多优点。通过进一步理解通用 JDBC 驱动程序所使用的跟踪，以及在进行跟踪时应搜索什么东西，可以帮助您解决在使用 JCC 驱动程序时可能碰到的任何问题。总而言之，更深入地理解 DB2 UDB JDBC 通用驱动程序，可以让您在 DB2 环境中进行下一阶段的 JDBC 应用程序开发时，在能力的提高上走得更远。