DB2UDBJDBC通用驱动程序.doc

DB2 UDB JDBC 通用驱动程序简介在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..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 4JDBC通用驱动程序有了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，那么需要确保在主机上有一些必要的存储过程，这些存储过程将确保跟踪得以进行：SQLCOLPRIVILEGESSQLCOLUMNSSQLFOREIGNKEYSSQLGETTYPEINFOSQLPRIMARYKEYSSQLPROCEDURECOLSSQLPROCEDURESSQLSPECIALCOLUMNSSQLSTATISTICSSQLTABLEPRIVILEGESSQLTABLESSQLUDTSSQLCAMESSAGE这些存储过程是版本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_NONEcom.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTION_CALLScom.ibm.db2.jcc.DB2BaseDataSource.TRACE_STATEMENT_CALLScom.ibm.db2.jcc.DB2BaseDataSource.TRACE_RESULT_SET_CALLScom.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRIVER_CONFIGURATIONcom.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTScom.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRDA_FLOWScom.ibm.db2.jcc.DB2BaseDataSource.TRACE_RESULT_SET_META_DATAcom.ibm.db2.jcc.DB2BaseDataSource.TRACE_PARAMETER_META_DATAcom.ibm.db2.jcc.DB2BaseDataSource.TRACE_DIAGNOSTICScom.ibm.db2.jcc.DB2BaseDataSource.TRACE_SQLJcom.ibm.db2.jcc.DB2BaseDataSource.TRACE_XA_CALLS(仅适用于Universal Type 2Connectivity 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.txtString databaseURL=jdbc：db2：/：5021+/sample：traceFile=/temp/driverLog.txt；traceLevel=+(com.ibm.db2.jcc.DB2BaseDataSource.TRACE_DRDA_FLOWS+|com.ibm.db2.jcc.DB2BaseDataSource.TRACE_CONNECTS)；还有一种方法也可以进行JCC跟踪，这种方法不用修改应用程序。如果在客户机上创建一个名为DB2JccCperties的文本文件，该文件中只有一行文本：db2.jcc.override.traceFile=c：jcc.trc然后将该文件添加到CLASSPATH中，那么JCC跟踪将被自动启用。在不能更改任何源代码或JCC驱动程序属性的时候(例如，使用在内部使用JCC驱动程序的第三方产品)，这种方法非常有用。请参考DB2 Information Center中的以下链接，以获得更详细的信息：在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导致连接断开的严重错误99999DB2通用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风格的：ibmdb2jcct4=表明所使用的是type 4版本的驱动程序。ibmdb2jcct2=表明所使用的是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这个返回代码。异常中还显示了通信错误，可以看到，在这种特定情况下，这就是要返回给应用程序的内容。一个很好的技巧就是上下搜索这个异常，掌握在