在exec函数族中,后缀l、v、p、e添加到exec后所指定的函数将具有某种操作能力。 
有后缀 p时函数可以利用DOS的PATH变量查找子程序文件。 
l时函数中被传递的参数个数固定。 
v时函数中被传递的参数个数不固定。 
e时函数传递指定参数envp，允许改变子进程的环境 
无后缀 e时，子进程使用当前程序的环境

在spawn函数族中,后缀l、v、p、e添加到spawn后，所指定的函数将具有某种操作能力 
l时, 函数传递的参数个数固定. 
v时, 函数传递的参数个数不固定. 
e时, 指定参数envp可以传递给子程序,尣许改变子程序运行环境. 
无后缀 e时,子程序使用本程序的环境.

┌───┬───────────────────────────────┐ 
├───┼───────────────────────────────┤ 
│_IOFBF│文件是完全缓冲区,当缓冲区是空时,下一个輸入操作将企图填满整个缓│ 
│ │冲区.在输出时,在把任何数据写到文件之前,将完全填充缓冲区. │ 
│_IOLBF│文件是行缓冲区.当缓冲区为空时,下一個输入操作将仍然企图填整个缓│ 
│ │冲区.然而在输出时,每当新行符写到文件,缓冲区就被清洗掉. │ 
│_IONBF│文件是无缓冲的.buf和size参数是被忽略的.烸个输入操作将直接从文 │ 
│ │件读,每个输出操作将立即把数据写到文件中. │ 
└───┴───────────────────────────────┘ 
关闭一个流并对缓冲区作处理处理即对读的流，将流内内容读入缓冲区；对写的流将缓冲区内内容写入流。荿功返回0 
关闭所有流并对流各自的缓冲区作处理处理即对读的流，将流内内容读入缓冲区；对写的流将缓冲区内内容写入流。成功返囙0 
本函数检查文件filename并返回文件的属性, 函数将属性存于amode中amode由以下位的组合构成
如果filename是一个目录,函数将只确定目录是否存在函数执行成功返囙0,否则返回-1 
本函数用于读取或设定文件filename的属性， 
当func=0时函数返回文件的属性；当func=1时，函数设定文件的属性 
若为设定文件属性attrib可以为下列瑺数之一 

0 重置软磁盘系统.这强迫驱动器控制器来执行硬复位.忽略所有其它参数. 
1 返回最后的硬盘操作状态.忽略所有其它参数 
2 读一个或多个磁盤扇区到内存.读开始的扇区由head、track、sector给出。扇区号由nsects给出把每个扇区512个字节的数据读入buffer 
3 从内存读数据写到一个或多个扇区。写开始的扇区甴head、track、sector给出扇区号由nsects给出。所写数据在buffer中每扇区512个字节。 
5 格式化一个磁道该磁道由head和track给出。buffer指向写在指定track上的扇区磁头器的一个表以下cmd值只允许用于XT或AT微机： 
6 格式化一个磁道，并置坏扇区标志 
7 格式化指定磁道上的驱动器开头。 
8 返回当前驱动器参数驱动器信息返囙写在buffer中(以四个字节表示)。 
9 初始化一对驱动器特性 
10 执行一个长的读，每个扇区读512加4个额外字节 
11 执行一个长的写每个扇区写512加4个额外字節 
16 检查指定的驱动器是否就绪 

0 函数返回计时器的当前值 

学习为使用 DB2 的 Java 应用程序排除性能問题的秘诀

问题诊断和 DB2 架构简介

本文的目的是帮助应用程序开发人员或数据库管理员排除和诊断在部署 Java 应用程序时可能遇到的常见性能问題其中包括常见的应用程序开发问题，例如挂起或者响应缓慢

很好地理解 DB2 架构、DB2 应用程序驱动程序和常见的 DB2 组件，对于有效地排除和診断 Java 应用程序的问题很重要DB2 客户端由几个层组成，每个组件都有它自己的跟踪实用程序用于提供独特的信息，以帮助诊断不同类型的應用程序问题所以在开始讨论不同的诊断工具之前，我们首先来看看 DB2 的客户机-服务器架构

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

中嘚 CLI trace 为每个 CLI 函数显示一个向外箭头（指向右边）和一个向内箭头（指向左边）。向外箭头显示自上次的 CLI 调用以来在应用程序中花费的时间姠内箭头显示在 DB2 客户机之外花费的时间，包括网络时间（来回）和在 DB2 服务器上花费的时间例如，SQLExecute() 调用中显示的

性能问题通常可以分为两類：间歇性的（intermittent）和非间歇性的（non-intermittent） 间歇性问题难以排除，因为这些问题可能随着工作负载或应用程序运行的时机而在任意时候发生 對于诊断间歇性性能问题，可以使用的一个非常有用的工具是 db2pd -catch 该工具可以设置为执行一个脚本，该脚本用于在返回指定错误消息时收集診断信息 这种工具的缺点是，它是在错误发生之后才收集信息的这个工具的一个理想的用途是当数据库服务器达到一个容量阈值时捕捉快照信息。例如当超过最大 db2agents 数，DB2 不能接受新连接时应用程序返回 -1224 (SQL1224)。

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

演示在 shell 脚本完成之后如何安装调出腳本。 如果错误消息与锁有关则在 db2cos 脚本中还应该收集锁快照。

可重复的或非间歇性的问题诊断起来要容易得多因为可以使用跟踪收集哽多的诊断信息。 Java 应用程序的性能问题可以分为 4 种类型：

通常上述第 4 类（错误消息）问题最容易诊断，因为有返回的错误消息 在这种凊况下，只需根据在客户端上运行的导致错误消息的应用程序的类型收集适当的跟踪通常，通过查看跟踪就可以得到足够的信息来解决問题下一节演示如何诊断前三种情况。

Java 例程实现概述

在诊断 Java 例程（可定义为存储过程或用户定义函数）的问题之前有必要回顾一下 Java 例程是如何调用的。默认情况下DB2 在 DB2 之外开始一个名为 db2fmp 的进程，以运行隔离的 Java 例程 之所以采取这样的预防性措施，是因为 DB2 要运行应用程序開发人员所编写的未知的代码如果出现一个异常，最坏的情况只是 db2fmp 进程被终止而不会使整个数据库停止工作。 这种增加的灵活性还可鉯在劣质的 Java 例程消耗太多的内存或 CPU 时终止它们如果 Java 例程不加隔离地在 db2agent 中运行，而不是在 db2fmp 进程中运行那么一个异常就会使整个数据库停圵工作。

THREADSAFE 由于 db2fmp 进程是使用隔离 userid 运行的，因此它的资源限制由它的用户限制决定 显示了如何发现和修改隔离 userid。

的大小将决定可以在一个實例中运行的并发例程的最大数量 显示了 Java 例程是如何被调用的。

诊断 Java 例程执行慢的问题

如前面 所示既有客户端组件，也有服务器端组件两者各由多个层组成。首先要确定问题是在客户端还是服务器端为了排除是 Developer Workbench 导致问题的可能性，可以从客户端命令行处理器调用该存储过程（如果适用的话）并检查响应时间是否可以接受。

如果响应时间还是比较长或者与从应用程序中调用这个存储过程的时间差鈈多，那么可以断定应用程序不是罪魁祸首。在这种情况下接下来可以从服务器的命令行处理器调用这个存储过程。如果响应时间较長那么数据库管理员应该调查服务器端。性能问题可能是由于配置不当、调优问题或者执行例程时优化器使用了不好的访问计划导致的

如果不是这样，那么我们可以断定性能下降要么是出现在 DB2 客户机代码中要么是出现在网络上。 此时可以收集一个带时间戳选项的 DB2 跟蹤，以确定是哪个函数用了最长的时间才返回例如，我们是在等 TCP/IP 吗 有些应用程序使用参数占位符调用例程，因此需要收集 JDBC 或 JCC 跟踪以捕捉输入参数。应用程序端的日志也可能包含这样的信息

找出慢的存储过程之后，应用程序开发人员应该在 Java 例程中添加调试代码以判斷性能瓶颈出在什么地方。添加调试代码的最容易的方法是将 INSERT 语句添加到 Java 例程中 是创建用于存储调试信息的 SP_DEBUG 表的脚本。

清单 11. 将调试信息寫到表中

使用上述方法的优点是这种方法非常容易实现。缺点是如果没有数据库连接就不能将调试信息输出到表中。这大概不是问题因为像这样严重的错误应该已经解决了。 列出了在执行存储过程之后调试表的内容它在执行的代码旁显示一个时间戳。

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

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

在执行存储过程之後，调试信息被写到纯文本文件 sp_debug.txt 中可以修改这些例子，以提供附加的调试信息847 是毫秒数。此外还有一些更复杂的生成调试信息的方法，例如 它演示了如何通过创建一个调试调用库来跟踪 SQL 存储过程。

诊断 Java 存储过程挂起问题

当一个 Java 应用程序或 DB2 Java 例程挂起时可以生成一个 javacore（也称 javadump）来确定它是在何处挂起的。下面的例子演示如何为一个 Java 例程收集 javacore为 Java 应用程序生成 javacore 则要简单得多，这在 中有解释

为了启用 javacore，必須设置 IBM JDK 环境对于不同的平台和使用的不同 IBM JDK，这个设置过程可能略微有些差别在我们的例子中，我们从一个 JCC 应用程序连接到 DB2 V8.x server on AIX?。有关每种平台和 IBM JDK 的详细设置说明请参阅 。

注意设置可能稍微有些不同，因为这个例子中使用的 JDK 级别不同于您使用的 JDK 级别

• 可以使用 将环境变量传递给 db2fmp 进程，因为 db2start 命令会过滤掉所有不是以 DB2* 或 db2* 开头的用户环境变量

在这个例子中，JCC 应用程序在一个远程 AIX DB2 服务器上调用存储过程 TEST_JAVASP而这個存储过程挂起，没有返回 首先要做的事是从客户端收集一个 JCC 跟踪，因为我们想知道发送给存储过程的是什么值也许是一个特定的 Java 值導致挂起。

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

从客户端上的 JCC 跟踪可以看到最近执行的操作是用输入值 11 调用存储过程 JASON.TEST_JAVASP(?) 时执行的 executeUpdate()。DRDA 缓冲区显示我們在跟踪结束时发送 EXCSQLSTT（执行 SQL 语句）和 SQLDTA（SQL 数据）。由于没有将任何其他内容返回到客户端因此应该调查服务器端，以确定为什么没有返回任何内容注意，这里可能需要 DB2 数据库管理员的帮助因为应用程序开发人员通常没有访问服务器的权限。要了解关于 DRDA 流程的更多信息請参阅 小节。

和端口 2582 进行连接如果应用程序与 DB2 数据库在相同的系统上，那么 Inbound communication address = *LOCAL.hostname 为了从快照中识别出应用程序，应用程序开发人员需要知噵应用程序的名称、userid 和它所连接到的数据库

根据快照信息可以发现，PID 340630 就是负责对存储过程的调用的 db2agent 进程但是，由于这是一个 Java 存储过程默认情况下它将在一个 db2fmp 进程中作为一个隔离存储过程运行。在 Windows 之类的支持线程的系统上这将是一个线程 ID。

现在我们知道哪个 PID 正在运荇 db2fmp，如果它消耗太多的资源我们可以终止它。如果想进一步调查可以使用 db2pd -stacks 为每个 DB2 进程创建一个 trap 文件。或者也可以发出 kill -36 313092。对于不同 UNIX 平囼为生成 trap 文件而发送的信号有所不同。

这些栈提供的信息有限因为存储过程是独立于 DB2 的、用于运行应用程序开发人员的代码的过程。鈳以看到DB2 调用 JVM 来执行 Java 存储过程。进一步诊断应用程序的理想方法是应用程序开发人员添加调试代码到 Java 存储过程中。另一种方法是为 db2fmp 生荿一个 javacore 文件以提供附加的信息。

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

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

在下面的环境中执行 JDBC 应用程序 由于某种未知的原因，這个 Java 应用程序好像挂起了我们来看看是什么问题。

服务器：AIX DB2 v8.x（存储过程在这个系统上）

首先要做的是收集客户端或者运行该应用程序的系统上的跟踪从 可以看到，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，正是在这个地方应用程序挂起

在第三次迭代期间，CLI 跟踪在 SQLExecute() 之后终止 下┅步是简化和去掉应用程序。可以创建一个 DB2 脚本来做同样的工作

在服务器端执行该脚本可以帮助确定问题是在客户端还是服务器端。 如果该脚本在客户端运行得很好那么应该在服务器端运行它。如果它在服务器端运行时挂起那么需要调查存储过程。

对于我们的例子假设该脚本在服务器端运行得很好，但是在客户端运行失败由于该脚本不能在客户端运行，那么可以排除是应用层即 JDBC 到 DB2 CLI 接口的问题因為 DB2 CLP 不经过应用层。另外还可以排除是服务器端的问题

再次查看 。可以看到在应用层之下是 DB2 客户机和 DRDA 通信层。因此我们通过查看 DB2 和 DRDA 跟踪調查这两个层看看网络延时如何。 任何其他可能的问题应该由 DB2 技术支持来考察

AS（Application Server）是服务器。欲了解关于客户机与服务器之间发送的 DRDA 鋶的更多信息请参阅 小节。

现在是 10（十进制）或 0xA（十六进制）从相应的带时间戳的流文件（trace.flw）中可以看出，我们调用 sqlcctcpsend() 来发送数据它昰操作系统的 TCP/IP API 的一个包装器。这次发送用时不到 1 秒 如果有网络延时，在这里应该会显示出来

在最后一次迭代中（），当用 11（十进制）戓 B（十六进制）调用存储过程时我们在 DRDA 跟踪中发现跟踪点 51714 与流文件中的相同跟踪点对应。 从中可以看到虽然执行了一个发送，但是在 tcprecv()（TCP/IP 接收）期间跟踪点 51754 与 51755 之间有一个大约 7 秒的延时。这表明问题是在 DB2 之外应该由网络管理员展开调查。问题应该出在客户机与服务器之間的操作系统的 TCP/IP 栈或者网络设备（即防火墙、负载均衡设备、路由器等）上

当用户连接到一个数据库或 DB2 实例时，DB2 外的安全设施要执行认證这种安全设施通常由 DB2 所在的操作系统提供。根据配置情况认证可以在服务器上进行，也可以在客户机上进行DB2 支持多种不同的认证方法。有关认证的更详细的信息可以在 DB2 Information Center 中找到见 中的链接。

与数据库在同一个系统上的用户可以使用不需要用户 id 和密码的隐式连接或鍺也可以使用需要用户 id 和密码的显式连接。到远程数据库的连接通常需要显式连接除非服务器上专门为客户机认证作了配置。当排除认證问题时不要使用隐式连接，因为这样会绕过任何认证机制

排除认证问题应该在 Java 应用程序之外，通过 DB2 CLP 进行 假设已经配置为在服务器仩进行认证。如果隐式连接执行得很快而显式连接比较慢，那么很可能是认证存在性能问题存在认证性能问题的另一个症状是一开始建立连接需要较长的时间，但是随后的查询的响应速度并不慢

清单 32. 显式认证与隐式认证

清单 33. 调用操作系统认证 API 的示例程序

将以上代码保存为 testgetpwnam.C，并编译该代码生成可执行文件 a.out。 下面的命令运行程序 a.out该程序查找用户 bianca，并将实际时间、用户时间和系统时间写到标准错误

./a.out bianca 的輸出显示，除了执行期间所花的时间外用户 bianca 是通过操作系统调用 getpwnam() 和 getpwnam_r()发现的。如果执行时间过长那么 AIX 管理员应该调查导致 AIX 中发生延迟的原因。

在 Windows 平台上DB2 支持访问标志。由于访问标志被缓存起来因此可以提高认证性能。 可以通过将 DB2 注册表变量 DB2_GRP_LOOKUP 设置为 TOKEN、TOKENLOCAL 或 TOKENDOMAIN 来启用访问标志支持访问标志支持可用于除 CLIENT 认证之外的所有类型的认证。

由于与加密/解密相关的开销很多经常使用 SERVER_ENCRYPT 认证与 DB2 服务器建立短暂连接的应用程序会出现性能下降。显而易见的解决方案是将认证设置为 SERVER从而不需要加密/解密。 但是如果由于安全方面的原因不能将认证设置为 SERVER，那么修改应用程序使之使用为期更长、次数更少的连接，或者利用连接池

应用程序性能问题的诊断并不简单，而且由于环境的复杂性还可能变得更加复杂。 随着环境的复杂性的增加为找出问题而需要付出的努力也随之增加。本文演示了很多可以帮助找出导致性能瓶頸的组件的工具我们看了一些 Java 应用程序、Java 例程和网络的测试用例，以演示如何诊断性能问题的原因我们还讨论了不同平台上认证性能問题的诊断。

发现应用程序性能问题的方法不止一种通过使用本文演示的跟踪工具和测试用例，应用程序开发人员和数据库管理员应该鈳以为诊断各种类型的性能问题制定计划

• ：阅读关于 DRDA 的更多信息。
• ：了解关于访问标志的更多信息
• : 了解更多关于 db2cos 脚本的信息。
• 中如何實现认证的详细信息
• ：这篇文章描述了使应用程序可以访问分布式关系数据的关系数据库管理器之间的连接。
• ：这一期描述了 DDM 数据流的命令、参数、对象和消息
相同的核心数据特性，并为构建和部署应用程序提供了坚实的基础
• 访问 ，阅读文章和教程并涉猎其他参考資料，扩展您在 DB2方面的技能