|
使用 DB2 通用 JDBC 驱动程序类型 4 连接 访问 DB2 UDB z/OS(R) 版服务器的 Java 应用程序可以利用它的连接集中器和综合系统（sysplex）工作负载平衡功能。
|这些功能类似于 DB2 Connect 的连接集中器和综合系统（sysplex）工作负载平衡功能。
|通过让许多连接对象使用同一物理连接，DB2 通用 JDBC 驱动程序 连接集中器可以减少 DB2 |UDB z/OS 版数据库服务器支持大量客户机应用程序所需的资源，从而减少与数据库服务器的物理连接总数。
|DB2 通用 JDBC 驱动程序 综合系统（sysplex）工作负载平衡可以提高数据共享组的可用性，因为驱动程序频繁地获取有关数据共享组成员的状态信息。驱动程序使用此信息确定下一个事务应路由至的数据共享成员。借助综合系统（sysplex）工作负载平衡，DB2 UDB z/OS 版服务器和“z/OS 的工作负载管理器”（WLM）确保在数据共享组的成员之间有效地分配工作，并确保在一个成员失败时将工作传送到数据共享组的另一个成员。
|DB2 通用 JDBC 驱动程序 使用传输对象和全局传输对象池来支持连接集中器和综合系统（sysplex）工作负载平衡。对于与数据库服务器的每个物理连接，都存在一个传输对象。启用连接集中器和综合系统（sysplex）工作负载平衡时，通过设置传输对象的最大数目，可以随时设置与数据库服务器的最大物理连接数。
|在驱动程序级别，使用 DB2 通用 JDBC 驱动程序 配置属性设置对传输对象数目的限制。
|在连接级别，使用数据源属性启用和禁用 DB2 通用 JDBC 驱动程序 连接集中器和综合系统（sysplex）工作负载平衡并设置对传输对象数目的限制。
|可用下列任一种方法来监视全局传输对象池：
|下列每个配置属性都用于连接集中器和综合系统（sysplex）工作负载平衡
|db2.jcc.dumpPool 的数据类型为整型（int.）。在写入任何统计信息之前，还必须设置 db2.jcc.dumpPoolStatisticsOnSchedule |和 db2.jcc.dumpPoolStatisticsOnScheduleFile 配置属性以写入统计信息。
|可以使用 db2.jcc.dumpPool 属性指定下列一种或多种统计信息类型：
|要跟踪多种事件类型，将想要跟踪的事件类型的值加起来。例如，假定想要跟踪 DUMP_GET_OBJECT 和 DUMP_CREATE_OBJECT 事件。与这些值等价的数字是 2 和 16，因此为 db2.jcc.dumpPool 值指定 18。
|缺省值是 0，它表示只写入全局传输池的总结统计信息。
|缺省值是 -1，它表示不写入全局传输池统计信息。
|如果未指定 db2.jcc.dumpPoolStatisticsOnScheduleFile |配置属性，则不写入全局传输池统计信息。
|db2.jcc.maxTransportObjectIdleTime 配置属性的缺省值是 60。将 db2.jcc.maxTransportObjectIdleTime 设置为一个小于 0 的值会导致立即从池中删除未使用的传输对象。建议不要使用此操作，因为它会严重降低性能。
|db2.jcc.maxTransportObjectWaitTime 配置属性的缺省值是 -1。任何负数值都表示应用程序永远等待下去。
|db2.jcc.maxTransportObjects 配置属性的缺省值是 -1，它表示对全局传输对象池中传输对象的数目没有限制。
|db2.jcc.minTransportObjects 配置属性的缺省值是 0。小于或等于 0 的任何值表示全局传输对象池可以为空。
|下列每个 DB2 通用 JDBC 驱动程序 数据源属性都用于连接集中器和综合系统（sysplex）工作负载平衡
|enableConnectionConcentrator 属性的数据类型为 boolean。缺省值是 false。但是，如果 enableSysplexWLB 被设置为 true，则缺省值为 true。
|enableSysplexWLB 属性的数据类型是 boolean。缺省值是 false。但是，如果 enableSysplexWLB 被设置为 true，则缺省情况下将 enableConnectionConcentrator 设置为 true。
|此属性的数据类型是整型（int.）。
|如果尚未达到 maxTransportObjects 值并且传输对象在全局传输对象池中不可用，则池将创建一个新的传输对象。如果达到 maxTransportObjects |值，则应用程序将等待 db2.jcc.maxTransportObjectWaitTime 配置属性所指定的时间长短。在经过该时间长短之后，如果池中仍没有可用的传输对象，则池将抛出 SQLException。
|maxTransportObjects |属性不覆盖 db2.jcc.maxTransportObjects 配置属性。maxTransportObjects 属性对来自其它数据源对象的连接无效。如果 maxTransportObjects 值大于 db2.jcc.maxTransportObjects 值，则 |maxTransportObjects 不会增加 db2.jcc.maxTransportObjects 值。
|maxTransportObjects 属性的缺省值是 -1，它表示仅驱动程序的 db2.jcc.maxTransportObjects 值限制数据源的传输对象的数目。
|下列过程是使用 WebSphere(R) Application Server 启用 DB2 通用 JDBC 驱动程序 连接集中器和综合系统（sysplex）工作负载平衡功能的示例。
|服务器要求：
|客户机要求：
|要使用 WebSphere Application Server 启用 DB2 通用 JDBC 驱动程序 连接集中器和综合系统（sysplex）工作负载平衡功能：
|java com.ibm.db2.jcc.DB2Jcc -version在输出中找到类似于以下内容的一行： |
[ibm][db2][jcc] Driver: IBM DB2 JDBC Universal Driver Architecture n nn 应为 2.7 或更大。
在 DB2JccConfiguration.properties 文件中设置配置属性。
|db2.jcc.minTransportObjects=0 |db2.jcc.maxTransportObjects=1500 |db2.jcc.maxTransportObjectWaitTime=-1 |db2.jcc.dumpPool=0 |db2.jcc.dumpPoolStatisticsOnScheduleFile= | /home/WAS/logs/srv1/poolstats
在 WebSphere Application Server |管理控制台中，设置应用程序用来连接至数据库服务器的数据源的下列属性：
|要监视 DB2 通用 JDBC 驱动程序 连接集中器和综合系统（sysplex）工作负载平衡功能，需要监视全局传输对象池。可用下列任一种方法来监视全局传输对象池：
|db2.jcc.dumpPool、db2.jcc.dumpPoolStatisticsOnSchedule 和 db2.jcc.dumpPoolStatisticsOnScheduleFile |配置属性控制对全局传输对象池的跟踪。
|例如，下列一组配置属性设置导致每 60 秒就将综合系统（sysplex）错误消息和转储池错误消息写入名为 /home/WAS/logs/srv1/poolstats 的文件：
|db2.jcc.dumpPool=DUMP_SYSPLEX_MSG|DUMP_POOL_ERROR |db2.jcc.dumpPoolStatisticsOnSchedule=60 |db2.jcc.dumpPoolStatisticsOnScheduleFile=/home/WAS/logs/srv1/poolstats|
池统计信息文件中的一个条目类似于如下所示：
|time Scheduled PoolStatistics npr:2575 nsr:2575 lwroc:439 |hwroc:1764 coc:372 aooc:362 rmoc:362 nbr:2872 tbt:857520 tpo:10
字段的含义为：
|可以编写应用程序以收集有关全局传输对象池的统计信息。这些应用程序在 DB2PoolMonitor 类中创建对象并调用方法来检索有关池的信息。
|例如，下列代码创建一个用于监视全局传输对象池的对象：
|import com.ibm.db2.jcc.DB2PoolMonitor; |DB2PoolMonitor transportObjectPoolMonitor = | DB2PoolMonitor.getPoolMonitor (DB2PoolMonitor.TRANSPORT_OBJECT);|
在创建 DB2PoolMonitor 对象之后，可以使用下列方法来监视全局传输对象池。
|public int getMonitorVersion()|
检索随 DB2 通用 JDBC 驱动程序 交付的 DB2PoolMonitor 类的版本。
|public int totalRequestsToPool()|
检索自创建池以来，DB2 通用 JDBC 驱动程序 向池发出的请求总数。
|public int successfullRequestsFromPool()|
检索自创建池以来，DB2 通用 JDBC 驱动程序 向池发出的成功请求数。成功请求表示池返回了一个对象。
|public int numberOfRequestsBlocked()|
检索 DB2 通用 JDBC 驱动程序 向池发出的、但由于池已达到其最大容量而被池阻塞的请求数。如果在超过 db2.jcc.maxTransportObjectWaitTime 配置值并且抛出异常之前一个对象被返回到池，则阻塞的请求可能是成功的。
|public long totalTimeBlocked()|
检索被池阻塞的请求的总时间（以毫秒计）。如果应用程序使用多线程，则这个时间可能比应用程序所用的执行时间长很多。
|public int lightWeightReusedObjectCount()|
检索已复用但不在池中的对象数。如果连接对象在事务边界处释放传输对象，则可能会出现这种情况。如果连接对象稍后需要一个传输对象，并且原始传输对象尚未被任何其它连接对象使用，则该连接对象可以使用该传输对象。
|public int heavyWeightReusedObjectCount()|
检索池中已复用的对象数。
|public int createdObjectCount()|
检索自创建池以来，DB2 通用 JDBC 驱动程序 创建的对象数。
|public int agedOutObjectCount()|
检索超过 db2.jcc.maxTransportObjectIdleTime |配置属性所指定的空闲时间并且已从池中删除的对象数。
|public int removedObjectCount()|
检索自创建池以来，已从池中删除的对象数。
|public int totalPoolObjects()|
当前在池中的对象数。
|OleDbReportIsLongForLongTypes 关键字受下列数据库服务器支持：
OLE DB 的客户机游标引擎和 OLE DB .NET 数据提供程序的 CommandBuilder 根据 IBM(R) DB2(R) OLE DB 提供程序提供的列信息来生成更新和删除语句。如果生成的语句在 WHERE 子句中包含 LONG 类型，则该语句将失败，这是因为不能在带有等号运算符的搜索中使用 LONG 类型。将关键字 OleDbReportIsLongForLongTypes 设置为 1 将使 IBM DB2 OLE DB 提供程序报告设置了 DBCOLUMNFLAGS_ISLONG 标志的 LONG 类型（LONG VARCHAR、LONG VARCHAR FOR BIT DATA、LONG VARGRAPHIC 和 LONG VARGRAPHIC FOR BIT DATA）。这可防止在 WHERE 子句中使用 LONG 列。
OleDbSQLColumnsSortByOrdinal 关键字受下列数据库服务器支持：
Microsoft(R) OLE DB 规范要求 IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) 返回按 TABLE_CATALOG、TABLE_SCHEMA、TABLE_NAME 和 COLUMN_NAME 列排序的行集。IBM DB2 OLE DB 提供程序遵守该规范。但是，通常已经编写了使用 Microsoft ODBC 桥提供程序（MSDASQL）的应用程序来获取按 ORDINAL_POSITION 排序的行集。将 OleDbSQLColumnsSortByOrdinal 关键字设置为 1 将使提供程序返回按 ORDINAL_POSITION 排序的行集。
IBM DB2 OLE DB 提供程序已经添加了新的属性组：DB2 数据源。DB2 数据源的属性集为 DBPROPSET_DB2DATASOURCE。
属性集的 GUID 为 {0x8a80412a,0x7d94,0x4fec,{0x87,0x3e,0x6c,0xd1,0xcd,0x42,0x0d,0xcd}}
DBPROPSET_DB2DATASOURCE 有三种属性：
#define DB2PROP_REPORTISLONGFORLONGTYPES 4 属性组：DB2 数据源 属性集：DB2PROPSET_DATASOURCE 类型：VT_BOOL 典型 R/W：R/W 描述：报告 Long 类型的 IsLong
OLE DB 的客户机游标引擎和 OLE DB .NET 数据提供程序的 CommandBuilder 根据 IBM DB2 OLE DB 提供程序提供的列信息来生成更新和删除语句。如果生成的语句在 WHERE 子句中包含 LONG 类型，则该语句将失败，这是因为不能在带有等号运算符的搜索中使用 LONG 类型。
| 值 | 含义 |
|---|---|
| VARIANT_TRUE | 将使 IBM DB2 OLE DB 提供程序报告设置了 DBCOLUMNFLAGS_ISLONG 标志的 LONG 类型（LONG VARCHAR、LONG VARCHAR FOR BIT DATA、LONG VARGRAPHIC 和 LONG VARGRAPHIC FOR BIT DATA）。这可防止在 WHERE 子句中使用 LONG 列。 |
| VARIANT_FALSE | 没有为 LONG VARCHAR、LONG VARCHAR FOR BIT DATA、LONG VARGRAPHIC 和 LONG VARGRAPHIC FOR BIT DATA 设置 DBCOLUMNFLAGS_ISLONG。这是缺省值。 |
#define DB2PROP_RETURNCHARASWCHAR 2 属性组：DB2 数据源 属性集：DB2PROPSET_DATASOURCE 类型：VT_BOOL 典型 R/W：R/W 描述：作为 WChar 来返回 Char
| 值 | 含义 |
|---|---|
| VARIANT_TRUE | OLE DB 将类型为 CHAR、VARCHAR、LONG VARCHAR 或 CLOB 的列描述为 DBTYPE_WSTR。ISequentialStream 中隐含的数据的代码页将为 UCS-2。这是缺省值。 |
| VARIANT_FALSE | OLE DB 将类型为 CHAR、VARCHAR、LONG VARCHAR 或 CLOB 的列描述为 DBTYPE_STR。ISequentialStream 中隐含的数据的代码页将为客户机的本地代码页。 |
#define DB2PROP_SORTBYORDINAL 3 属性组：DB2 数据源 属性集：DB2PROPSET_DATASOURCE 类型：VT_BOOL 典型 R/W：R/W 描述：按序数排序
Microsoft OLE DB 规范要求 IDBSchemaRowset::GetRowset(DBSCHEMA_COLUMNS) 返回按 TABLE_CATALOG、TABLE_SCHEMA、TABLE_NAME 和 COLUMN_NAME 列排序的行集。IBM DB2 OLE DB 提供程序遵守该规范。但是，通常已经编写了使用 Microsoft ODBC 桥提供程序（MSDASQL）的应用程序来获取按 ORDINAL_POSITION 排序的行集。
| 值 | 含义 |
|---|---|
| VARIANT_TRUE | 将使提供程序返回按 ORDINAL_POSITION 排序的行集。 |
| VARIANT_FALSE | 将使提供程序返回按 TABLE_CATALOG、TABLE_SCHEMA、TABLE_NAME 和 COLUMN_NAME 排序的行集。这是缺省值。 |
在“安装 DB2 通用 JDBC 驱动程序”这一主题中，DB2Binder 语法图不正确地定义了 DB2 通用 JDBC 驱动程序的 URL 语法。下图中显示了 DB2Binder 的 URL 语法的正确表示：
|
DB2 通用数据库(TM)（UDB）Linux(TM) 版、UNIX(R) 版、 版和 Windows(R) 版中的自动客户机重新路由功能允许客户机应用程序从与服务器的通信断开恢复，以便它们能继续处理最小的中断。
每当服务器锁定时，该服务器连接的每个客户机都会接收到一个通信错误，从而终止连接并导致应用程序错误。如果您非常重视可用性，应准备好备用的设置或故障转移支持。（故障转移是指一个服务器失效时另一个服务器接管操作的能力。）在任何一种情况下，DB2 通用 JDBC 驱动程序客户机都将尝试重新建立与新服务器或原始服务器的连接，该服务器可能会在故障转移节点上运行。重新建立连接后， 应用程序将接收到 SQLException 异常，通知它事务失败，但是应用程序可以继续进行下一事务。
在数据库管理员在服务器实例中的特定数据库中指定备用服务器位置之后，主服务器位置和备用服务器位置将在连接时返回至客户机。DB2 通用 JDBC 驱动程序创建可引用对象 DB2ClientRerouteServerList 的实例，并将该实例存储在它的瞬态内存中。如果通信中断，DB2 通用 JDBC 驱动程序将尝试使用从服务器返回的服务器信息来重新建立连接。
clientRerouteServerListJNDIName 数据源属性在客户机上提供附加客户机重新路由支持；clientRerouteServerListJNDIName 有两个功能：
clientRerouteServerListJNDIName 标识对备用服务器信息的 JNDI 资源库中的 DB2ClientRerouteServerList 实例的 JNDI 引用。在成功连接至主服务器之后， clientRerouteServerListJNDIName 提供的备用服务器信息将被来自该服务器的信息覆盖。如果定义了 clientRerouteServerListJNDIName 属性，则在故障转移之后，DB2 通用 JDBC 驱动程序将尝试把更新后的信息传播至 JNDI 存储。如果指定了 clientRerouteServerListJNDIName，则将把在 DB2ClientRerouteServerList 中指定的主服务器信息用于连接。如果未指定主服务器，则将使用在数据源上指定的 serverName 信息。
DB2ClientRerouteServerList 是有以下四种属性的可序列化 Java(TM) bean：
提供了用于访问这些属性的 Getter 和 setter 方法。DB2ClientRerouteServerList 类的定义为如下所示：
package com.ibm.db2.jcc;
public class DB2ClientRerouteServerList
implements java.io.Serializable,
javax.naming.Referenceable
{
public String[] alternateServerName;
public synchronized void
setAlternateServerName(String[] alternateServer);
public String[] getAlternateServerName();
public int[] alternatePortNumber;
public synchronized void
setAlternatePortNumber(int[] alternatePortNumberList);
public int[] getAlternatePortNumber();
public synchronized void
setPrimaryServerName (String primaryServerName);
public String getPrimaryServerName ();
public synchronized void setPrimaryPortNumber (int primaryPortNumber)
public int getPrimaryPortNumber ();
}
新建立的故障转移连接是使用原始数据源属性配置的，但是服务器名称和端口号除外。此外，在原始连接期间修改的任何 DB2 UDB 专用寄存器将在故障转移连接中使用 DB2 通用 JDBC 驱动程序来重新建立。
在发生通信故障时，DB2 通用 JDBC 驱动程序首先尝试恢复至主服务器。如果恢复至主服务器失败，驱动程序就会尝试连接至备用位置（故障转移）。重新建立连接之后，该驱动程序会向应用程序抛出 java.sql.SQLException 及 SQLCODE -4498，以便对应用程序指示已经自动与备用服务器重新建立了连接。于是该应用程序重试该事务。
要设置存储器以使 DB2ClientRerouteServerList 保持持久，遵循下列步骤：
// Create a starting context for naming operations
InitialContext registry = new InitialContext();
// Create a DB2ClientRerouteServerList object
DB2ClientRerouteServerList address=new DB2ClientRerouteServerList();
// Set the port number and server name for the primary server
address.setPrimaryPortNumber(50000);
address.setPrimaryServerName("mvs1.sj.ibm.com");
// Set the port number and server name for the alternate server
int[] port = {50002};
String[] server = {"mvs3.sj.ibm.com"};
address.setAlternatePortNumber(port);
address.setAlternateServerName(server);
registry.rebind("serverList", address);
datasource.setClientRerouteServerListJNDIName("serverList");DB2 通用 JDBC 驱动程序配置属性允许您设置具有驱动程序范围作用域的属性值。这些设置将应用于各个应用程序和数据源实例。可以更改这些设置而不必更改应用程序源代码或数据源特征。
每个 DB2 通用 JDBC 驱动程序配置属性设置使用以下格式：
property=value
如果配置属性以 db2.jcc.override 开头，则该配置属性适用于所有连接并将覆盖任何具有相同属性名的连接或数据源属性。如果配置属性以 db2.jcc 或 db2.jcc.default 开头，则配置属性值将为缺省值。连接或数据源属性设置将覆盖该值。
要设置配置属性：
对于独立 Java 应用程序，可通过在执行 java 命令时对每个配置属性指定 -Dproperty=value 来将配置属性设置为 Java 系统属性。
对于独立 Java 应用程序，可通过在执行 java 命令时指定 -Ddb2.jcc.propertiesFile=path 选项来设置配置属性。
DB2JccConfiguration.properties 可能是独立文件，也可能包括在 JAR 文件中。
如果 DB2JccConfiguration.properties 是独立文件，则 DB2JccConfiguration.properties 的路径必须在 CLASSPATH 并置中。
如果 DB2JccConfiguration.properties 在 JAR 文件中，该 JAR 文件必须在 CLASSPATH 并置中。
可设置下列 DB2 通用 JDBC 驱动程序配置属性。所有属性都是可选的。
对 db2.jcc.override.traceFile 属性值指定全限定文件名。
db2.jcc.override.traceFile 属性将覆盖连接或数据源对象的跟踪文件属性。
例如，对 db2.jcc.override.traceFile 指定以下设置将允许跟踪 DB2 通用 JDBC 驱动程序 Java 代码并记录至名为 /SYSTEM/tmp/jdbctrace 的文件：
db2.jcc.override.traceFile=/SYSTEM/tmp/jdbctrace
应在 IBM 软件支持机构的指导下设置跟踪属性。
db2secFreeToken 函数（标记拥有的可用内存）不再是 db2secGssapiServerAuthFunctions_1 用户认证插件 API 的一部分。
如果安全性插件的部署未经过充分编码、复查和测试，DB2 通用数据库（UDB）安装的完整性会受到损害。DB2 UDB 对于许多常见类型的故障采取了一些预防措施，但是，并不能保证部署用户编写的安全性插件时的完整性。
如果要使用您自己的定制安全性插件，可在通过 CLP 发出的连接语句或动态 SQL 语句上使用最多 255 个字符的用户标识。
对于 db2secGetGroupsForUser、db2secValidatePassword 和 db2secGetAuthIDs API，输入参数 dbname 可为空，而其对应长度输入参数 dbnamelen 将设置为 0。
在所有 Linux 和 UNIX 平台上，现在接受将 .so 作为用户编写的安全性插件库的文件扩展名。
在 AIX(R) 上，安全性插件库的扩展名可能是 .a 或 .so。如果同时存在两个版本的插件库，则使用 .a 版本。
对于 HP-UX on PA-RISC，安全性插件库的扩展名可以是 .sl 或 .so。如果同时存在两个版本的插件库，则使用 .sl 版本。
在所有其它 Linux 和 UNIX 平台上，.so 是安全性插件库唯一支持的文件扩展名。
在 AIX 上，安全性插件库的文件扩展名可以是 .a 或 .so。用于装入插件库的机制取决于使用哪个扩展名：
例如，要构建 32 位归档式插件库：
xlc_r -qmkshrobj -o shr.o MyPlugin.c -bE:MyPlugin.exp ar rv MyPlugin.a shr.o
xlc_r -qmkshrobj -o MyPlugin.so MyPlugin.c -bE:MyPlugin.exp
在除了 AIX 之外的所有平台上，安全性插件库总是被假定为动态可装入的共享对象。
GSS-API 认证仅限于使一个令牌从客户机流至服务器和使一个令牌从服务器流至客户机。这些令牌是从客户机上的 gss_init_sec_context() 和服务器上的 gss_accept_sec_context() 获得的。尝试更多流的 GSS-API 插件将生成安全性插件意外错误，从而导致连接失败。
消息加密和签名在 GSS-API 安全性插件中不可用。
所有应用程序终止（正常和异常）隐式回滚未完成的工作单元，不管操作系统如何都是如此。
在 DB2 通用数据库（UDB）版本 8.2 的“新增内容”文档中，『DB2 通用 JDBC 驱动程序改进』一节中的分布式事务支持信息中提供了不正确的信息。这一节的最后一句不正确。正确信息应为：
从版本 8.2 开始，DB2 UDB 支持符合 XA 规范的分布式事务处理。此支持实现 Java 2 Platform, Enterprise Edition（J2EE）Java 事务服务（JTS）和 Java 事务 API（JTA）规范。
[ 页的顶部 |上一页 | 下一页 | 目录 ]