DB2的JDBC连接驱动和URL总结

DB2的JDBC连接驱动和URL总结

2009-03-30 13:41

DB2 和 JDBC 支持
依照 JDBC 规范，有四种类型的 JDBC 驱动程式体系结构
DB2 和 JDBC 支持
依照 JDBC 规范，有四种类型的 JDBC 驱动程式体系结构：

Type 1：这类驱动程式将 JDBC API 作为到另一个数据访问 API 的映射来实现，如开放式数据库连通性（Open Database Connectivity，ODBC）。这类驱动程式通常依赖本机库，这限制了其可移植性。JDBC-ODBC 桥驱动程式就是 Type 1 驱动程式的最常见的例子。

Type 2：这类驱动程式部分用 JAVA 编程语言编写，部分用本机代码编写。这些驱动程式使用特定于所连接数据源的本机客户端库。同样，由于使用本机代码，所以其可移植性受到限制。

Type 3：这类驱动程式使用纯 JAVA 客户机，并使用独立于数据库的协议和中间件服务器通信，然后中间件服务器将客户机请求传给数据源。

Type 4：这类驱动程式是纯 JAVA，实现针对特定数据源的网络协议。客户机直接连接至数据源。
对于DB2 UDB V7.2来说，他不支持 Type 1 和 Type 4 的驱动程式，不过提供了分别支持 Type 2 和 Type 3 的驱动程式。
示例如下：
两种驱动程式均随产品安装由 db2java.zip 提供。

COM.ibm.db2.jdbc.app.DB2Driver
这是一种 Type 2 的 JDBC 驱动程式，他通过 DB2 本地客户机库的帮助建立和 DB2本地数据库或是远程数据库的连接（事先将远程数据库编目到本地）。因此，我们必须在应用系统所在的机器上同时部署 DB2 本地客户机库，这也许是他最大的一个不足之处。
使用格式如下：
Driver Name：COM.ibm.db2.jdbc.app.DB2Driver
URL Pattern：jdbc:db2:databasename
databasename: 需要访问的数据库名

COM.ibm.db2.jdbc.net.DB2Driver
这是一种 Type 3 的 JDBC 驱动程式，他通过和一台已部署了 DB2 本地客户机库的机器通信来建立和 DB2 远程数据库的连接。
使用格式如下：
Driver Name：COM.ibm.db2.jdbc.net.DB2Driver
URL Pattern：jdbc:db2:ServerIP:databasename
ServerIP: 需要访问的数据库所在机器IP地址
databasename: 需要访问的数据库名
（目标DB2系统侦听该服务于默认端口6789，否则还需要在 URL Pattern 中指定目标端口号）
对于 DB2 UDB V8.1 来说，他仍然不支持 Type 1 的驱动程式。同时，他在 DB2 UDB V8.1的基础上，新增加了对 Type 4 驱动程式的支持。
示例如下：
DB2 UDB V8.1 仍然支持上面所述 V7.2 支持的两种驱动程式，随产品安装由 db2java.zip 提供，但具体实现上和 DB2 UDB V7.2 产品发布的包有所不同，所以可能存在下文所要进行实验验证的兼容性问题。
除了 COM.ibm.db2.jdbc.app.DB2Driver 之外，DB2 UDB V8.1 还提供了另外一种 Type 2 的驱动程式，随产品安装由 db2jcc.jar 提供。其实现包名是 com.ibm.db2.jcc.DB2Driver，在DB2 UDB V8.1 最初的实现中，此驱动程式只用于使用 Type 4 驱动程式体系结构和 DB2 服务器进行直接的 JAVA 连接，这类驱动程式由于不必另外部署 DB2 本地客户机库及性能相对较好而收到研发人员的欢迎。自从 DB2 UDB V8.1.2（安装了 FixPack 2）之后，研发人员还能在 Type 2 体系结构中使用该驱动程式，以提高本地应用程式的性能。
这里，两种驱动程式具有相同的实现类名称，有两种不同的方法能区分 DB2 系统在内部最终会实例化哪个驱动程式：

使用不同的 URL Pattern 来区分两种不同的驱动程式
Type 2 Driver URL Pattern：jdbc:db2:databasename
这当中 databasename 是需要访问的数据库名
Type 4 Driver URL Pattern：jdbc:db2://ServerIP:50000/databasename
这当中 ServerIP 是需要访问的数据库所在机器IP地址，databasename 是需要访问的数据库名，DB2 服务器会在默认端口 50000 上进行侦听。

使用连接特性来区分数据库连接是否会使用 DB2 本地客户机库，或是使用JAVA 直接连接。
DB2 UDB V8.1 新增加支持的这种 Type 4 驱动程式，常被称为“通用 JDBC 驱动程式”，是一种和驱动程式类型连通性或目标平台无关的抽象 JDBC 处理器，因此常用于进行分布式和本地 DB2 UDB 访问。因为“通用 JDBC 驱动程式”独立于所有特定 JDBC 驱动程式类型连通性或目标平台，所以他在一个 DB2 UDB 驱动程式实例中同时支持所有 JAVA 连通性（Type 4 驱动程式）和基于 JNI 的连通性（Type 2 驱动程式）。该驱动程式能用于独立 JAVA 应用程式或多层应用程式，是研发人员一个不错的选择。
兼容性实验
上文前后介绍了非常多种 DB2 系统支持的 JDBC 驱动程式，想必你的应用中已采用了其中的某一种或几种，而在迁移你的应用时你一定希望最佳不要更改原有的程式。这个需求能办到么？如果你的应用中所采用的驱动程式对不同版本的 DB2 系统进行连接的兼容性足够好，这个需求就一定能办到。那让我们带着这个疑问，来进行下面这个兼容性实验吧。
实验环境：
为了完成这个实验，我部署了两台机器，就分别命名为 Machine A 和 Machine B 吧。
Machine A 上部署了 DB2 UDB V7.2.7（安装了 FixPack 7），他可能和你应用环境中的旧版本 DB2 系统非常类似；Machine B 上我部署了 DB2 UDB V8.1.4（安装了 FixPack 4，这是目前公研发布的最新的补丁），这也许和你升级后的最新 DB2 系统相仿。
相应的，在两台机器上，我都安装了 DB2 命令行工具（CLP），DB2 控制中心（Control Center），DB2 命令中心（Command Center）等工具以便能够对 DB2 系统进行设置和监视。
实验中当需要编写代码的时候，我采用的工具是 WSAD V5.0（WebSphere Studio Application Developer），这是个不错的研发工具。
实验目的：
我们带着上文碰到的这个问题来做这个实验。因此，我们分别采用上文中提及的各种 JDBC驱动程式尝试建立和 DB2 本地数据库和远程数据库的连接。如果一切顺利，这还只是完成了实验第一步。假设建立数据库连接成功，我们会紧接着尝试对这个数据库进行各种操作，先是测试查询操作，这是最常见的数据库操作；然后会是插入，更新，删除等 DML 操作，他们会改动数据库中存储的数据。如果这些都没有问题的话，我们还需要继续尝试诸如新建，修改，删除数据表等 DDL 操作。
为了增强实验的比较效果和准确性，我们除了会编写代码来进行各种测试，还会使用 DB2 命令行工具（CLP）和 DB2 命令中心（图像化管理工具）来进行相同的操作，并且就运行结果进行比较。
明确了实验目的，下面就来开始我们的实验吧。
实验过程：
A：实验的第一步是测试 DB2 UDB 不同版本随产品发布的 JDBC 驱动程式对该版本自身的兼容性。
这里我先编写代码完成了各项测试目的，一切顺利。
然后，我使用 DB2 命令行工具（CLP）来重复这些测试。
能通过在命令行中键入 db2cmd 进入 DB2 CLP，然后在提示符下键入 db2，就会进入DB2 CLP 的交互界面。
如下图：


这个命令行工具能完成图像化工具所做的所有管理设置工作，并且能节省非常多内存资源。
实验中，我们首先需要用命令连接到一个数据库：  
示例如下，在命令行提示符后键入
CONNECT TO SAMPLEDBUSER db2adminUSING password
该命令表示使用用户名为 db2admin，密码为 password，连接至数据库 SAMPLEDB，紧接着会返回连接后的数据库相关信息。然后就能在命令行提示符后直接键入各种 DDL 或 DML 语句来执行各种操作。
最后，我们还能使用 DB2 UDB 随产品发布的一个图像化管理工具——命令中心（Command Center）来验证我们的实验。


能参照上图启动命令中心，其相关操作请参见产品文件。
B：这一步我们将测试 DB2 UDB 两个版本中随产品发布的 Type 2 JDBC 驱动程式连接和其本身不同版本的 DB2 UDB 系统时的兼容性。
在进行这步测试时，由于 Type 2 JDBC 驱动程式是针对本地数据库研发的，因此我们需要先将远程数据库编目（catalog）到本地，再尝试连接。下面先给出了采用 DB2 命令行工具编目远程数据库的例子。
远程数据库的相关信息示例如下：
目标数据库所在机器名：TESTSERVER
目标数据库所在机器 IP 地址：10.1.1.15
目标数据库所属实例名：TESTINSTANCE
目标数据库名：SAMPLEDB
目标数据库所在机器操作系统类型：WINDOWS

启动 DB2 命令行工具

在命令行提示符下键入命令：
CATALOG TCPIP NODE TESTSERVERREMOTE 10.1.1.15 SERVER 50000REMOTE_INSTANCE TESTINSTANCEOSTYPE WINDOWS
此命令将 TESTSERVER 这台机器及其中指定的数据库实例编目到本地

在命令行提示符下键入命令：
CATALOG DATABASE SAMPLEDBAT NODE TESTSERVER
此命令将样本数据库 SAMPLEDB 编目到本地

在命令行提示符下键入命令：
COMMIT 此命令将上面基本的修改提交给 DB2 系统使之生效。

在命令行提示符下键入命令：LIST DB DIRECTORY
通过这个命令你能查看所有本地的数据库及编目到本地的远程数据库的信息，以验证编目是否成功。
编目远程数据库之后，我们就能将其看作是本地数据库对其进行各种操作。（如果想进一步了解这些命令的更多内容，能参考 DB2 联机帮助）
这部分的测试结果比较有趣，在实验结果中会周详描述。
C：完成了上一步之后，我们已有了不少收获。在这一步中，我们测试了 DB2 UDB 两个版本中随产品发布的 Type 3 JDBC 驱动程式连接和其本身不同版本的 DB2 UDB 系统时的兼容性。
在这步当中，我们直接采用 COM.ibm.db2.jdbc.net.DB2Driver 这种网络 JDBC 驱动程式来尝试连接远程数据库，均以失败告终。这无论是编写代码测试，还是 DB2 命令行工具，或是 DB2 命令中心，都是令人沮丧的结果，因而这种方式不推荐大家使用。
D：最后这步也许是大家所最关心的，就是 DB2 UDB V8.1 新增支持的 Type 4 JDBC 驱动程式连接 DB2 UDB V7.2 时的兼容性（同时也支持Type 2 体系结构访问）。
这里我们将 DB2 UDB V7.2 作为远程数据库，采用 Type 4 JDBC 驱动程式直接进行连接，同样以失败告终。我们转而先将其编目到本地，采用该驱动程式的 Type 2 方式进行访问，其现象和用随 DB2 UDB V8.1 产品发布的 COM.ibm.db2.jdbc.app.DB2Driver 进行测试的结果类似。
这似乎让我们对这种新增支持的 JDBC 驱动程式失去了信心，不过不要着急。下文中会给出一种解决方法，能够使得这种驱动程式顺利的实现对 DB2 UDB V7.2 数据库的连接和各种操作。
附件
中给出了测试代码的框架，请有兴趣的读者自行更改各种 JDBC 驱动程式的包名和 URL 模式以完成各种实验组合。
实验结果：
A：对于这一类实验，我们对实验结果还是非常有信心的，最后的实验结果也验证了我们事先的预想。
对于DB2 UDB V7.2
  
DB2 UDB V7.2本地数据库
DB2 UDB V7.2远程数据库
COM.ibm.db2.jdbc.app.DB2Driver
成功
成功
COM.ibm.db2.jdbc.net.DB2Driver
成功
成功
对于DB2 UDB V8.1
  
DB2 UDB V8.1 本地数据库
DB2 UDB V8.1 远程数据库
COM.ibm.db2.jdbc.app.DB2Driver
成功
成功
COM.ibm.db2.jdbc.app.DB2Driver
成功
成功
com.ibm.db2.jcc.DB2Driver(Type 2)
成功
成功
com.ibm.db2.jcc.DB2Driver(Type 4)
成功
成功
这步测试中，编写代码，DB2 命令行工具，DB2 命令中心测试结果一致。看来随产品发布的 JDBC 驱动程式对本产品的支持相当不错。
B：这类实验的结果差别还是比较大的，也比较有趣。
  
DB2 UDB V7.2 远程数据库
（编目成本地数据库）
DB2 UDB V8.1 远程数据库
（编目成本地数据库）
COM.ibm.db2.jdbc.app.DB2Driver（随 DB2 UDB V7.2 产品发布）
无意义
成功
COM.ibm.db2.jdbc.app.DB2Driver（随 DB2 UDB V8.1 产品发布）
连接成功，其他操作失败（CLP 除外）
无意义
这步实验需要分两种情况来分析：
1. 本地端是 DB2 UDB V7.2 系统，远端是 DB2 UDB V8.1 系统，被编目至本地。

先用 DB2 命令行工具建立连接，进行各项数据库操作，都没有问题。

再用 DB2 命令中心重复上面操作，也没有问题。最后编写代码重复上面操作，同样一切正常。
这个结果让我们非常满意。
2. 本地端是 DB2 UDB V8.1 系统，远端是 DB2 UDB V7.2 系统，被编目至本地。

先用 DB2 命令行工具建立连接，进行各项数据库操作，一切正常。

再用 DB2 命令中心重复上面操作，数据库连接正常，但继续做数据库操作时，会报错：SQL0805N 未找到程式包 "NULLID.SYSSH200"。 SQLSTATE=51002，无法继续。

最后，编写代码进行测试，数据库连接一切正常，能够获得 Connection 对象引用，不过一旦进行各种数据库操作，会报和上面同样的错误。
这个错误将和下面实验 D 碰到的错误类似，下文会给出统一的解决方案。
C：这类实验之前我们猜测成功的可能性不大，最后的结果也验证了我们的猜测。
  
DB2 UDB V7.2 远程数据库（未编目成本地数据库）
DB2 UDB V8.1 远程数据库（未编目成本地数据库）
COM.ibm.db2.jdbc.net.DB2Driver（DB2 UDB V7.2产品发布）
和A重复
连接失败
COM.ibm.db2.jdbc.net.DB2Driver（DB2 UDB V8.1产品发布）
连接失败
和A重复
经过这步测试，能认为直接用 COM.ibm.db2.jdbc.net.DB2Driver 连接不同版本的远程数据库是不合适的。
D：研发人员一定对 DB2 UDB V8.1 新增支持的这两种 JDBC 驱动程式期望值非常高，因此这步实验的结果大家会比较关心。
  
DB2 UDB V7.2 远程数据库（编目成本地数据库）
DB2 UDB V7.2 远程数据库（未编目成本地数据库）
com.ibm.db2.jcc.DB2Driver(Type 2)
连接成功，其他操作失败（CLP 除外）
无意义
com.ibm.db2.jcc.DB2Driver(Type 4)
无意义
连接失败
通过这步实验，这种最新支持的 JDBC 驱动程式在兼容低版本上和原有驱动类似。看到这个结果我们有点失望。
其实，这个问题的关键在于一些标准 JCC JDBC 程式包没有和目标数据库进行绑定，能手工通过执行下面命令来完成这项工作。
示例如下：
db2jdbcbind -url jdbc:db2://ServerIP:50000/SAMPLEDB -user db2admin -password password
使用该命令实现绑定相关程式包之后，我又重复了部分实验 B 和实验 D，实验结果如下：
  
DB2 UDB V7.2 远程数据库（编目成本地数据库）
DB2 UDB V8.1 远程数据库（编目成本地数据库）
COM.ibm.db2.jdbc.app.DB2Driver（DB2 UDB V8.1产品发布）
成功
成功
  
DB2 UDB V7.2 远程数据库（编目成本地数据库）
DB2 UDB V7.2 远程数据库（未编目成本地数据库）
com.ibm.db2.jcc.DB2Driver(Type 2)
成功
无意义
com.ibm.db2.jcc.DB2Driver(Type 4)
无意义
成功
这同时解决了实验 B 和实验 D 中都碰到的问题，让我们松了一口气。
实验结论：
通过上面的实验，我们就能得出这样一些建议。他适用于当你需要在不同版本的DB2系统之间迁移你的数据库应用的时候。

我们能基于旧版本的 DB2 系统（如 DB2 UDB V7.2），然后将目标系统（如 DB2 UDB V8.1）编目至本地，使用 COM.ibm.db2.jdbc.app.DB2Driver 进行数据库连接和操作。

我们也能基于新版本的 DB2 系统（如 DB2 UDB V8.1），然后将目标系统（如 DB2 UDB V7.2）编目至本地，先手工将相关程式包绑定至目标数据库系统，再使用 COM.ibm.db2.jdbc.app.DB2Driver 或是 com.ibm.db2.jcc.DB2Driver 进行数据库连接和操作。
实验的结果让我们较为满意，我们有了不只一种选择来迁移我们的应用。