您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
电路与系统专业论文-soc低功耗物理设计中电源网络分析与研究.pdf54页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
文档加载中...广告还剩秒
需要金币：200 &&
电路与系统专业论文-soc低功耗物理设计中电源网络分析与研究
你可能关注的文档：
··········
··········
声 明 本学位论文是我在导师的指导下取得的研究成果，尽我所知，在
本学位论文中，除了加以标注和致谢的部分外，不包含其他人已经发
表或公布过的研究成果，也不包含我为获得任何教育机构的学位或学
历而使用过的材料。与我一同工作的同事对本学位论文做出的贡献均 已在论文中作了明确的说明。
研究生签名： 瑚侈年弓月 瑁 学位论文使用授权声明 南京理工大学有权保存本学位论文的电子和纸质文档，可以借阅
或上网公布本学位论文的部分或全部内容，可以向有关部门或机构送
交并授权其保存、借阅或上网公布本学位论文的部分或全部内容。对
于保密论文，按保密的有关规定和程序处理。
研究生签名： 加侈年弓月2瑁
硕士论文 SOC低功耗物理设计中电源网络分析 摘 要 On 随着半导体工艺水平越来越先进，集成电路的发展进入到片内系统 SystemChip，
SOC 的时代。芯片的规模越来越大，能达到上千万门，而如此大规模的晶体管带来的
功耗问题急需解决。数字集成电路物理设计是集成电路设计中的重要组成部分。物理设
计中电源网络的规划，其性能的优劣直接影响到数字集成电路片内系统能否正常工作， 因此，对其进行研究具有重要的意义。本文将对SOC物理设计的电源网络情况进行详
细的研究。 本文首先介绍了集成电路设计中功耗的组成理论。影响静态功耗以及动态功耗的因
素，从器件结构上考虑降低静态功耗的方法以及动态功耗中的开关功耗和瞬间的短路功
耗的计算方法，总结低功耗设计优化的方向。然后基于对SOC功耗工作原理的研究，
变频等手段来进行低功耗的设计规划。根据规划的结果，在物理设计的阶段，运用EPS
设计电源网格视图，
正在加载中，请稍后...403 Forbidden
403 Forbidden　　应用程序开发人员和数据库管理员每天面临的一项挑战就是处理性能问题。虽然很多性能问题与数据库服务器有关，但也有一些性能问题与客户机应用程序有关。本文深入分析如何从应用程序客户机的角度诊断和隔离性能问题。您将学习如何排除使用
应用程序中出现的性能问题。一旦理解了性能问题的根源所在，离找到解决方案也就不远了。
　　问题诊断和
　　本文的目的是帮助应用程序开发人员或数据库管理员排除和诊断在部署
应用程序时可能遇到的常见性能问题。其中包括常见的应用程序开发问题，例如挂起或者响应缓慢。
　　很好地理解
应用程序驱动程序和常见的
组件，对于有效地排除和诊断
应用程序的问题很重要。DB2
客户端由几个层组成，每个组件都有它自己的跟踪实用程序，用于供给独特的信息，以帮助诊断不同类型的应用程序问题。所以在开始讨论不同的诊断工具之前，我们首先来看看
的客户机-服务器架构。
在客户端和服务器端使用的软件栈。
有两种法子可以连接到
是最常用的配置。在此，诸如
客户机是与应用程序一起安装的。DB2
driver（也称
　　第二种法子，即
2，不需要安装
客户机，而是使用
driver（也称
T4），后者可以单独下载。为了使用
driver，应用程序开发人员必须在应用程序使用的
db2jcc.jar
和许可文件
db2jcc_license_*.jar。这两种类型的客户机都使用一种称作
Distributed
Relational
Architecture（DRDA）的开放数据库通信标准与
数据库服务器通信。
客户机/服务器架构
客户机供给很多类型的应用程序接口。图
显示了应用层，其中详述了可以与
一起使用的应用程序类型。其中大多数应用程序都通过
Interface（CLI）。JCC
驱动程序只限于
应用程序，因为这是一个基于
的应用程序。当出现问题时，取决于使用的应用程序的类型，应用程序开发人员可以收集下面描述的跟踪信息的组合。
Trace：大多数应用程序通过
跟踪：在用户应用程序下和在
通信层跟踪
客户端的内部工作情况。也可用于跟踪服务器端的问题。
跟踪：这是用于使用
的应用程序的一个单独的跟踪实用程序。
跟踪：跟踪遗留
driver；但是不常用，因为对这一层的调用将被向下传递到
应用层详图
　　下面是在故障诊断时要记住的一些关键概念：
　　使用自上而下的法子进行故障诊断，而不是盯着细节，试图弄清楚那些细节是否与当前问题有关。
　　理解环境和配置。
　　应用程序在哪里运行？
　　数据库驻留在哪里？
　　每个系统上使用何种平台、何种操作系统和什么版本（修复包级别）的
　　尽可能地简化环境和应用程序。
　　从应用程序的外面执行相同的查询是否会表现出相同的行为？
　　与从客户端运行查询相比，从服务器运行查询是否可以产生相同的响应？
　　注意最近的任何软件或硬件的变化。
　　只有在理解了环境并简化了问题域之后，才使用可用的跟踪功能向下探索以发现根本原因。
　　在客户端和服务器端应用程序以及
日志中查找相应的消息。
　　Developer
调试功能概述
　　Developer
供给一个全面的开发环境，为
例程的开发和调试供给了便利。当创建一个存储过程时，应该在调适模式下创建例程。
为新的存储过程启用调试
　　现在可以在存储过程中创建一些断点，然后单击
对话框开始调试。
#p#分页标题#e#
　　在下面的屏幕快照中，调试器在每个断点处停下，并显示程序中的变量的当前状态。
调试存储过程
调试存储过程
　　Developer
应用程序的一个方便的工具。但是，当存在性能问题时，应用程序开发人员就可能不知道哪个
例程或哪部分代码的性能有缺陷。DB2
功能可用于向下探索和隔离导致问题的应用程序。
Connectivity
驱动程序是
数据库服务器的一个可调用
接口。JDBC
driver、DB2
module(DBD:DB2)、PHP
DB2、IBM_DB
.NET/ADO/OLEDB
供给程序构建在
Connectivity
驱动程序之上。
Connectivity
驱动程序中内建的跟踪功能。所有直接或间接访问
层的应用程序都可以使用
来跟踪。DB2
包含不同的时间信息，这些信息可用于诊断应用程序的性能问题。
函数显示一个向外箭头（指向右边）和一个向内箭头（指向左边）。向外箭头显示自上次的
调用以来在应用程序中花费的时间。向内箭头显示在
客户机之外花费的时间，包括网络时间（来回）和在
服务器上花费的时间。例如，SQLExecute()
调用中显示的
执行时间加上网络时间组成。可以提取出
SQLPrepareW()
语句，然后在数据库服务器的
CLP（命令行处理器）上本地运行它。如果在服务器上运行所花的时间要少得多，那么延迟可能是在网络层。
　　如果在服务器上的运行时间大致相同，那么
就必须调优服务器和
SQLExecute()
中的执行时间
SQLPrepareW(
hStmt=1:1,
pszSqlStr=select
cbSqlStr=31
StmtOut=select
...　　　　　　　　　　　　　　　　
SQLExecute(
)　　　　　　　　　　　　　　　　　　　　　　　　　
seconds　　　　　　　　　　　　　　
Package=SYSSH200　　　　　,
)　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　sqlccsend(
)　　　　　　　　　　　　　　　　　　　
　　sqlccsend(
)　　　　　　　　　　　　　　　　　　　　　　
　　sqlccsend(
+4.5　　　　　　　　　　
　　sqlccrecv(
)　　　　　　　　　　　　　　　　
　　sqlccrecv(
Attributes=3
)　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
Attributes=524298
)　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
Attributes=524299
)　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
SQLExecute(
)　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
SQL_SUCCESS　
　　下面的
跟踪输出显示在
SQLGetConnectAttr()
SQLColAttributesW()
之间在应用程序中花费的时间为
秒）。换句话说，应用程序中出现了
秒的延迟。如果那样的延迟超出了预期，那么应用程序开发人员应该调查应用程序代码。
#p#分页标题#e#
应用程序中的执行时间
SQLGetConnectAttr(
fOption=SQL_ATTR_AUTOCOMMIT,
pvParam=0c53fdf0,
　　cbParamMax=-4,
pcbParam=NULL
SQLGetConnectAttr(
SQL_SUCCESS　
SQLColAttributesW(
hStmt=1:1,
fDescType=SQL_DESC_SCHEMA_NAME,
　　rgbDesc=0c53fd10,
cbDescMax=200,
pcbDesc=0c53fde0,
pfDesc=0c53fdd8
　　sqlccsend(
　　sqlccsend(
　　sqlccsend(
　　sqlccrecv(
　　sqlccrecv(
SQLColAttributesW(
pCharAttribute=MING　　,
psCharAttributeByteLen=16
SQL_SUCCESS　
　　下面的
跟踪显示一个连接花费了
秒）。如果只在连接期间观察到这样的延迟，那么可能是认证延迟的症状。欲了解更多细节，请参阅诊断认证问题小节。
SQLDriverConnect()
中的执行时间
SQLDriverConnect(
szConnStrIn=DSN=UID=
PWD=********;AUTOCOMMIT=0;CONNECTTYPE=1;,
cbConnStrIn=-3,
szConnStrOut=0bf9de64,
cbConnStrOutMax=256,
pcbConnStrOut=0bf9e044,
fDriverCompletion=SQL_DRIVER_NOPROMPT
sqlccsend(
sqlccsend(
sqlccsend(
sqlccrecv(
sqlccrecv(
sqlccsend(
sqlccsend(
sqlccsend(
sqlccrecv(
sqlccrecv(
NAME=DB2/AIX64,
Version=08.02.0004,
Fixpack=0x
Application
Codepage=1252,
Codepage=819,
Codepage=1252,
Codepage=1200
SQLDriverConnect(
szConnStrOut=DSN=UID=;PWD=********;
DBALIAS=DPMP;AUTOCOMMIT=0;CONNECTTYPE=1;,
pcbConnStrOut=74
SQL_SUCCESS
　　当利用
跟踪调查性能问题时，重要的是使用
TRACECOMM，另外还可以选择使用关键字
TRACETIMESTAMP，，因为这两个关键字将跟踪额外的时间信息，并将该信息写入到
跟踪文件中，从而更方便发现跟踪中的延时。
跟踪功能概述
跟踪可用于跟踪客户端上应用程序之下的层。它还可以用于跟踪服务器端。
　　可以使用带时间戳的
跟踪来发现网络缓慢的问题。
下面是可以在客户端上使用的跟踪：
　　输入命令
　　通过从
语句重新创建性能问题。
　　输入命令
　　跟踪被关闭后，在发出
命令的路径中将生成一个二进制
文件。在这里，这个
trc.dmp，为了使该文件可读，必须将其流化（flw）和款式化（fmt）为
文件。使用
将生成一个
　　例如：
　　db2trc
　　db2trc
　　db2trc
trc_drda.fmt
　　应该注意的是，这个过程需要与收集
文件必须在相同的
修复包级别上执行。流文件（trc.flw）列出每个进程和线程做出的函数调用。款式文件（trc.fmt）将供给关于每个
函数的详细信息，顺序与写到跟踪文件的顺序一致。如果
选项发出的，那么可以用
文件，如下所示。
　　db2trc
　　上面的命令创建一个带时间戳的
跟踪流文件。清单
跟踪流文件的一个示例。第二列是时间戳，其款式为
ssss:nnnnnnnnn。其中
表示秒，nnnnnnnnnn
表示纳秒。
带时间戳的
sqlcctcprecv
sqlcctcprecv
sqlcctcprecv
#p#分页标题#e#
依赖于操作系统应用程序编程接口来执行网络通信。可以将上面的
调用的一个包装器。recv()函数从一个连接套接字接收数据。如清单
所示，tcprecv()
1485）来接收数据。这
秒由服务器响应时间和网络时间完成。如果在服务器上从
执行相同的
语句花的时间要少得多，那么最值得怀疑的是网络缓慢，网络管理员需要进行调查。
显示如何使用
db2diag.log
中的返回码。
解释返回码
E:db2v8BINdb2diag
'fffffb95'
0xFFFFFB95
(-1131）。
../sqz/sqlzwhatisrc.C:
0xFFFFFB95
0x83000B95
Equivalent
0xFFFFBB95
Unexpected
Component:
(Component
v8.1.14.292;
Attempting
0xFFFFFB95
SQL1131N　DARI
Procedure)
terminated
abnormally.
　　当判断在收到错误消息之前已经发生或正在发生的操作、性能问题或挂起时，需要使用
跟踪。如果没有这种类型的信息，就难以断定应用程序如何进入这种状态。JCC
跟踪应该在包含
应用程序的系统上运行。
跟踪的头部供给一组有用的环境信息，例如：
　　操作系统和环境变量。该信息可用于断定我们是否在使用多个版本的
或应用程序库。
　　应用程序用于连接的
的版本和供应商。确认
级别和使用的
数据库的版本。
驱动程序级别对应于一个
修复包，如
v9.x）所示。表
显示了从一个
跟踪返回的产品标识。
1.0GA（General
Availability
2.7.58FP10
introduced
2.8.46FP11
2.9.31FP12
2.10.27FP13
2.10.52FP14
3.1.57GA（General
Availability
跟踪的产品版本
数据库产品版本DB2
Linux/Unix/Windows
Linux/Unix/Windows
DSN07012DB2
DSN08015DB2
V05R04M00DB2
跟踪可以看到，JCC
应用程序在
运行，它使用
(DSN08015)
上的数据库
[ibm][db2][jcc]
TRACE_DRIVER_CONFIGURATION
[ibm][db2][jcc]　Driver:
Architecture
[ibm][db2][jcc]
Compatible
[ibm][db2][jcc]
restrictions:
Unix/Windows:
Cloudscape:
[ibm][db2][jcc]
[ibm][db2][jcc]
[ibm][db2][jcc]
[ibm][db2][jcc]
isolation:
[ibm][db2][jcc]
performance
statistics:
[ibm][db2][jcc]
[ibm][db2][jcc]
[ibm][db2][jcc]
[ibm][db2][jcc]
jdbc.drivers
[ibm][db2][jcc]　Java
Environment
[ibm][db2][jcc]
Environment
Microsystems
[ibm][db2][jcc]
[ibm][db2][jcc]
installation
/apps/j2re1.4.2_07
[ibm][db2][jcc]
specification
[ibm][db2][jcc]
specification
Microsystems
[ibm][db2][jcc]
specification
Specification
[ibm][db2][jcc]
implementation
1.4.2_07-b05
[ibm][db2][jcc]
implementation
Microsystems
[ibm][db2][jcc]
implementation
HotSpot(TM)
[ibm][db2][jcc]
Environment
specification
[ibm][db2][jcc]
Environment
specification
Microsystems
[ibm][db2][jcc]
Environment
specification
Specification
[ibm][db2][jcc]
[ibm][db2][jcc]
:/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_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]
/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]
directories
/apps/j2re1.4.2_07/lib/ext
[ibm][db2][jcc]　Operating
[ibm][db2][jcc]　Operating
architecture
[ibm][db2][jcc]　Operating
[ibm][db2][jcc]
[ibm][db2][jcc]
[ibm][db2][jcc]
User's
[ibm][db2][jcc]
User's
/home/admin
[ibm][db2][jcc]
User's
/apps/jakarta-tomcat-5.5.7/bin
[ibm][db2][jcc]
properties
/apps/jakarta-tomcat-5.5.7/webapps/ivs/WEB-INF/classes/DB2JccConfiguration.properties
[ibm][db2][jcc]
ClassLoader:
WebappClassLoader
[ibm][db2][jcc]
TRACE_DRIVER_CONFIGURATION
[ibm][db2][jcc]
TRACE_CONNECTS
[ibm][db2][jcc]
Attempting
connection
:50000/SAMPLE
[ibm][db2][jcc]
properties:
traceFile/tmp/jcctrace.txt,
user=DB2INST1,
password=********}
[ibm][db2][jcc]
TRACE_CONNECTS
[ibm][db2][jcc][Connection@16fa474]
TRACE_CONNECTS
[ibm][db2][jcc][Connection@16fa474]　Successfully
jdbc:db2://:50000/SAMPLE
[ibm][db2][jcc][Connection@16fa474]
[ibm][db2][jcc][Connection@16fa474]
[ibm][db2][jcc][Connection@16fa474]　Database
[ibm][db2][jcc][Connection@16fa474]
Architecture
[ibm][db2][jcc][Connection@16fa474]
[ibm][db2][jcc][Connection@16fa474]
Application
Correlator:
G41E4EB2.GA90.C0E00
[ibm][db2][jcc][Connection@16fa474]
TRACE_CONNECTS
#p#分页标题#e#
　　性能问题通常可以分为两类：间歇性的（intermittent）和非间歇性的（non-intermittent）。
间歇性问题难以排除，因为这些问题可能随着工作负载或应用程序运行的机会而在任意时候发生。对于诊断间歇性性能问题，可以使用的一个非常有用的工具是
该工具可以设置为执行一个脚本，该脚本用于在返回指定错误消息时收集诊断信息。这种工具的缺点是，它是在错误发生之后才收集信息的。这个工具的一个理想的用途是当数据库服务器达到一个容量阈值时捕捉快照信息。例如，当超过最大
不能接受新连接时，应用程序返回
(SQL1224)。
　　可以编写一个名为
脚本，其中包含您想要在
错误时运行的任何操作系统或
命令。注意，该脚本必须命名为
db2cos；否则
不会执行它。
information
Collecting
information
SQL1224db2cos.rpt
db2cos.rpt
db2cos.rpt
脚本完成之后，如何安装调出脚本。如果错误消息与锁有关，则在
脚本中还应该收集锁快照。
/home/db2inst1/sqllib
'-1224'
0xFFFFFB38
(-1224）。
　　　　Sqlcode:　　　　-1224
　　　　ReasonCode:　　
　　　　ZRC:　　　　　　0
　　　　ECF:　　　　　　0
　　　　Component
　　　　LockName:　　　
　　　　LockType:　　　
　　　　Current
　　　　Max
Count:　　　255
　　　　Bitmap:　　　　
　　　　Action:　　　　
　　　　Action:　　　　
sqllib/db2cos
　　　　Action:　　　　
db2diag.log　　　　
　　可重复的或非间歇性的问题诊断起来要容易得多，因为可以使用跟踪收集更多的诊断信息。
应用程序的性能问题可以分为
　　执行慢
　　错误消息
　　通常，上述第
类（错误消息）问题最容易诊断，因为有返回的错误消息。在这种情况下，只需根据在客户端上运行的导致错误消息的应用程序的类型收集适当的跟踪。通常，通过查看跟踪就可以得到足够的信息来解决问题。下一节演示如何诊断前三种情况。
例程实现概述
　　在诊断
例程（可定义为存储过程或用户定义函数）的问题之前，有必要回顾一下
例程是如何调用的。默认情况下，DB2
之外开始一个名为
的进程，以运行隔离的
例程。之所以采取这样的预防性措施，是因为
要运行应用程序开发人员所编写的未知的代码。如果出现一个异常，最坏的情况只是
进程被终止，而不会使整个数据库停止工作。这种增加的灵活性还可以在劣质的
例程消耗太多的内存或
时终止它们。如果
例程不加隔离地在
中运行，而不是在
进程中运行，那么一个异常就会使整个数据库停止工作。
　　除了将
例程定义为
外，还可以将它们定义为
THREADSAFE
THREADSAFE。不同之处在于，THREADSAFE
例程是作为
进程中的一个线程运行的。而
THREADSAFE
例程在一个单独的
进程中运行。默认情况下，DB2
例程创建为
THREADSAFE。由于
进程是使用隔离
运行的，因此它的资源限制由它的用户限制决定。
显示了如何发现和修改隔离
/home/db2inst1/sqllib/adm:
-rw-r--r--　
nobody　nobody　　　　　　
/home/db2inst1/:
SQL1064N　DB2STOP
processing
successful.
/home/db2inst1/:
/home/db2inst1/sqllib/adm/.fenced
/home/db2inst1/:
SQL1063N　DB2START
processing
successful.
/home/db2inst1/sqllib/adm:
-rw-r--r--　
db2fenc1　fencgrp　　　　　　
#p#分页标题#e#
　　当一个应用程序连接到
时，将有一个或多个
进程被分配给这个应用程序，用以运行查询。当应用程序调用一个
例程时，db2agent
进程之间的通信通过
Communication
Pool，后者由
注册表变量
DB2_FMP_COMM_HEAPSZ
DB2_FMP_COMM_HEAPSZ
的大小将决定可以在一个实例中运行的并发例程的最大数量。
例程是如何被调用的。
例程执行慢的问题
　　如前面
所示，既有客户端组件，也有服务器端组件，两者各由多个层组成。首先要断定问题是在客户端还是服务器端。为了排除是
导致问题的可能性，可以从客户端命令行处理器调用该存储过程（如果适用的话），并检查响应时间是否可以接受。
　　如果响应时间还是比较长，或者与从应用程序中调用这个存储过程的时间差不多，那么可以确定，应用程序不是罪魁祸首。在这种情况下，接下来可以从服务器的命令行处理器调用这个存储过程。如果响应时间较长，那么数据库管理员应该调查服务器端。性能问题可能是由于配置不当、调优问题或者执行例程时优化器使用了不好的访问计划导致的。
　　如果不是这样，那么我们可以确定性能下降要么是出现在
客户机代码中，要么是出现在网络上。
此时，可以收集一个带时间戳选项的
跟踪，以断定是哪个函数用了最长的时间才返回。例如，我们是在等
吗？有些应用程序使用参数占位符调用例程，因此需要收集
跟踪，以捕捉输入参数。应用程序端的日志也可能包含这样的信息。
　　找出慢的存储过程之后，应用程序开发人员应该在
例程中添加调试代码，以判断性能瓶颈出在什么地方。添加调试代码的最容易的法子是将
语句添加到
是创建用于存储调试信息的
表的脚本。
创建调试表的
sp_debug(sp_name
varchar(100),
timestamp,
trace_point
varchar(100));
将调试信息写到表中
java.sql.*;
java.io.*;
TEST_JAVASP3
tEST_JAVASP3　(int
SQLException,
　　Exception
　　Connection
　　Statement
　　PreparedStatement
　　　　　
　　　　//
caller's
connection
DriverManager.getConnection(jdbc:default:connection);
statements
　　debug_st
dbCon.createStatement();
　　debug_st.execute(INSERT
values('test_javasp3',
　　　　current
timestamp,
1,'entry'));
　　　　String
　　debug_st.execute(INSERT
values('test_javasp3',
　　　　current
timestamp,
2,'prepare'));
　　　　pstmt
dbCon.prepareStatement(query);
　　　　pstmt.setInt(1,
　　　　pstmt.executeUpdate();
　　　debug_st.execute(INSERT
values('test_javasp3',
　　　　　current
timestamp,
3,'executeUpdate'));
　　　　　while(true);　　
　　debug_st.execute(INSERT
values('test_javasp3',
　　　　current
timestamp,
4,'done
if'));
　　debug_st.execute(INSERT
values('test_javasp3',
　　　　current
timestamp,
10,'exit'));
　　pstmt.close();
　　debug_st.close();
　　dbCon.close();　　　
　　　catch
(SQLException
　　　　errorCode
sqle.getErrorCode();
　　　　throw
SQLException(
　　　finally
　　　　　if(pstmt
　　　　　{pstmt.close();}
　　　　　
　　　　　if(debug_st
　　　　　{debug_st.close();}
　　　　　
　　　　　if(
　　{dbCon.close();}　　
#p#分页标题#e#
SP_NAMETIMETRACEPOINTDESC
test_javasp-19.25.21.4360001
test_javasp-19.25.21.4520002
test_javasp-19.25.21.4520003
executeUpdate
test_javasp-19.25.21.4520004
test_javasp-19.25.21.
　　使用上述法子的优点是，这种法子非常容易实现。缺点是如果没有数据库连接，就不能将调试信息输出到表中。这大概不是问题，因为像这样严重的错误应该已经解决了。
列出了在执行存储过程之后调试表的内容。它在执行的代码旁显示一个时间戳。
　　另一种法子是修改
例程，使它将调试信息写到一个文件中，如
所示。在我们的例子中，我们将一个调试参数添加到存储过程定义中，以启用/禁用调试。当添加调试信息时，可能会有额外的开销，所以应用程序开发人员可以选择从
例程的生产版本中删除调试代码。还应注意，与将调试信息插入到一个表中相比，将调试信息写到文件中需要进行更多的调用，因为需要款式化一个
时间戳。默认情况下，Java
时间戳为自
日以来的毫秒数。Calendar()
对象用于将时间戳（单位为毫秒）款式化为人类熟悉的款式。
debugOut.flush()的调用立即将字符缓冲区转储到文件中。在调试挂起问题时，假设没有这个调用，那么如果在字符缓冲区充满之前发生了挂起，就不能将调试输出写到文件。
将调试信息写到文件
java.sql.*;
java.io.*;
java.util.*;
TEST_JAVASP2
tEST_JAVASP2　(int
SQLException,
　　Exception
PrintWriter
　　　　　if
　　　　　{
　　　　　　cal
Calendar.getInstance();
　　　　　　cal.setTimeInMillis(System.currentTimeMillis()
　　　　　
　　　　　　//
　　　　　　debugOut
PrintWriter(new
FileWriter(sp_debug.txt));
　　　cal.setTimeInMillis(System.currentTimeMillis()
　　　　　　debugOut.println(cal.getTime()
cal.get(Calendar.MILLISECOND)+
　　　　　　　　+
tEST_JAVASP2
　　　　　
　　　　　　//
troubleshooting
　　　　　　//
　　　　　　debugOut.flush();
　　　　　}
　　　　　
　　　　//
caller's
connection
　　Connection
DriverManager.getConnection(jdbc:default:connection);
　　　　String
　　　　　{
　　　cal.setTimeInMillis(System.currentTimeMillis()
　　　　debugOut.println(cal.getTime()
cal.get(Calendar.MILLISECOND)+
　　　　　　+
tEST_JAVASP2
　　　debugOut.flush();
　　　　PreparedStatement
con.prepareStatement(query);
　　　　pstmt.setInt(1,
　　　　pstmt.executeUpdate();
　　　　　{
　　　cal.setTimeInMillis(System.currentTimeMillis()
　　　　debugOut.println(cal.getTime()
cal.get(Calendar.MILLISECOND)+
　　　　　　+
tEST_JAVASP2
　　　　debugOut.flush();
　　　　　for(int
i=0;i10;i++)
　　　　　{
　　　　　　if
　　　　　　　　　　{
　　　　　　　cal.setTimeInMillis(System.currentTimeMillis()
　　　　　　　debugOut.println(cal.getTime()
cal.get(Calendar.MILLISECOND)
　　　　　　　　　+
tEST_JAVASP2
　　　　　　debugOut.flush();
　　　　　　}　　　　
　　　　　{
　　　　cal.setTimeInMillis(System.currentTimeMillis()
　　　　debugOut.println(cal.getTime()
cal.get(Calendar.MILLISECOND)
　　　　　　+
tEST_JAVASP2
　　　　debugOut.flush();
　　　　//
　　　　debugOut.close();
　　　catch
(SQLException
　　　　errorCode
sqle.getErrorCode();
　　　　throw
SQLException(
　　　finally
　　　　if(debugOut!=null)
　　　　{debugOut.close();
　　　　　
　　　}　　　　
#p#分页标题#e#
　　在执行存储过程之后，调试信息被写到纯文本文件
sp_debug.txt
中。可以修改这些例子，以供给附加的调试信息。847
是毫秒数。此外，还有一些更繁杂的生成调试信息的法子，例如
这个例子，它演示了如何通过创建一个调试调用库来跟踪
存储过程。
sp_debug.txt
tEST_JAVASP2
tEST_JAVASP2
tEST_JAVASP2
tEST_JAVASP2
tEST_JAVASP2
tEST_JAVASP2
tEST_JAVASP2
tEST_JAVASP2
tEST_JAVASP2
tEST_JAVASP2
tEST_JAVASP2
tEST_JAVASP2
tEST_JAVASP2
存储过程挂起问题
　　当一个
应用程序或
例程挂起时，可以生成一个
javacore（也称
javadump）来断定它是在何处挂起的。下面的例子演示如何为一个
javacore。
　　为了启用
javacore，必须设置
环境。对于不同的平台和使用的不同
JDK，这个设置过程可能略微有些差别。在我们的例子中，我们从一个
应用程序连接到
JAVA_DUMP_OPTS=ONINTERRUPT(JAVADUMP),ONANYSIGNAL(JAVADUMP)
IBM_JAVACOREDIR=/db1/j2ma
DB2ENVLIST=IBM_JAVACOREDIR
JAVA_DUMP_OPTS
time(seconds)　　　　unlimited
file(blocks)　　　　
data(kbytes)　　　　
stack(kbytes)　　　　32768
memory(kbytes)　　　
coredump(blocks)　　
nofiles(descriptors)
SQL1064N　DB2STOP
processing
successful.
SQL1063N　DB2START
processing
successful.
　　注意，设置可能稍微有些不同，因为这个例子中使用的
级别不同于您使用的
　　JAVA_DUMP_OPTS
指定哪些信号会触发
javacore。
　　IBM_JAVACOREDIR
文件的位置。
　　可以使用
DB2ENVLIST
将环境变量传递给
进程，因为
命令会过滤掉所有不是以
开头的用户环境变量。
　　然后，确认隔离
coredump=unlimited，并重新启动实例。
　　在这个例子中，JCC
应用程序在一个远程
服务器上调用存储过程
TEST_JAVASP，而这个存储过程挂起，没有返回。首先要做的事是从客户端收集一个
跟踪，因为我们想知道发送给存储过程的是什么值。也许是一个特定的
值导致挂起。
对存储过程调用的
[jcc][Time:-17:39:29.388][Thread:main][Connection@54a328]
prepareStatement
JASON.TEST_JAVASP(?))
[jcc][Time:-17:39:29.420][Thread:main][Connection@54a328]
prepareStatement
PreparedStatement@1fc2fb
[jcc][Time:-17:39:30.967][Thread:main][PreparedStatement@1fc2fb]
executeUpdate
[jcc][SystemMonitor:stop]
13.378541ms
9.792076ms
[jcc][Time:-17:39:30.967][Thread:main][PreparedStatement@1fc2fb]
[jcc][SystemMonitor:start]
[jcc][Time:-17:39:30.967][Thread:main][PreparedStatement@1fc2fb]
executeUpdate
[t4][time:-17:39:30.967][thread:main][tracepoint:1][Request.flush]
[jcc][t4]　　　　SEND
EXCSQLSTT　　　　　　　(ASCII)　　　　　
[jcc][t4]　　　　0
ABCDEF　ABCDEF
007ED　200BF9　.~.Q...x
..D!...　.=}...........v9
A040　4040　....@@@@@@@@@@@@　samp　　　　　　
D5E4D3D3C9C4　......@@@@@@@@@@　NULLID　　　　　
E2E2C8F2　F0F0　@@........@@@@@@　　SYSSH200　　　
534C　564C　@@@@SYSLVL01....　　　..........
11F1　7FFF　!....!....!.....　..1....1.......
FFFFFFFF　..!A....!@....!B　.........
000000　　　...!..........　　..............　
[jcc][t4]　　　　SEND
SQLDTA　　　　　　　　
(ASCII)　　　　　
001E　0676　.$......$......v　..}.............
DE4D0　A0000　.....q.......z..　}.....U}.....:..
0000000B　　　　　　　　　　　　　　....　　　　　　　....　　　　　　
[time:-17:39:30.967][thread:main][tracepoint:101]Request
#p#分页标题#e#
　　从客户端上的
跟踪可以看到，最近执行的操作是用输入值
调用存储过程
JASON.TEST_JAVASP(?)
executeUpdate()。DRDA
缓冲区显示，我们在跟踪结束时发送
EXCSQLSTT（执行
SQLDTA（SQL
数据）。由于没有将任何其他内容返回到客户端，因此应该调查服务器端，以断定为什么没有返回任何内容。注意，这里可能需要
数据库管理员的帮助，因为应用程序开发人员通常没有访问服务器的权限。
　　在服务器端，有多种法子可以显示应用程序信息，例如使用
-applications
applications
等等。在我们的例子中，我们选择收集应用程序快照，以发现发生了什么事情。在下面的例子中，JCC
应用程序从客户端
10.1.1.123
进行连接。如果应用程序与
数据库在相同的系统上，那么
communication
*LOCAL.hostname
。为了从快照中识别出应用程序，应用程序开发人员需要知道应用程序的名称、userid
和它所连接到的数据库。
使用快照发现与应用程序关联的
　　　　　　Application
Application
handle　　　　　　　　　　　　
Application
status　　　　　　　　　　　　
time　　　　　　　　　　　　
Application
page　　　　　　　　　　　=
Application
country/region
code　　　　　　=
correlation
token　　　　　　　　　　
GA123456.GA16.
Application
name　　　　　　　　　　　　　
db2jcc_application
Application
ID　　　　　　　　　　　　　　
GA123456.GA16.
number　　　　　　　　　　　　　　=
ID　　　　　　　　　=
workstation
name　　　　
application
name　　　　
accounting
string　　　　=
Connection
timestamp　　　　
06/22/2007
16:06:08.388356
completion
timestamp　　　
06/22/2007
16:06:08.865863
Application
time　　　　　　　　　　　=
Authorization
ID　　　　　　　　　
ID　　　　　　　　　　　　　　=
Configuration
client　　　　　　　=
ID　　　　
application　　　　　
application　　　　　　
Communication
client　　　　　
communication
address　　　　　　　=
10.1.1.123
Coordinator
　　根据快照信息可以发现，PID
就是负责对存储过程的调用的
进程。但是，由于这是一个
存储过程，默认情况下它将在一个
进程中作为一个隔离存储过程运行。在
之类的支持线程的系统上，这将是一个线程
　　可以使用
来发现代表
执行该存储过程的
进程。从下面的清单中可以看到，db2fmp
存储过程。
发现与应用程序关联的
/home/j2ma/sqllib/db2dump:
06/27/2007
Size:　　　
FMP:　　　　YES
Initialized:　　
Path:　　/home/j2ma/sqllib/function/unfenced
Address　　　　　　FmpPid　　
Flags　　　ActiveThrd
PooledThrd
313092　　
1　　　　　0　　　　　No　
Address　　　　　　FmpPid　　
EduPid　　
ThreadId　
313092　　
340630　　
2571　　　
Address　　　　　　FmpPid　　
ThreadId　
　　现在，我们知道哪个
db2fmp，如果它消耗太多的资源，我们可以终止它。如果想进一步调查，可以使用
进程创建一个
文件。或者，也可以发出
313092。对于不同
平台，为生成
文件而发送的信号有所不同。
#p#分页标题#e#
*******************************************
sigpre　　　*
signal　　　　　　　　　　　　　　　　　*
*******************************************
　　　　　　
0000000f　　　　　　　　　
*****************************
　　　　　　　　　　*
*******************************************
timestamp:
-15.39.55.254086
N:panipuri
StackTrace
-------Frame------
------Function
Offset------
_event_sleep
_event_wait
_cond_wait_local
_cond_wait
pthread_cond_timedwait
sqloAppWaitOnSync
sqleProcessObjects
timestamp:
-15.39.56.253815
N:panipuri
StackTrace
-------Frame------
------Function
Offset------
sysSignalWait
signalDispatcherThread
xmExecuteThread
threadStart
_pthread_body
/StackTrace
　　这些栈供给的信息有限，因为存储过程是独立于
的、用于运行应用程序开发人员的代码的过程。可以看到，DB2
存储过程。进一步诊断应用程序的理想法子是，应用程序开发人员添加调试代码到
存储过程中。另一种法子是为
文件，以供给附加的信息。
　　由于我们已经启用了
Javacores，并且已经发现了执行存储过程的
PID，因此现在可以生成一个
javacore。DB2
文件转储到它的
db2diag.log
中，而不是一个单独的
文件。必须使用
javacore。
db2diag.log
/home/j2ma/sqllib/db2dump/db2diag.log
javadump.txt
ID:0xA0B。记住，这是从
输出的线程
2571（十进制）转换为
0xA0B（十六进制）。线程
就是那个挂起的执行
存储过程的线程。在我们的应用程序中，它在第
中的源代码，它在一个
无限循环中。
20.Javacore
Requesting
NULL　　　　　
-----------------------------------------------------------------
0SECTION　　　
subcomponent
NULL　　　　　
===============================
1TISIGINFO　　
1TIDATETIME　　Date:　　　　　　　　
1TIFILENAME　　Javacore
filename:　　/db1/j2ma/javacore2972298.txt
0SECTION　　　
subcomponent
NULL　　　　　
==============================
1XHTIME　　　　Wed
1XHSIGRECV　　
0x7cdb02a639e00002
1XHFULLVERSION
1XMTHDINFO　　
NULL　　　　　
------------------
NULL　　　　　
2XMFULLTHDDUMP
3XMTHREADINFO　　　Thread-0
(TID:0xB8B78,
sys_thread_t:0x,
4XESTACKTRACE　　　　　
TEST_JAVASP.tEST_JAVASP(TEST_JAVASP.java:31)
3XHNATIVESTACK　　　
NULL　　　　　　　　
------------
本文章下载来自：