mysql coldel0 03_mysql db2 性能_确定DB2 Java应用程序的性能问题

最新推荐文章于 2021-10-12 16:44:00 发布

weixin_39747577

最新推荐文章于 2021-10-12 16:44:00 发布

阅读量370

点赞数

文章标签： mysql coldel0 03

本文链接：https://blog.csdn.net/weixin_39747577/article/details/113425372

版权

问题确定和DB2体系结构简介

本文的目的是帮助您作为应用程序开发人员或数据库管理员，对您在部署Java应用程序时可能遇到的常见性能问题进行故障排除和诊断。这些包括常见的应用程序开发问题，例如挂起或响应缓慢。

深入了解DB2体系结构，DB2应用程序驱动程序以及所涉及的常见DB2组件对于有效地对Java应用程序问题进行故障排除和诊断至关重要。 DB2客户端由几层组成，每个组件都有自己的跟踪实用程序，以提供独特的信息来帮助诊断不同类型的应用程序问题。因此，在开始研究各种诊断工具之前，我们将从研究DB2客户机-服务器体系结构开始。

图1概述了DB2在客户端和服务器端使用的软件堆栈。有两种方法可以连接到DB2。图1中所示的客户端1是最常用的配置。这里，该应用程序安装了一个DB2客户机，例如DB2 Runtime Client。 DB2 Runtime Client还包括Universal JDBC Type 2驱动程序(也称为JCC T2)。

第二种方法(在图1中显示为Client 2)不需要安装DB2客户机。它使用DB2通用JDBC驱动程序(也称为JCC T4)代替DB2客户机，并且可以单独下载。 (请参阅本文“ 相关主题”部分中的链接。)要使用JCC T4驱动程序，应用程序开发人员必须在应用程序使用的CLASSPATH中包括db2jcc.jar和许可证文件db2jcc_license _ *。jar。两种类型的客户机都使用称为分布式关系数据库体系结构(DRDA®)的开放式数据库通信标准与DB2数据库服务器进行通信。有关DRDA的更多信息，链接到相关主题。

图1. DB2客户端/服务器架构

DB2客户机提供了许多类型的应用程序接口。图2显示了应用程序层，其中详细说明了可与DB2一起使用的应用程序类型。这些应用程序中的大多数都通过DB2呼叫级别接口(CLI)。 JCC驱动程序仅限于Java应用程序，因为它是基于Java的驱动程序。出现问题时，应用程序开发人员可以根据所使用的应用程序的类型来收集以下所述的跟踪信息的组合。

呼叫级别接口(CLI)跟踪：大多数应用程序通过CLI层。

DB2跟踪：跟踪用户应用程序下方和DRDA通信层的DB2客户端的内部工作。它也可以用于跟踪服务器端问题。

JCC跟踪：这是使用DB2通用JDBC驱动程序的应用程序的单独跟踪实用程序。

JDBC跟踪：这将跟踪旧式JDBC Type 2驱动程序；但是，它并不经常使用，因为对该层的调用将被向下传递到CLI层。

图2.扩展应用程序层

在进行故障排除时，请记住以下一些关键概念：

使用自上而下的方法进行故障排除，而不是查看详细信息并尝试弄清楚这些详细信息是否与当前问题有关。

了解环境和配置。

应用程序在哪里运行？

数据库在哪里？

每个系统上都有什么平台，操作系统和DB2版本(修订包级别)？

尽可能简化环境和应用程序。

从应用程序外部执行相同的查询是否表现出相同的行为？

与从客户端执行查询相比，从服务器运行查询是否得到相同的响应？

注意最近的软件或硬件更改。

仅在了解环境并简化问题域之后，才能使用可用的跟踪功能进行深入查找以找到根本原因。

在客户端和服务器端应用程序以及DB2日志中查找任何相应的消息。

Developer Workbench调试工具概述

Developer Workbench提供了一个全面的开发环境，可促进SQL和Java例程的开发和调试。创建存储过程时，请确保以调试模式创建例程。

图3.启用新的存储过程进行调试

现在，我们可以在存储过程中创建一些断点，然后单击“调试”对话框开始调试。

图4.调试对话框

在下面的屏幕快照中，调试器在每个断点处停止并显示程序中变量的当前状态。

图5.调试存储过程

图6.调试存储过程

Developer Workbench是开发Java应用程序时使用的便捷工具。但是，当出现性能问题时，应用程序开发人员可能无法了解哪个Java例程或代码的哪一部分执行不充分。 DB2跟踪工具可用于向下钻取并隔离引起问题的应用程序。有关如何使用Developer Workbench的更多详细信息，请参见“ 相关主题”部分。

CLI跟踪概述

用于开放式数据库连接(ODBC)和调用级别接口(CLI)的DB2 IBM驱动程序是DB2数据库服务器的可调用SQL接口驱动程序。 JDBC 2类驱动程序，DB2 Perl模块(DBD：DB2)，用于DB2PHP数据对象接口，用于Ruby on Rails的IBM_DB驱动程序以及.NET / ADO / OLEDB提供程序均基于IBM开放数据库连接(ODBC)驱动程序和呼叫层接口(CLI)驱动程序。

DB2 CLI跟踪是内置在IBM驱动程序中的跟踪工具，用于开放式数据库连接(ODBC)和呼叫级别接口(CLI)驱动程序。可以使用CLI跟踪来跟踪直接和间接访问CLI驱动程序的所有应用程序。 DB2 CLI跟踪包含各种时序信息，可用于诊断应用程序性能问题。

以下链接提供了有关CLI跟踪的更多信息：

配置CLI跟踪

启用CLI跟踪

解释CLI跟踪文件中的输入和输出参数

解释CLI跟踪中的时序信息

清单1中的CLI跟踪显示了每个CLI函数的out箭头(指向右)和in箭头(指向左)。向外箭头显示自上次CLI调用以来在应用程序中花费的时间。 in箭头显示了在DB2客户机之外花费的时间，包括网络时间(往返)和在DB2服务器上花费的时间。例如，SQLExecute()调用中显示的1.828213E + 001秒(约18秒)由SQL执行时间加网络时间组成。可以提取在SQLPrepareW()语句中找到的SELECT语句，然后在数据库服务器的DB2 CLP(命令行处理器)上本地运行它。如果在服务器上花费的时间少得多，则延迟可能在网络层。请参阅“ 使用Java应用程序诊断网络问题 ”一节以调查网络问题。如果在服务器上运行大约需要相同的时间，则DBA将必须调整服务器和SQL语句。

清单1. SQLExecute()中的执行时间

SQLPrepareW( hStmt=1:1, pszSqlStr="select * from EMPLOYEE", cbSqlStr=31 )

---> Time elapsed - +1.728000E-003 seconds

( StmtOut="select * from EMPLOYEE" )

...

SQLExecute( hStmt=1:1 )

---> Time elapsed - +2.145000E-003 seconds

( Package="SYSSH200 ", Section=4 )

sqlccsend( Handle - 186081616 )

sqlccsend( ulBytes - 487 )

sqlccsend( ) rc - 0, time elasped - +4.500000E-005

sqlccrecv( timeout - +0.000000E+000 )

sqlccrecv( ulBytes - 34736 ) - rc - 0, time elapsed - +1.823593E+001

( Requested Cursor Attributes=3 )

( Reply Cursor Attributes=524298 )

( Actual Cursor Attributes=524299 )

SQLExecute( )

以下CLI跟踪输出显示了CLI调用SQLGetConnectAttr()和SQLColAttributesW()之间在应用程序中花费的时间1.260248E + 002秒(约126秒)。换句话说，在应用程序中发生了1.260248E + 002秒的延迟。如果预计不会出现此类延迟，则应用程序开发人员应调查应用程序代码。

清单2.应用程序中的执行时间

SQLGetConnectAttr( hDbc=0:1, fOption=SQL_ATTR_AUTOCOMMIT, pvParam=&0c53fdf0,

cbParamMax=-4, pcbParam=)

---> Time elapsed - +1.407000E-003 seconds

SQLGetConnectAttr( pvParam=0 )

Time elapsed - +1.260248E+002 seconds

sqlccsend( Handle - 186057520 )

sqlccsend( ulBytes - 228 )

sqlccsend( ) rc - 0, time elasped - +8.000000E-006

sqlccrecv( timeout - +0.000000E+000 )

sqlccrecv( ulBytes - 4099 ) - rc - 0, time elapsed - +1.311000E-003

SQLColAttributesW( pCharAttribute="MING ", psCharAttributeByteLen=16 )

以下CLI跟踪显示了连接耗时5.569619E + 001秒(约55秒)。如果仅在连接期间观察到延迟，则可能是身份验证延迟的征兆。有关更多详细信息，请参阅诊断身份验证部分。

清单3. SQLDriverConnect()中的执行时间

SQLDriverConnect( hDbc=0:1, hwnd=0:0, szConnStrIn="DSN=sample;UID=ming;

PWD=********;AUTOCOMMIT=0;CONNECTTYPE=1;", cbConnStrIn=-3,

szConnStrOut=&0bf9de64, cbConnStrOutMax=256, pcbConnStrOut=&0bf9e044,

fDriverCompletion=SQL_DRIVER_NOPROMPT )

---> Time elapsed - +1.806000E-003 seconds

sqlccsend( Handle - 199165312 )

sqlccsend( ulBytes - 276 )

sqlccsend( ) rc - 0, time elasped - +2.440000E-004

sqlccrecv( )

sqlccrecv( ulBytes - 122 ) - rc - 0, time elapsed - +3.849500E-002

sqlccsend( Handle - 199165312 )

sqlccsend( ulBytes - 272 )

sqlccsend( ) rc - 0, time elasped - +2.670000E-004

sqlccrecv( )

sqlccrecv( ulBytes - 249 ) - rc - 0, time elapsed - +4.629900E-002

( DBMS NAME="DB2/AIX64", Version="08.02.0004", Fixpack="0x23050106" )

( Application Codepage=1252, Database Codepage=819, Char Send/Recv

Codepage=1252, Graphic Send/Recv Codepage=1200 )

SQLDriverConnect( szConnStrOut="DSN=sample;UID=;PWD=********;

DBALIAS=DPMP;AUTOCOMMIT=0;CONNECTTYPE=1;", pcbConnStrOut=74 )

在针对性能问题进行CLI跟踪时，使用CLI关键字TRACECOMM和可选的关键字TRACETIMESTAMP非常重要，因为这两个关键字都会将额外的计时信息跟踪到CLI跟踪文件，从而更容易发现跟踪中的任何延迟。

DB2跟踪工具概述

DB2跟踪可用于跟踪客户端上应用程序下面的层。它也可以用来跟踪服务器端。

有关DB2跟踪的更多信息，请参见developerWorks文章DB2基础：DB2 UDB跟踪工具简介。

您可以使用带有时间戳记的DB2跟踪来识别慢速网络问题。以下是可在客户端使用的跟踪说明：

db2trc on -t -f trc.dmp输入命令db2trc on -t -f trc.dmp 。

通过从CLP运行SQL语句来重新创建性能问题。

输入命令db2trc off 。

有关其他DB2跟踪选项，请参阅参考资料小节中的DB2跟踪语法。

一旦关闭跟踪，将在发出db2trc命令的路径中生成一个二进制转储文件。在这种情况下，转储文件是trc.dmp，必须对其进行流(flw)并将其格式化(fmt)到ASCII文件，以便使其可读。使用fmt -c将生成DRDA跟踪。

例如：

db2trc flw trc.dmp trc.flw

db2trc fmt trc.dmp trc.fmt

db2trc fmt -c trc.dmp trc_drda.fmt

应当注意，此过程需要在与收集DB2跟踪转储文件相同的DB2修订包级别上执行。流文件(trc.flw)列出了每个进程和线程进行的函数调用。格式文件(trc.fmt)将按写入跟踪文件的顺序提供有关每个DB2函数调用的详细信息。如果db2trc on是使用-t选项发出的，则可以使用-t选项流转储文件，如下所示。

db2trc flw -t trc.dmp trc.flw

上面的指示信息创建带有时间戳的DB2跟踪流文件。清单4是DB2跟踪流文件的样本。第二列是格式为ssss：nnnnnnnnn的时间戳。其中ssss表示秒，nnnnnnnnnn表示纳秒。

清单4.带时间戳的DB2跟踪

5572283 1485:587835949 | | | | | sqlccrecv data [probe 120]

5572284 1485:587837095 | | | | | | sqlcctcprecv entry

5572285 1485:587838001 | | | | | | sqlcctcprecv data [probe 1]

5572286 1485:587839212 | | | | | | | tcprecv entry

6059823 1570:670189615 | | | | | | | tcprecv data [probe 2]

6059824 1570:670198964 | | | | | | | tcprecv exit

6059825 1570:670208194 | | | | | | sqlcctcprecv exit

6059826 1570:670211750 | | | | | sqlccrecv data [probe 5]

6059827 1570:670213511 | | | | | sqlccrecv exit

DB2依靠操作系统(OS)应用程序编程接口(API)来执行网络通信。您可以将上面的函数tcprecv()视为OS API TCP / IP recv()调用的包装器。 recv()函数从连接的套接字接收数据。如清单4所示，tcprecv()大约需要85秒(1570-1485)来接收数据。这85秒是服务器响应时间和网络时间的总和。如果从服务器上的CLP执行相同SQL语句花费的时间少得多，则主要是怀疑网络速度较慢，网络管理员需要进行调查。

清单5显示了如何使用db2diag命令解释DB2跟踪或db2diag.log中的返回码。

清单5.解释返回码

E:\db2v8\BIN>db2diag -rc fffffb95

Input ECF string 'fffffb95' parsed as 0xFFFFFB95 (-1131).

NOTE: ../sqz/sqlzwhatisrc.C:

V7 input ZRC 0xFFFFFB95 (-1131) may translate to V8 ZRC value of 0x83000

B95 (-2097149035)

ZRC value to map: 0x83000B95 (-2097149035)

V7 Equivalent ZRC value: 0xFFFFBB95 (-17515)

ZRC class :

Unexpected Operating System error (Class Index: 3)

Component:

Unknown component (Component Index: 0)

Undefined as of DB2 v8.1.14.292; s061108

Attempting to lookup value 0xFFFFFB95 (-1131) as a sqlcode Sqlcode -1131

SQL1131N DARI (Stored Procedure) process has been terminated abnormally.

DB2通用JDBC驱动程序跟踪概述

需要JDBC通用驱动程序(JCC)跟踪来确定在收到错误消息，性能问题或挂起之前已经发生或正在执行的操作。如果没有此类信息，则很难确定应用程序如何进入此状态。 JCC跟踪应在托管Java应用程序的系统上运行。

有多种方法可以收集JCC跟踪：

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

获取使用DB2通用JDBC驱动程序的应用程序的痕迹

JCC跟踪的标题提供了大量有用的环境信息，例如：

操作系统和环境变量。这可以用来确定我们是否要选择JCC驱动程序或应用程序库的多个版本。

应用程序用来连接的用户ID

JDK版本和供应商。确保DB2支持JDK

使用的JCC驱动程序级别和JDBC属性

远程DB2数据库的版本

每个JCC驱动程序级别都对应于表1 (DB2 v8.x)和表2 (DB2 v9.x)中描述的DB2修订包。从JCC跟踪返回的产品标识显示在表3中。

表1. DB2 v8附带的JCC驱动程序版本

JCC版本

DB2版本

JCC 1.0

GA(常规可用性或FixPak 0)

JCC 1.1

FP1

JCC 1.2

FP2

JCC 1.3

FP3

JCC 1.5

FP4

JCC 1.9

FP5

JCC 2.2

FP6

JCC 2.3

FP7

JCC 2.5

FP8

JCC 2.6.80

FP9

JCC 2.7.58

引入了FP10 SYSPLEX路由支持

JCC 2.8.46

FP11

JCC 2.9.31

FP12

JCC 2.10.27

FP13

JCC 2.10.52

FP14

表2. DB2 9附带的JCC驱动程序版本

JCC版本

DB2版本

JCC 3.1.57

GA(常规可用性或FixPak 0)

JCC 3.2.49

FP1

JCC 3.3.54

FP2

JCC 3.4.65

FP3

表3. JCC跟踪的产品版本

数据库产品版本

DB2平台

SQL08027

Linux / Unix / Windows上的DB2 v8.x

SQL09011

Linux / Unix / Windows上的DB2 v9.x

DSN07012

DB2 for z系列(z / OS)v7.x

DSN08015

DB2 z系列(z / OS)v8.x

V05R04M00

DB2 i系列(AS400)V5R4

从清单6中的示例JCC跟踪中，我们可以看到JCC Type 4应用程序以用户admin的身份在Sun Solaris 5.8上运行，并使用用户标识DB2INST1连接到DB2 v8 for z / OS上的数据库SAMPLE(DSN08015)。

清单6.示例JCC跟踪

[ibm][db2][jcc] BEGIN TRACE_DRIVER_CONFIGURATION

[ibm][db2][jcc] Driver: IBM DB2 JDBC Universal Driver Architecture 2.10.62

[ibm][db2][jcc] Compatible JRE versions: { 1.3, 1.4, 1.5 }

[ibm][db2][jcc] Target server licensing restrictions: { z/OS: enabled; SQLDS: enabled;

iSeries: enabled; DB2 for Unix/Windows: enabled; Cloudscape: enabled }

[ibm][db2][jcc] Range checking enabled: true

[ibm][db2][jcc] Bug check level: 0xff

[ibm][db2][jcc] Default fetch size: 64

[ibm][db2][jcc] Default isolation: 2

[ibm][db2][jcc] Collect performance statistics: false

[ibm][db2][jcc] No security manager detected.

[ibm][db2][jcc] Detected local client host: appserver.ibm.com/9.29.3.3

[ibm][db2][jcc] Access to package sun.io is permitted by security manager.

[ibm][db2][jcc] JDBC 1 system property jdbc.drivers = null

[ibm][db2][jcc] Java Runtime Environment version 1.4.2_07

[ibm][db2][jcc] Java Runtime Environment vendor = Sun Microsystems Inc.

[ibm][db2][jcc] Java vendor URL = http://java.sun.com/

[ibm][db2][jcc] Java installation directory = /apps/j2re1.4.2_07

[ibm][db2][jcc] Java Virtual Machine specification version = 1.0

[ibm][db2][jcc] Java Virtual Machine specification vendor = Sun Microsystems Inc.

[ibm][db2][jcc] Java Virtual Machine specification name = Java Virtual Machine

Specification

[ibm][db2][jcc] Java Virtual Machine implementation version = 1.4.2_07-b05

[ibm][db2][jcc] Java Virtual Machine implementation vendor = Sun Microsystems Inc.

[ibm][db2][jcc] Java Virtual Machine implementation name = Java HotSpot(TM) Server VM

[ibm][db2][jcc] Java Runtime Environment specification version = 1.4

[ibm][db2][jcc] Java Runtime Environment specification vendor = Sun Microsystems Inc.

[ibm][db2][jcc] Java Runtime Environment specification name = Java Platform API

Specification

[ibm][db2][jcc] Java class format version number = 48.0

[ibm][db2][jcc] Java class path = :/apps/jakarta-tomcat-5.5.7/common/lib/db2jcc.jar:

/apps/jakarta-tomcat-5.5.7/common/lib/db2jcc_license_cisuz.jar:

/apps/jakarta-tomcat-5.5.7/common/lib/db2jcc_javax.jar:

/apps/jakarta-tomcat-5.5.7/bin/bootstrap.jar:

/apps/jakarta-tomcat-5.5.7/bin/commons-logging-api.jar

[ibm][db2][jcc] Java native library path = /apps/j2re1.4.2_07/lib/sparc/server:

/apps/j2re1.4.2_07/lib/sparc:/apps/j2re1.4.2_07/../lib/sparc:/usr/lib

[ibm][db2][jcc] Path of extension directory or directories = /apps/j2re1.4.2_07/lib/ext

[ibm][db2][jcc] Operating system name = SunOS

[ibm][db2][jcc] Operating system architecture = sparc

[ibm][db2][jcc] Operating system version = 5.8

[ibm][db2][jcc] File separator ("/" on UNIX) = /

[ibm][db2][jcc] Path separator (":" on UNIX) = :

[ibm][db2][jcc] User's account name = admin

[ibm][db2][jcc] User's home directory = /home/admin

[ibm][db2][jcc] User's current working directory = /apps/jakarta-tomcat-5.5.7/bin

[ibm][db2][jcc] Loaded global properties file:

/apps/jakarta-tomcat-5.5.7/webapps/ivs/WEB-INF/classes/DB2JccConfiguration.properties

[ibm][db2][jcc] Loaded by Context ClassLoader: WebappClassLoader

...

[ibm][db2][jcc] END TRACE_DRIVER_CONFIGURATION

[ibm][db2][jcc] BEGIN TRACE_CONNECTS

[ibm][db2][jcc] Attempting connection to test.ibm.com:50000/SAMPLE

[ibm][db2][jcc] Using properties: { traceFile/tmp/jcctrace.txt, user=DB2INST1,

password=********}

[ibm][db2][jcc] END TRACE_CONNECTS

...

[ibm][db2][jcc][Connection@16fa474] BEGIN TRACE_CONNECTS

[ibm][db2][jcc][Connection@16fa474] Successfully connected to server

jdbc:db2://test.ibm.com:50000/SAMPLE

[ibm][db2][jcc][Connection@16fa474] User: DB2INST1

[ibm][db2][jcc][Connection@16fa474] Database product name: DB2

[ibm][db2][jcc][Connection@16fa474] Database product version: DSN08015

[ibm][db2][jcc][Connection@16fa474] Driver name: IBM DB2 JDBC Universal Driver

Architecture

[ibm][db2][jcc][Connection@16fa474] Driver version: 2.10.62

[ibm][db2][jcc][Connection@16fa474] DB2 Application Correlator:

G41E4EB2.GA90.C0E39670F334.0000

[ibm][db2][jcc][Connection@16fa474] END TRACE_CONNECTS

...

Java性能

性能问题通常可以分为两种类型：间歇性和非间歇性。间歇性问题很难解决，因为它们可能根据工作量或应用程序时间而随时发生。要诊断间歇性性能问题，可以使用的一种非常有用的工具是db2pd -catch 。可以将此工具设置为执行脚本，当返回指定的错误消息时，该脚本可用于收集诊断信息。缺点是在发生错误后会收集信息。此工具的一种理想用法是在数据库服务器达到容量阈值时捕获快照信息。例如，当db2agent的最大数量已超过并且DB2无法接受新连接时，应用程序将返回-1224(SQL1224)。

您可以编写一个名为“ db2cos”的shell脚本，其中包含要在DB2遇到SQL1224错误时要执行的任何操作系统或DB2命令。请注意，该脚本必须命名为db2cos。否则，DB2将不会执行它。有关db2cos的更多信息，请参见db2cos的“ DB2信息中心”部分。

清单7.编写db2cos脚本

#!/bin/sh

# DB2 Callout script to collect information for SQL1224

echo "Collecting information for SQL1224">>db2cos.rpt

echo "db2cos script executed at `date`" >>db2cos.rpt

db2pd -agents >>db2cos.rpt

清单8演示了一旦shell脚本完成，如何安装调出脚本。如果错误消息与锁定有关，那么也应该在db2cos脚本中收集锁定快照。

清单8.启用db2cos

$ cp db2cos /home/db2inst1/sqllib

$ db2pd -catch clear all

All error catch flag settings cleared.

$ db2pd -catch -1224

Input ECF string '-1224' parsed as 0xFFFFFB38 (-1224).

Error Catch #1

Sqlcode: -1224

ReasonCode: 0

ZRC: 0

ECF: 0

Component ID: 0

LockName: Not Set

LockType: Not Set

Current Count: 0

Max Count: 255

Bitmap: 0x461

Action: Error code catch flag enabled

Action: Execute sqllib/db2cos callout script

Action: Produce stack trace in db2diag.log

由于可以使用跟踪收集其他诊断信息，因此可重现或非间歇性问题的诊断要容易得多。 Java应用程序的性能问题可以分为四种一般类型：

执行缓慢

挂

非DB2问题

错误信息

通常，由于返回了错误消息，因此上述第四种类型(错误消息)最容易诊断。在这种情况下，根据导致错误消息的客户端执行的应用程序类型，收集适当的跟踪。查看跟踪通常可以提供足够的信息来解决问题。下一节将说明如何诊断上述前三种情况。

Java例程实现概述

在诊断可以定义为存储过程(SP)或用户定义函数(UDF)的Java例程问题之前，有必要检查一下Java例程的调用方式。缺省情况下，DB2在DB2之外启动一个单独的进程，以运行称为db2fmp的受防护的Java例程。之所以采取这种预防措施，是因为DB2正在执行应用程序开发人员编写的未知代码。如果发生异常，最坏的情况是db2fmp进程终止而没有关闭整个数据库。这种增加的灵活性还允许流氓Java例程在消耗过多内存或CPU时终止它们。如果Java例程在db2agent而不是db2fmp进程中以不受限制的方式运行，则异常可能会使整个数据库崩溃。

除了将Java例程定义为FENCED或UNFENCED外，还可以将它们定义为THREADSAFE或NOT THREADSAFE。区别在于THREADSAFE Java例程在db2fmp进程内作为线程运行。 NOT THREADSAFE Java例程在单独的db2fmp进程中运行。缺省情况下，DB2将Java例程创建为THREADSAFE。由于db2fmp进程是使用受防护的用户ID运行的，因此其资源限制将由其用户限制确定。清单9显示了如何查找和修改受保护的用户ID。

清单9.修改受保护的用户标识

/home/db2inst1/sqllib/adm: ls -la .fenced

-rw-r--r-- 1 nobody nobody 0 Jun 20 16:49 .fenced

/home/db2inst1/: db2stop

SQL1064N DB2STOP processing was successful.

/home/db2inst1/: chown db2fenc1 /home/db2inst1/sqllib/adm/.fenced

/home/db2inst1/: db2start

SQL1063N DB2START processing was successful.

/home/db2inst1/sqllib/adm: ls -la .fenced

-rw-r--r-- 1 db2fenc1 fencgrp 0 Jun 20 16:55 .fenced

当一个应用程序连接到DB2时，一个或多个db2agent进程被分配给该应用程序以运行查询。当应用程序调用Java例程时，db2agent和db2fmp进程之间的通信将通过由DB2注册表变量DB2_FMP_COMM_HEAPSZ确定的Fenced Mode通信池。 DB2_FMP_COMM_HEAPSZ的大小确定可以在实例中运行的并发例程的最大数量。图7说明了如何调用Java例程。

图7.调用Java例程

诊断Java例程执行缓慢

如先前在图1中看到的，有客户端和服务器端组件，每个组件都由多层组成。第一项是确定这是客户端还是服务器端的问题。要排除Developer Workbench引起问题的可能性，请从客户端命令行处理器(如果适用)调用存储过程，并检查响应时间是否可接受。

如果其响应时间很慢或类似于从应用程序调用SP的时间，那么我们可以得出结论，该应用程序不是罪魁祸首。在这种情况下，请继续从服务器的命令行处理器调用存储过程。如果响应时间很慢，则数据库管理员应从服务器端进行调查。性能问题可能是由优化程序在执行例程时使用的配置错误，调整问题或访问计划不正确引起的。

否则，我们可以得出结论，性能下降是在DB2客户机代码中还是在网络中。此时，我们可以使用timestamp选项收集DB2跟踪，以确定哪个函数返回时间最长。例如，我们在等待TCP / IP吗？一些应用程序将使用参数标记来调用例程，因此将需要收集JDBC或JCC跟踪以捕获输入参数。应用程序端日志也可能包含此信息。

隔离慢的SP后，应用程序开发人员应将调试代码添加到Java例程中，以确定性能瓶颈在哪里。添加调试代码最简单的方法是将INSERT语句添加到Java例程中。清单10是创建表SP_DEBUG来存储调试信息的脚本。

清单10.创建调试表的DB2脚本

connect to sample;

create table sp_debug(sp_name varchar(100), time timestamp, trace_point integer,

desc varchar(100));

terminate;

清单11.将调试信息写入表

import java.sql.*;

import java.io.*;

public class TEST_JAVASP3

{

public static void tEST_JAVASP3 (int input) throws SQLException,

Exception

{

int errorCode;

Connection dbCon=null;

Statement debug_st=null;

PreparedStatement pstmt=null;

try

{

// get caller's connection to the database

dbCon = DriverManager.getConnection("jdbc:default:connection");

// Create a statement handle for to execute debug statements

debug_st = dbCon.createStatement();

debug_st.execute("INSERT INTO SP_DEBUG values('test_javasp3',

current timestamp, 1,'entry')");

String query = "INSERT INTO T1 (C1) VALUES (?)";

debug_st.execute("INSERT INTO SP_DEBUG values('test_javasp3',

current timestamp, 2,'prepare')");

pstmt = dbCon.prepareStatement(query);

pstmt.setInt(1, input);

pstmt.executeUpdate();

debug_st.execute("INSERT INTO SP_DEBUG values('test_javasp3',

current timestamp, 3,'executeUpdate')");

/* Cause the stored proc to hang if the input value is 11 */

if( input == 11)

{

while(true);

}

debug_st.execute("INSERT INTO SP_DEBUG values('test_javasp3',

current timestamp, 4,'done if')");

debug_st.execute("INSERT INTO SP_DEBUG values('test_javasp3',

current timestamp, 10,'exit')");

// Cleanup

pstmt.close();

debug_st.close();

dbCon.close();

}

catch (SQLException sqle)

{

errorCode = sqle.getErrorCode();

throw new SQLException( errorCode + " FAILED" );

}

finally

{

if(pstmt !=null)

{pstmt.close();}

if(debug_st !=null)

{debug_st.close();}

if( dbCon != null)

{dbCon.close();}

}

} // end finally

}

表4. SP_DEBUG表的内容

SP_NAME

时间

示踪点

数据中心

test_javasp3

2007-07-10-19.25.21.436000

1个

条目

test_javasp3

2007-07-10-19.25.21.452000

准备

test_javasp3

2007-07-10-19.25.21.452000

executeUpdate

test_javasp3

2007-07-10-19.25.21.452000

如果完成

test_javasp3

2007-07-10-19.25.21.452000

出口

使用上述方法的优点是它很容易实现。缺点是，如果没有数据库连接，它将无法将调试信息输出到表。由于这样的严重错误已经解决，因此这可能不会成为问题。表4列出了执行存储过程后调试表的内容。它显示时间戳以及已执行的代码部分。

另一种方法是修改Java例程，以便它将调试信息写入文件，如清单12所示。在我们的示例中，将调试参数添加到存储过程定义中以启用/禁用调试。添加调试信息时会产生额外的开销，因此应用程序开发人员可能会选择从Java例程的生产版本中删除调试代码。还要注意，与将调试信息插入表相比，写入文件需要更多的调用，因为我们需要格式化Java时间戳。默认情况下，Java时间戳自1970年1月1日起以毫秒为单位。Calendar()对象用于将时间戳(以毫秒为单位)格式化为人类可读的格式。对debugOut.flush()的调用立即将字符缓冲区转储到文件中。如果没有此调用，则在调试挂起问题时，可能不会写入调试输出，因为挂起是在字符缓冲区变满之前发生的。

清单12.将调试信息写入文件

import java.sql.*;

import java.io.*;

import java.util.*;

public class TEST_JAVASP2

{

public static void tEST_JAVASP2 (int input, int debug) throws SQLException,

Exception

{

int errorCode;

PrintWriter debugOut=null;

Calendar cal = null;

try

{

if (debug == 1)

{

cal = Calendar.getInstance();

cal.setTimeInMillis(System.currentTimeMillis() );

// Open debug file

debugOut = new PrintWriter(new FileWriter("sp_debug.txt"));

cal.setTimeInMillis(System.currentTimeMillis() );

debugOut.println(cal.getTime() + " " + cal.get(Calendar.MILLISECOND)+ " "

+ "tEST_JAVASP2 - entry");

// Need to flush buffer to disk otherwise when troubleshooting hang

// issue the output file will be empty

debugOut.flush();

}

// get caller's connection to the database

Connection con = DriverManager.getConnection("jdbc:default:connection");

String query = "INSERT INTO T1 (C1) VALUES (?)";

if (debug == 1)

{

cal.setTimeInMillis(System.currentTimeMillis() );

debugOut.println(cal.getTime() + " " + cal.get(Calendar.MILLISECOND)+ " "

+ "tEST_JAVASP2 - preparing query");

debugOut.flush();

}

PreparedStatement pstmt = con.prepareStatement(query);

pstmt.setInt(1, input);

pstmt.executeUpdate();

if (debug == 1)

{

cal.setTimeInMillis(System.currentTimeMillis() );

debugOut.println(cal.getTime() + " " + cal.get(Calendar.MILLISECOND)+ " "

+ "tEST_JAVASP2 - executed query");

debugOut.flush();

}

if( input == 11)

{

for(int i=0;i<10;i++)

{

if (debug == 1)

{

cal.setTimeInMillis(System.currentTimeMillis() );

debugOut.println(cal.getTime() + " " + cal.get(Calendar.MILLISECOND)

+ " " + "tEST_JAVASP2 - loop" + " i="+i);

debugOut.flush();

}

if (debug == 1)

{

cal.setTimeInMillis(System.currentTimeMillis() );

debugOut.println(cal.getTime() + " " + cal.get(Calendar.MILLISECOND)

+ " " + "tEST_JAVASP2 - exit");

debugOut.flush();

// Close debug File

debugOut.close();

}

catch (SQLException sqle)

{

errorCode = sqle.getErrorCode();

throw new SQLException( errorCode + " FAILED" );

}

finally

{

if(debugOut!=null)

{debugOut.close(); }

}

执行存储过程后，调试信息将写入纯文本文件sp_debug.txt。可以修改这些示例以提供其他调试信息。 847是毫秒数。有更多复杂的方法来生成调试信息，例如本示例，该示例演示如何通过创建调试调用库来跟踪SQL存储过程。

清单13. sp_debug.txt中的内容

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - entry

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - preparing query

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - executed query

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - loop i=1

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - loop i=2

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - loop i=3

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - loop i=4

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - loop i=5

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - loop i=6

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - loop i=7

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - loop i=8

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - loop i=9

Wed Jul 11 16:18:11 EDT 2007 847 tEST_JAVASP2 - exit

诊断Java存储过程挂起

当Java应用程序或DB2 Java例程挂起时，我们可以生成一个javacore(也称为javadump)来确定它挂在哪里。此示例说明了如何为Java例程收集javacore。为Java应用程序生成Javacore更为简单，并且已在《 IBM JDK诊断指南》中进行了说明。

必须设置IBM JDK环境以启用javacores。对于每个平台和所使用的IBM JDK，设置过程略有不同。在我们的示例中，我们正在从JCC应用程序连接到AIX®上的DB2 V8.x服务器。请查阅《 IBM JDK诊断指南》以获取每个平台和IBM JDK的详细设置说明。

清单14.在AIX中启用Javacore

$ export JAVA_DUMP_OPTS="ONINTERRUPT(JAVADUMP),ONANYSIGNAL(JAVADUMP)"

$ export IBM_JAVACOREDIR=/db1/j2ma

$ db2set DB2ENVLIST="IBM_JAVACOREDIR JAVA_DUMP_OPTS"

$ ulimit -a

time(seconds) unlimited

file(blocks) unlimited

data(kbytes) 131072

stack(kbytes) 32768

memory(kbytes) 32768

coredump(blocks) unlimited

nofiles(descriptors) 2000

$ db2stop

SQL1064N DB2STOP processing was successful.

$ db2start

SQL1063N DB2START processing was successful.

请注意，该设置可能会略有不同，因为本示例中使用的JDK级别将与您的不同。

JAVA_DUMP_OPTS指定哪些信号将触发javacore。

IBM_JAVACOREDIR指定javacore文件的位置。

DB2ENVLIST用于将环境变量传递给db2fmp进程，因为db2start命令过滤掉了所有不以DB2 *或db2 *开头的用户环境变量。

之后，我们确保受防护的用户标识的coredump=unlimited并重新启动实例。

在此示例中，JCC应用程序在挂起且不返回的远程AIX DB2服务器上调用存储过程TEST_JAVASP。要做的第一件事是从客户端收集JCC跟踪，因为我们想知道向存储过程发送了哪些值。可能是某个特定的数据值导致挂起。

清单15.存储过程调用的JCC跟踪

[jcc][Time:2007-06-20-17:39:29.388][Thread:main][Connection@54a328]

prepareStatement (CALL JASON.TEST_JAVASP(?)) called

[jcc][Time:2007-06-20-17:39:29.420][Thread:main][Connection@54a328]

prepareStatement () returned PreparedStatement@1fc2fb

...

[jcc][Time:2007-06-20-17:39:30.967][Thread:main][PreparedStatement@1fc2fb]

executeUpdate () returned -1

[jcc][SystemMonitor:stop] core: 13.378541ms | network: 9.792076ms | server: 0.0ms

[jcc][Time:2007-06-20-17:39:30.967][Thread:main][PreparedStatement@1fc2fb]

setInt (1, 11) called

[jcc][SystemMonitor:start]

[jcc][Time:2007-06-20-17:39:30.967][Thread:main][PreparedStatement@1fc2fb]

executeUpdate () called

[jcc] [t4][time:2007-06-20-17:39:30.967][thread:main][tracepoint:1][Request.flush]

[jcc][t4] SEND BUFFER: EXCSQLSTT (ASCII) (EBCDIC)

[jcc][t4] 0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0123456789ABCDEF

[jcc][t4] 0000 007ED05100010078 200B00442113A5F9 .~.Q...x ..D!... .=}...........v9

[jcc][t4] 0010 A281949740404040 4040404040404040 ....@@@@@@@@@@@@ samp

[jcc][t4] 0020 D5E4D3D3C9C44040 4040404040404040 ......@@@@@@@@@@ NULLID

[jcc][t4] 0030 4040E2E8E2E2C8F2 F0F0404040404040 @@........@@@@@@ SYSSH200

[jcc][t4] 0040 404040405359534C 564C303100010005 @@@@SYSLVL01.... ...

从客户端进行的JCC跟踪中，我们可以看到使用输入值11调用存储过程JASON.TEST_JAVASP(？)时，最后执行的操作是executeUpdate()。DRDA缓冲区显示我们发送了EXCSQLSTT(执行SQL语句) )和SQLDTA(SQL数据)(跟踪结束时)。由于没有其他任何东西返回给客户端，因此应该调查服务器端以确定为什么什么也没有返回。请注意，由于应用程序开发人员通常无法访问服务器，因此可能需要DB2数据库管理员的帮助。有关DRDA流程的更多详细信息，请参见“ 相关主题”部分。

在服务器端，有多种显示应用程序信息的方法，例如，使用db2pd -applications -db sample ， db2 "list applications show detail"等。在我们的情况下，我们选择收集应用程序快照以找出什么是发生。在下面的示例中，JCC应用程序从客户端IP地址10.1.1.123端口2582连接。如果应用程序与DB2数据库位于同一系统上，则入站通信地址= * LOCAL.hostname 。为了从快照中识别应用程序，应用程序开发人员将需要知道应用程序名称，用户ID和它要连接的数据库。

清单16.使用快照查找与应用程序关联的db2agent的PID

Application Snapshot

Application handle = 7

Application status = UOW Executing

Status change time = Not Collected

Application code page = 819

Application country/region code = 0

DUOW correlation token = GA123456.GA16.070622200608

Application name = db2jcc_application

Application ID = GA123456.GA16.070622200608

Sequence number = 0003

TP Monitor client user ID =

TP Monitor client workstation name = majason1

TP Monitor client application name =

TP Monitor client accounting string =

Connection request start timestamp = 06/22/2007 16:06:08.388356

Connect request completion timestamp = 06/22/2007 16:06:08.865863

Application idle time = Not Collected

CONNECT Authorization ID = J2MA

Client login ID = J2MA

Configuration NNAME of client = majason1

Client database manager product ID = JCC03020

Process ID of client application = 0

Platform of client application = Unknown via DRDA

Communication protocol of client = TCP/IP

Inbound communication address = 10.1.1.123 2582

...

Coordinator agent process or thread ID = 340630

...

根据快照信息，我们看到PID 340630是db2agent进程，为对存储过程的调用提供服务。但是，由于这是Java存储过程，因此默认情况下它将在db2fmp进程中作为受防护的存储过程运行。在诸如Windows的线程系统上，这将是线程ID。

我们可以使用db2pd -fmp查找代表db2agent执行存储过程的db2fmp进程。在下面，我们看到db2fmp PID 313092中的线程2571(0xA0B)正在运行db2agent PID 340630的Java存储过程。

清单17.查找与应用程序关联的db2fmp的PID

/home/j2ma/sqllib/db2dump: db2pd -fmp

Database Partition 0 -- Active -- Up 0 days 00:00:30 -- Date 06/27/2007 15:22:43

FMP:

Pool Size: 0

Max Pool Size: 225

Keep FMP: YES

Initialized: YES

Trusted Path: /home/j2ma/sqllib/function/unfenced

Fenced User: j2ma

FMP Process:

Address FmpPid Bit Flags ActiveThrd PooledThrd Active

0x078000000016CEA0 313092 64 0x00000003 1 0 No

Active Threads:

Address FmpPid EduPid ThreadId

0x078000000016D020 313092 340630 2571

Pooled Threads:

Address FmpPid ThreadId

No pooled threads.

现在我们知道哪个PID正在运行db2fmp，如果消耗太多资源，就可以终止此过程。如果我们要进一步研究db2pd -stacks将为每个DB2进程创建一个陷阱文件。或者，我们可以发出kill -36 313092 。每个UNIX平台之间发送来生成信息性陷阱文件的信号都不同。

清单18.生成的陷阱文件t313092.000

*******************************************

* A db2fmp process received a sigpre *

* signal *

*******************************************

* Master Thread TID: 00000001 *

* Waiter Thread TID: 00002314 *

* Number of worker threads in process 00000001 *

* db2fmp flags 0000000f *

* thread list *****************************

* Thread TID: 00002571 *

*******************************************

8.1.0.128 s061108 SQL08027

timestamp: 2007-06-27-15.39.55.254086

instance name: j2ma.000

EDU name : db2fmp (Java)

Signal #36

uname: S:AIX R:2 V:5 M:0009028F4C00 N:panipuri

process id: 313092

thread id : 2314 (0x90A)

...

-------Frame------ ------Function + Offset------

0x000000000000377C ?unknown + 0x0

0x090000000027B54C _event_sleep + 0x9C

0x090000000027BAB0 _event_wait + 0x60

0x0900000000287A5C _cond_wait_local + 0x308

0x0900000000287FD0 _cond_wait + 0x44

0x0900000000288848 pthread_cond_timedwait + 0x25C

0x09000000192C3478 sqloAppWaitOnSync + 0x19C

0x090000001954DACC sqletimestamp: 2007-06-27-15.39.56.253815

instance name: j2ma.000

EDU name : db2fmp (Java)

Signal #36

uname: S:AIX R:2 V:5 M:0009028F4C00 N:panipuri

process id: 313092

thread id : 258 (0x102)

kthread id : 397831

-------Frame------ ------Function + Offset------

0x000000000000377C ?unknown + 0x0

0x0900000000280724 _p_nsleep + 0xC

0x09000000000350B4 nsleep + 0xAC

0x0900000000040964 sleep + 0x58

0x090000001F9E1E50 sysSignalWait + 0x70

0x090000003170283C signalDispatcherThread + 0xE4

0x0900000031703C58 xmExecuteThread + 0x234

0x090000003170852C threadStart + 0x30

0x090000001F9CCEC4 _start + 0x64

0x0900000000271508 _pthread_body + 0xBC

堆栈提供的信息有限，因为存储过程是独立于DB2的进程，用于运行应用程序开发人员的代码。我们可以看到DB2调用了JVM来执行Java SP。理想情况下，要进一步诊断，应用程序开发人员应在其Java SP中添加调试代码。一种替代方法是为db2fmp进程生成一个javacore文件，以提供其他信息。

由于我们已经启用了Javacores并找到了执行存储过程的db2fmp进程的PID，因此我们现在可以生成一个Javacore。 DB2会将javacore文件而不是单独的javacore文件转储到其db2diag.log中。必须使用grep命令将javacore解析出来。

清单19.生成javacore并解析db2diag.log

$ kill -QUIT $ grep MESSAGE /home/j2ma/sqllib/db2dump/db2diag.log >javadump.txt

生成javacore后，在javacore中搜索本机ID：0xA0B 。请记住，这是db2pd -fmp的线程ID输出，从2571(十进制)转换为0xA0B(十六进制)。线程0xA0B是执行挂起的Java存储过程的线程。它卡在我们应用程序的第31行中。参考清单21中的源代码，它处于无限while(1)循环中。

清单20. Javacore文件

MESSAGE : JVMDG303: JVM Requesting Java core file

MESSAGE : NULL -----------------------------------------------------------------

MESSAGE : 0SECTION TITLE subcomponent dump routine

MESSAGE : NULL ===============================

MESSAGE : 1TISIGINFO signal 3 received

MESSAGE : 1TIDATETIME Date: 2007/06/27 at 15:24:58

MESSAGE : 1TIFILENAME Javacore filename: /db1/j2ma/javacore313092.1182972298.txt

MESSAGE : 0SECTION XHPI subcomponent dump routine

MESSAGE : NULL ==============================

MESSAGE : 1XHTIME Wed Jun 27 15:24:58 2007

MESSAGE : 1XHSIGRECV SIGQUIT received at 0x7cdb02a639e00002 in .

MESSAGE : 1XHFULLVERSION J2RE 1.4.2 IBM AIX 5L for PowerPC (64 bit JVM)

build caix64142-20040917

MESSAGE : NULL

...

MESSAGE : 1XMTHDINFO All Thread Details

MESSAGE : NULL ------------------

MESSAGE : NULL

MESSAGE : 2XMFULLTHDDUMP Full thread dump Classic VM (J2RE 1.4.2 IBM AIX 5L for PowerPC

(64 bit JVM) build caix64142-20040917, native threads):

MESSAGE : 3XMTHREADINFO "Thread-0" (TID:0x7000000000B8B78, sys_thread_t:0x1130B7340,

state:R, native ID:0xA0B) prio=5

MESSAGE : 4XESTACKTRACE at TEST_JAVASP.tEST_JAVASP(TEST_JAVASP.java:31)

MESSAGE : 3XHNATIVESTACK Native Stack

MESSAGE : NULL ------------

...

清单21.存储过程的源代码

1: /* Java stored procedure to insert a value into the database.

2: * It will hang if it receives the value 11.

3: * Inputs: input value (integer)

4: * Ouputs: None

5: */

8: import java.sql.*;

10: public class TEST_JAVASP

11: {

12: public static void tEST_JAVASP (int input) throws SQLException,

13: Exception

14: {

15: int errorCode;

16:

17: try

18: {

19: // get caller's connection to the database

20: Connection con = DriverManager.getConnection("jdbc:default:connection");

21:

22: String query = "INSERT INTO T1 (C1) VALUES (?)";

23:

24: PreparedStatement pstmt = con.prepareStatement(query);

25: pstmt.setInt(1, input);

26: pstmt.executeUpdate();

27:

28: /* Cause the stored proc to not return if input value is 11 */

29: if( input == 11)

30: {

31: while(true);

32: }

33: }

34: catch (SQLException sqle)

35: {

36: errorCode = sqle.getErrorCode();

37: throw new SQLException( errorCode + " FAILED" );

38: }

39: }

40: }

使用Java应用程序诊断网络问题

清单22在下面的环境中执行JDBC应用程序。由于某些未知原因，Java应用程序似乎挂起。让我们找出问题所在。

客户端：在Windows DB2 v9.1上运行的旧版JDBC Type 2应用程序

服务器：AIX DB2 v8.x(存储过程在此系统上)

清单22.运行Java应用程序

D:\java>java CallTestJavaSPT2 sample majason 12345678

URL is: jdbc:db2:p6db

Trying to connect using Legacy JDBC T2 driver

Connected to database

Inserting value 9 into database...

Done inserting value 9

Inserting value 10 into database...

Done inserting value 10

Inserting value 11 into database...

(Ctrl-C executed from client side after a few seconds since the program above seems

to hang and never return.)

首先要做的是在客户端或运行应用程序的系统上收集跟踪。根据图1，我们看到JDBC Type 2应用程序在到达DB2客户端代码之前先经过DB2的CLI层。因此，我们将收集并发的CLI，DB2和DRDA跟踪，并为CLI和DB2跟踪启用时间戳选项。

CLI跟踪显示我们正在使用参数标记调用CALL TEST_JAVASP(？)存储过程。此存储过程被调用了三次，每次使用不同的值。我们可以看到参数标记? 绑定一次，然后执行三次SQL语句，因为在SQLBindParameter()之后对SQLExecute()进行了三个调用。每次调用SQLExecute()时，我们都可以看到用于参数标记的值。此值分别标记为iPar (输入参数编号)和rgbValue (输入参数值)。因此，对于第一个迭代，是rgbValue=9 ，然后是rgbValue=10 ，最后在挂起时是rgbValue=11 。

清单23. CLI跟踪，输入值rgbValue = 9

...

[1184187845.736027 - 07/11/2007 17:04:05.736027]

SQLPrepareW( hStmt=1:1, pszSqlStr="CALL TEST_JAVASP(?)", cbSqlStr=19 )

[1184187845.748055 - 07/11/2007 17:04:05.748055]

---> Time elapsed - +5.700000E-003 seconds

[1184187845.752649 - 07/11/2007 17:04:05.752649] ( StmtOut="CALL TEST_JAVASP(?)" )

[1184187845.758786 - 07/11/2007 17:04:05.758786]

[1184187845.761948 - 07/11/2007 17:04:05.761948] SQLPrepareW( )

[1184187845.765148 - 07/11/2007 17:04:05.765148]

Time elapsed - +3.229000E-003 seconds

[1184187845.780470 - 07/11/2007 17:04:05.780470] SQLNumParams( pcPar=1 )

[1184187845.786270 - 07/11/2007 17:04:05.786270]

Time elapsed - +1.624200E-002 seconds

[1184187845.839286 - 07/11/2007 17:04:05.839286] SQLBindParameter( )

[1184187845.842363 - 07/11/2007 17:04:05.842363]

Time elapsed - +3.261000E-003 seconds

[1184187845.854865 - 07/11/2007 17:04:05.854865]

( Package="SYSSH200 ", Section=4 )

[1184187845.863376 - 07/11/2007 17:04:05.863376]

[1184187845.880312 - 07/11/2007 17:04:05.880312]

( Row=1, iPar=1, fCType=SQL_C_LONG, rgbValue=9, pcbValue=4, piIndicatorPtr=4 )

[1184187845.901568 - 07/11/2007 17:04:05.901568]

sqlccsend( Handle - 192938080 )

sqlccsend( ulBytes - 435 )

sqlccsend( ) rc - 0, time elasped - +7.000000E-005

sqlccrecv( timeout - +0.000000E+000 )

sqlccrecv( ulBytes - 198 ) - rc - 0, time elapsed - +3.571100E-001

[1184187846.270909 - 07/11/2007 17:04:06.270909] ( return=0 )

[1184187846.277250 - 07/11/2007 17:04:06.277250]

[1184187846.280375 - 07/11/2007 17:04:06.280375] ( COMMIT REQUESTED=1 )

[1184187846.286339 - 07/11/2007 17:04:06.286339]

sqlccsend( Handle - 192938080 )

sqlccsend( ulBytes - 10 )

sqlccsend( ) rc - 0, time elasped - +6.400000E-005

sqlccrecv( timeout - +0.000000E+000 )

sqlccrecv( ulBytes - 54 ) - rc - 0, time elapsed - +4.342000E-003

[1184187846.306069 - 07/11/2007 17:04:06.306069] ( COMMIT REPLY RECEIVED=1 )

[1184187846.312165 - 07/11/2007 17:04:06.312165]

[1184187846.315283 - 07/11/2007 17:04:06.315283] SQLExecute( )

[1184187846.318434 - 07/11/2007 17:04:06.318434]

清单24. CLI跟踪，输入值rgbValue = 10

...

[1184187846.369625 - 07/11/2007 17:04:06.369625] SQLExecute( hStmt=1:1 )

[1184187846.375663 - 07/11/2007 17:04:06.375663]

---> Time elapsed - +6.313000E-003 seconds

[1184187846.378759 - 07/11/2007 17:04:06.378759]

( Row=1, iPar=1, fCType=SQL_C_LONG, rgbValue=10, pcbValue=4, piIndicatorPtr=4 )

[1184187846.401220 - 07/11/2007 17:04:06.401220]

sqlccsend( Handle - 192938080 )

sqlccsend( ulBytes - 157 )

sqlccsend( ) rc - 0, time elasped - +6.700000E-005

sqlccrecv( timeout - +0.000000E+000 )

sqlccrecv( ulBytes - 80 ) - rc - 0, time elapsed - +8.489000E-003

[1184187846.422672 - 07/11/2007 17:04:06.422672] ( return=0 )

[1184187846.428435 - 07/11/2007 17:04:06.428435]

[1184187846.432088 - 07/11/2007 17:04:06.432088] ( COMMIT REQUESTED=1 )

[1184187846.438348 - 07/11/2007 17:04:06.438348]

sqlccsend( Handle - 192938080 )

sqlccsend( ulBytes - 10 )

sqlccsend( ) rc - 0, time elasped - +6.100000E-005

sqlccrecv( timeout - +0.000000E+000 )

sqlccrecv( ulBytes - 54 ) - rc - 0, time elapsed - +3.608000E-003

[1184187846.454256 - 07/11/2007 17:04:06.454256] ( COMMIT REPLY RECEIVED=1 )

[1184187846.460343 - 07/11/2007 17:04:06.460343]

[1184187846.464846 - 07/11/2007 17:04:06.464846] SQLExecute( )

[1184187846.468118 - 07/11/2007 17:04:06.468118]

清单25. CLI跟踪，输入值rgbValue = 11

...

[1184187846.519822 - 07/11/2007 17:04:06.519822] SQLExecute( hStmt=1:1 )

[1184187846.526027 - 07/11/2007 17:04:06.526027]

---> Time elapsed - +6.523000E-003 seconds

[1184187846.529060 - 07/11/2007 17:04:06.529060]

( Row=1, iPar=1, fCType=SQL_C_LONG, rgbValue=11, pcbValue=4, piIndicatorPtr=4 )

[1184187846.549404 - 07/11/2007 17:04:06.549404]

sqlccsend( Handle - 192938080 )

sqlccsend( ulBytes - 157 )

sqlccsend( ) rc - 0, time elasped - +7.100000E-005

sqlccrecv( timeout - +0.000000E+000 )

在第三次迭代期间，CLI跟踪在SQLExecute()之后结束。下一步是简化应用程序并将其从图片中删除。我们可以创建一个DB2脚本来执行与上述相同的功能。

清单26. test.db2

connect to sample user db2inst1 using 12345678;

call test_javasp(9);

call test_javasp(10);

call test_javasp(11);

terminate;

在服务器端执行脚本将有助于将问题隔离到客户端或服务器端问题。如果脚本在客户端运行良好，则应在服务器端运行。如果它在服务器端挂起，则需要检查存储过程。

对于我们的示例，假设脚本在服务器端运行良好，但在客户端失败。由于脚本无法在客户端上运行，因此我们可以排除应用程序层的任何问题，即JDBC到DB2 CLI的接口，因为DB2 CLP绕过了应用程序层。我们也可以排除服务器端。

再次参考图1 。我们看到在应用程序层下面是DB2客户机和DRDA通信层。因此，我们将通过检查DB2和DRDA跟踪来继续研究这两层的网络延迟。任何其他可能的问题都应由DB2技术支持进行审查。

打开DRDA跟踪，并找到要使用输入参数发送CALL TEST_JAVASP(？)的跟踪点。我们可以看到输入值的每次迭代都对应于它自己的DB2跟踪点。在跟踪点49130上的FDODTA = 9，在跟踪点50460上的FDODTA = 10，最后在跟踪点51714上的FDODTA = 11。请注意，在DRDA术语中，AR(应用程序请求者)是客户端，而AS(应用程序服务器)是服务器。可以在“ 相关主题”部分中找到有关在客户端和服务器之间发送的DRDA流的更多信息。

清单27. CALL TEST_JAVASP(9)的DRDA跟踪

49130data DB2 UDB DRDA Communication Manager sqljcSend fnc (3.3.54.5.0.1177)

pid 2088 tid 2484 cpid 526 node 0 sec 223545 nsec 574400066 probe 1177

bytes 452

SEND(AR) OBJDSS - Object Data Stream Structure

LL: 35 CORR: 0003 CHAINED: y CONT ON ERR: n SAME CORR FOR NEXT DSS: n

NM: SQLSTT - SQL Statement

LL: 29 CP: 2414

DATA: (ASCII) (EBCDIC)

000000001343414C 4C20544553545F4A .....CALL TEST_J .......<

我们看到SEND(AR)，它是来自客户端的发送缓冲区。 SQLDTA(SQL DATA结构)说，我们在CALL TEST_JAVASP(？)中输入9作为参数标记

清单28. CALL TEST_JAVASP(10)的DRDA跟踪

50460data DB2 UDB DRDA Communication Manager sqljcSend fnc (3.3.54.5.0.1177)

pid 2088 tid 2484 cpid 526 node 0 sec 223546 nsec 533380764 probe 1177

bytes 174

SEND BUFFER(AR):

EXCSQLSTT RQSDSS (ASCII) (EBCDIC)

0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0123456789ABCDEF

0000 0079D05100010073 200B004421135341 .y.Q...s ..D!.SA .`}.............

0010 4D504C4520202020 2020202020202020 MPLE (&

现在是10(十进制)或0xA(十六进制)。从带有时间戳的相应流文件(trace.flw)中，我们可以看到我们调用了sqlcctcpsend()，它是操作系统的TCP / IP API的包装器，用于发送数据。此发送花了不到1秒的时间。如果存在网络延迟，则应在此处显示。

清单29. trace.flw

50480 33:650976401 | | | | | clientCommCallback exit

50481 33:650984989 | | | | sqljcSend exit

50482 33:650989272 | | | | sqljrRecv entry

50483 33:650989982 | | | | | sqljcReceive entry

50484 33:650993253 | | | | | | clientCommCallback entry

50485 33:651003619 | | | | | | | CLI_utlGetInfo entry

50486 33:651005423 | | | | | | | CLI_utlGetInfo exit

50487 33:651008072 | | | | | | | sqlrxf2a entry

50488 33:651021647 | | | | | | | sqlrxf2a data [probe 4]

50489 33:651022705 | | | | | | | sqlrxf2a exit

50490 33:656536851 | | | | | | clientCommCallback exit

50491 33:656547857 | | | | | | sqlccrecv entry

50492 33:656549136 | | | | | | sqlccrecv data [probe 1]

50493 33:656551339 | | | | | | sqlccrecv data [probe 2]

50494 33:656551992 | | | | | | sqlccrecv data [probe 3]

50495 33:656552653 | | | | | | sqlccrecv data [probe 4]

50496 33:656553245 | | | | | | sqlccrecv data [probe 120]

50497 33:656554490 | | | | | | sqlccrecv data [probe 130]

50498 33:656556542 | | | | | | | sqlcctcprecv entry

50499 33:656557298 | | | | | | | sqlcctcprecv data [probe 1]

50500 33:656561269 | | | | | | | | tcprecv entry

50501 33:237234851 | | | | | | | | tcprecv data [probe 2]

50502 33:237247868 | | | | | | | | tcprecv exit

50503 33:237256312 | | | | | | | sqlcctcprecv exit

50504 33:237258748 | | | | | | sqlccrecv data [probe 5]

50505 33:237259658 | | | | | | sqlccrecv exit

清单30. CALL TEST_JAVASP(11)的DRDA跟踪

51714data DB2 UDB DRDA Communication Manager sqljcSend fnc (3.3.54.5.0.1177)

pid 2088 tid 2484 cpid 526 node 0 sec 223546 nsec 816354478 probe 1177

bytes 174

SEND BUFFER(AR):

EXCSQLSTT RQSDSS (ASCII) (EBCDIC)

0 1 2 3 4 5 6 7 8 9 A B C D E F 0123456789ABCDEF 0123456789ABCDEF

0000 0079D05100010073 200B004421135341 .y.Q...s ..D!.SA .`}.............

0010 4D504C4520202020 2020202020202020 MPLE (&

在最后一次迭代( 清单30 )中，当使用11(十进制)或B(十六进制)调用存储过程时，我们在DRDA跟踪中找到跟踪点51714，它对应于流文件中的同一跟踪点。在内部，我们看到已执行发送，但是在tcprecv()(TCP / IP接收)期间，跟踪点51754和51755之间存在〜7s的延迟。这表明该问题是DB2的外部问题，应由网络管理员调查。问题可能出在客户端和服务器之间的操作系统的TCP / IP堆栈或网络设备(即防火墙，负载平衡设备，路由器等)中。

清单31. trace.flw

51714 33:922051842 | | | | sqljcSend data [probe 1177]

...

51735 33:934285388 | | | | sqljcSend exit

51736 33:934290007 | | | | sqljrRecv entry

51737 33:934290717 | | | | | sqljcReceive entry

51738 33:934294324 | | | | | | clientCommCallback entry

51739 33:934304206 | | | | | | | CLI_utlGetInfo entry

51740 33:934306048 | | | | | | | CLI_utlGetInfo exit

51741 33:934309009 | | | | | | | sqlrxf2a entry

51742 33:934322190 | | | | | | | sqlrxf2a data [probe 4]

51743 33:934323299 | | | | | | | sqlrxf2a exit

51744 33:939817767 | | | | | | clientCommCallback exit

51745 33:939828871 | | | | | | sqlccrecv entry

51746 33:939830244 | | | | | | sqlccrecv data [probe 1]

51747 33:939832445 | | | | | | sqlccrecv data [probe 2]

51748 33:939833093 | | | | | | sqlccrecv data [probe 3]

51749 33:939833764 | | | | | | sqlccrecv data [probe 4]

51750 33:939834387 | | | | | | sqlccrecv data [probe 120]

51751 33:939835606 | | | | | | sqlccrecv data [probe 130]

51752 33:939837978 | | | | | | | sqlcctcprecv entry

51753 33:939838688 | | | | | | | sqlcctcprecv data [probe 1]

51754 33:939842723 | | | | | | | | tcprecv entry

51755 154:211882227 | | | | | | | | tcprecv data [probe 2]

51756 154:211896294 | | | | | | | | tcprecv exit

51757 154:211904245 | | | | | | | sqlcctcprecv exit

51758 154:211906988 | | | | | | sqlccrecv data [probe 5]

51759 154:211907763 | | | | | | sqlccrecv exit

...

诊断身份验证问题

当用户连接到数据库或附加到DB2实例时，认证由DB2外部的安全设施执行。安全设施通常由DB2所在的操作系统提供。根据配置，可以在服务器或客户端上进行身份验证。 DB2支持各种认证方法。 Further authentication information can be found in the DB2 Information Center, from the link in the Resources section .

A user which is on the same system as the database can connect using an implicit connect in which no user id and password are required or explicit connect in which a user id and password must be used. Connections to remote databases will usually require an explicit connect unless the server was configured for client authentication. When troubleshooting authentication issues, do not use an implicit connect because this bypasses any authentication mechanisms.

Troubleshooting authentication issues should be performed from outside the Java application via the DB2 CLP. Assuming that authentication has been configured to take place on the server. If an implicit connect executes quickly but an explicit connect exhibits a slow connect then there is likely a performance issue with authentication. Another indication of an authentication performance issue is that the initial time needed to establish a connect takes a long time, but there is no query response degradation for subsequent queries.

Listing 32. Explicit versus implicit authentication

$ db2 "connect to sample user db2inst1 using mypassword"

Database Connection Information

Database server = DB2/AIX64 8.2.7

SQL authorization ID = DB2INST1

Local database alias = SAMPLE

$ db2 "connect to sample"

Database Connection Information

Database server = DB2/AIX64 8.2.7

SQL authorization ID = DB2INST1

Local database alias = SAMPLE

On the AIX platform, DB2 uses the OS API getpwnam_r to get the user attributes. The AIX OS API getpwnam_r is a thread safe version of getpwnam. Following sample C program demonstrates the getpwnam_r and getpwnam calls.

Listing 33. Sample program calling O/S authentication APIs

#include #include #include #include #include #include int main(int argc, char *argv[])

{

int err = 0;

int rc = 0;

struct passwd *pResult = NULL;

struct passwd passwordData;

char *pBuffer = (char *)malloc(256);

if (argc != 2)

{

printf("Usage: %s \n", argv[0]);

exit (1);

}

pResult = getpwnam(argv[1]);

if (pResult == NULL)

{

err = errno;

printf("\n1: err: %d", err);

}

else

{

printf("getpwnam returned OK. \n");

}

rc = getpwnam_r(argv[1],

&passwordData,

pBuffer,

256,

&pResult);

if ((rc != 0) || (pResult == NULL))

{

err = errno;

printf("\n2: err: %d, rc: %d\n", err, rc);

}

else

{

printf("getpwnam_r returned OK. \n");

}

Save the code above as testgetpwnam.C and compile it generating the executable a.out. The command runs the program a.out that looks up user bianca and writes the amount of real, user, and system time to standard error.

Listing 34. Executing testgetpwnam program

$ xlc testgetpwnam.C

$ time ./a.out bianca

getpwnam returned OK.

getpwnam_r returned OK.

real 0m0.80s

user 0m0.01s

sys 0m0.00s

The output of ./a.out bianca shows user bianca is found by operating system calls getpwnam() and getpwnam_r() in addition to the time spent during execution. If execution time appears to be excessive, the AIX admin should be engaged to investigate the cause of delay that occurred in AIX

On the Windows platform, DB2 supports access tokens. Because access tokens are cached, this increases authentication performance. The access token support is enabled by using by setting the DB2 registry variable DB2_GRP_LOOKUP to TOKEN, TOKENLOCAL or TOKENDOMAIN. Access token support can be enabled with all authentication types except CLIENT authentication.

Listing 35. Windows authentication DB2 registry variables

db2set DB2_GRP_LOOKUP=,TOKEN

db2set DB2_GRP_LOOKUP=LOCAL,TOKENLOCAL

db2set DB2_GRP_LOOKUP=DOMAIN,TOKENDOMAIN

More information on DB2 access tokens can be found DB2 Information Center. Link from the