步步深入DB2应用程序性能调整

• 讨论DB2性能调整的工具和结构
• 重点讲解如何找到DB2的性能问题，以及为其做出的准备和报告等
• 解释一些用来减轻性能问题的详细方法

　　DB2性能调整信息来源

　　在任何DB2调整之前，都必须对可发现问题的性能信息做一个总览。DB2子系统有一些工具来获取信息并且产生DB2的跟踪记录，它被写到SMF或者GTF目标文件中。一般使用的性能相关信息记录的目标文件是SMF。DB2创建三种常见的SMF记录标识符：100，101和102。DB2给这些记录类型分配多个级别。这些级别被定义在DSNZPARM或者在START TRACE命令里，并且告诉DB2来统计哪个级别的数据。

　　SMF记录

　　SMF 100记录被称为统计记录，包含DB2系统范围内的信息。和这些统计记录相关的是四个级别。因为这些统计记录的负载非常小，一般来说统计级别都设置为1，3，4和5。这些级别包含以下信息：

• Class 1——这些记录每隔N分钟记录(DSNZPARM中规定)，显示在该时间段内和所有DB2活动相关的总体信息。
• Class 3——这些记录在每次死锁或者超时时写入，包含这些事件相关信息。
• Class 4——这些记录在DB2发生例外情况时写入，包含诊断信息。
• Class 5——这些记录包含数据分享的信息。

　　SMF 101记录被称为记账记录，包含了单个DB2线程相关的信息，用来初始化任何性能调整工程。大体上这些统计跟踪级别被设置为1，2和3(如果你使用DB2包，愿意使用包级别统计信息，激活class 7和8)。下面的信息解释了级别的含义：

• Class 1——这个记录包含基本记账信息
• Class 2——这个记录包含“in-DB2”时间。没有这个级别，就不可能判别问题是出在DB2内部还是其他资源或者产品上
• Class 3——这个记录包含等待时间。这是非常重要的，如果问题和缓冲池，CPU负载，DASD，或者其他对缓冲时间有影响的因素有关。
• Class 7——这个记录包含了包/DBRM基本记账信息
• Class 8——这个记录包含了包/DBRM层次等待时间信息

　　SMF 102记录被称为性能记录，包含了详细的性能相关信息。这些记录为每次详细的问题发现而收集。注意，一些性能跟踪会影响DB2的性能。

　　其它性能数据

　　其他重要的调整信息来源是DB2 EXPLAIN输出。这个信息描述了DB2用来获取结果集的方法。在绑定多个计划和包的时候保持EXPLAIN的运行是非常重要的。同样，保留EXPLAIN输出的历史数据也是非常重要的。历史数据是决定是否一个性能问题和数据获取方法的变化相关。

　　最后一个DB2性能相关的基本信息来源就是RMF数据。RMF信息可以在问题是CPU资源或者DASD竞争时非常有用。RMF帮助找到一些关键问题所在。

　　隔离和发现性能问题

　　当DB2应用程序性能发生问题了，你该怎么办?首先要明确的事情是问题是客观存在了。可以通过以下现象认识到：

• 用户抱怨事情总是用去太长时间
• 性能监控器
• 一个提前主动的(通常是用户写的)记账信息分析程序。

　　隔离原因

　　当问题被认识到时，80/20法则就应该被用来查明代表主要工作负载的那一小部分DB2会话。这些会话如果能被调整将会带来很大的性能提升。在这个阶段中要问问这样一些问题如：这个问题是和单个的会话，任务或用户相关，还是这个问题隔一段时间就会发生?给出这些问题的答案，它们会减少“可疑”的会话列表到可以接受的数量。

　　DB2PM短记账报告

　　在性能调整工程的问题查明阶段，正常的开始点是去审查以下DB2PM短记账报告。这个报告提供了使用的资源的情况。它将指明：

• DB2响应时间(过去的时间)
• 使用的资源(处理器和I/O)
• 锁定
• 程序代码变化(通过SQL使用的域)
• 等待时间(处理器，I/O等待或者锁定等待)

　　这些域标明了可能潜在的问题。使用短记账报告有一个警告：这个报告是报告间隔里一个计划或者包的所有执行的平均。平均能够影响一些非常长的计划或包的执行情况，如果1)在这个阶段有多个计划或者包的执行2)大多是非常短时间的执行。再次说明，找到在报告间隔里看起来使用资源最多的计划或包。

　　详细性能分析

　　当“有问题的”计划或包被查出之后，就是到了仔细审查相关信息的时间了。首先是检查EXPLAIN输出。运行一个独立的EXPLAIN来决定当前DB2使用的访问路径。然后比较这个信息和EXPLAIN输出(PLAN_TABLE中积累的)，因为它是和运行这个计划或包的最后一次绑定相关的。如果DB2使用的访问路径和你认为的不一样，检查DB2 Catalog中丢失的信息或者SQL调用中的变化等。

　　DB2PM长记账报告

　　如果DB2的访问路径不能揭示解决办法，检查DB2PM长记账报告。这个报告展示了计划或者包的执行的详细信息。下面就是一些此报告的关键部分信息:

• Class 1经过时间——将这个值与CICS或者IMS变迁时间做比较。它们应该相近，但是并不一定相同，因为DB2时间不包括：

　　　　a. 第一个SQL语句执行前的时间

　　　　b. DB2创建线程时间

　　　　c. DB2终止线程之后的时间

　　这会帮助标识是否问题和DB2相关或者“外部”原因。

• Not-in-DB2时间——这是Class1和Class2经过时间的差值。如果发生在DB2外的时间(但是在DB2记账间隔内)较长，问题将会在这个程序，如CICS，IMS或者总体系统中，而不是在DB2中
• 锁/拴 系统挂起时间——这个值表明了DB2资源的竞争。检查“锁统计”段来发现更多信息，然后处理锁报告。
• 同步I/O挂起时间——这是DB2同步I/O总体程序等待时间。如果I/O次数很高，检查：

　　　　a. 访问路径的变化

　　　　b. 程序代码的变化

　　　　c. 系统范围内DB2缓冲池的问题

　　　　d. RID池失败

　　　　e. 系统范围内EDM池问题

　　如果I/O时间比预期的高，检查I/O竞争。一个同步读应该占去15-25毫秒，根据DASD设备的不同。如果这个值较大，使用RFM来检查DASD竞争。

• 异步读挂起——这是一个线程下而非其自身的读I/O的积累时间。它包含了另外一个线程的顺序预取，列表预取，顺序检测和同步读的时间。大体上顺序预取或者顺序检测(异步I/O)是1-2毫秒每页，表预取是3-4毫秒每页。检查“其它读I/O”来找到该值。
• 非记账DB2时间——这是统计class 2时间中不是class2 CPU的那个部分或者class3挂起的时间，一般主要是MVS页面化，处理器等待时间或者用来进行并行任务处理的时间。检查“不记账”域来找到该值。

　　有很多地方来查找，也有很多原因来导致DB2性能问题。这篇文章只是一个开始。你将发现你越了解DB2函数的运行机理，性能调节就会变得越容易。

查看本文来源