db2top工具详解翻译文档格式.docx

1、因为磁盘的I / O比存储器存取慢得多，用户更喜欢访问在内存中的数据。当用户看到HitRatio下降低则可以查看缓冲池（bufferpools）是不是不够大了，或是不是有查询进行了太多的全白扫描而导致页面数据从内存洗冲到磁盘。和读类似，A_Writes代表异步写入，这表明数据页是由异步页清洁剂之前写的缓冲池空间是必需的。通过db2top 刷新频率这段时间内的写数量我们还能知道有多少写请求发生了。还能计算每次写入的平均花费时间这对分析I/O瓶颈引起的一些性能问题有所帮助。当A_Writes/Writes的比值越高则写I/O性能越高。SortOvf代表排序溢出。如果用户发现这个数字变为非常高，就需

2、要寻找查询了。排序溢出发生在SORTHEAP不足够大，导致排序（Sort）或HashJoin操作可能会溢出数据到临时空间。有时该值随着SORTHEAP增加而降低，但在其他情况下，可能没有多大帮助，如果进行排序的数据集比可分配给SORTHEAP内存大得多。如果请求的数据量超过缓冲池可容纳的临时空间大小那么就可能需要物理I/O来进行SORT或哈希链接在这种情况下排序溢出将是很大的瓶颈。因此优化查询来减少排序溢出的数量能显著提高系统的性能。在数据库屏幕的最后（zuhu）四个条目显示的平均物理读取时间（AvgPRdTime），平均直接（zhji）读取时间（AvgDRdTime），物理（wl）平均写入时

3、间（AvgPWrTime）和平均（pngjn）直接写入时间（AvgDWrTime）。这四个项目直接（zhji）反映I/ O子系统性能。如果用户发现一个意想不到的大量的时间花费在每个读或写操作，进一步的调查应到I/ O子系统。正常情况下，DB2 排序发生在内存中，这块内存叫做排序堆，即 SORTHEAP。当需要排序的数据超出 SORTHEAP 大小限制时，就会发生排序溢出。溢出的数据会写到临时表中，这会产生更多的 I/O，因此对性能会有较大影响。Tablespace （t）Figure 3. Tablespace screen表空间屏幕提供每个表空间的详细信息。Hit Ratio%和Async

4、Reads%列对用户来说是非常重要的。在数据库级别仅仅监视缓冲池命中率，你可能无法获得足够精确的信息。在包含多个表空间的环境中，在一个表空间中发生了不良查询现象会被所有表空间平均命中率遮蔽。在每个表空间级别上监测Hit Ratio%和Async Reads%对于分析系统工作细节很有帮助。Delta逻辑读取（写）和Delta物理读取（写）（Delta 逻辑读（写入）和Delta 物理读（写入）说明这些表空间如何“忙”的。一些不太活跃的表空间可能不具有非常高的缓冲命中率。在大多数情况下最好使用活动性更大的表空间。想要左右滚动（gndng）屏幕可以使用键盘（jinpn）上的左，右箭头键。所有（suy

5、u）的列信息（xnx）不能在一个屏幕（p）上显示可以通过按下左或右箭头键来查看。Space Used,Total Size和% full能够很方便的查看各表空间的使用率情况，还能从其他列信息中查看表空间类型是DMS还是SMS。Dynamic SQL （D）Figure 4. Dynamic SQL screen动态SQL屏幕提供缓存的SQL语句的详细信息。用户可以再此屏幕对特定SQL语句产生执行计划（DB2EXPLN）和（db2exfmt）。执行数量（Num Execution）和平均执行时间（Avg ExecTime）可以用来了解查询语句执行了多少次和平均运行时间。通过平均CPU时间（Avg

6、 CpuTime）与平均执行时间（Avg ExecTime）比较能看出执行时间花费在CPU上还是花在了等待锁或I/O上。行读取（Row read）和行写入（Row written）能够明白查询的行为。例如，如果用户看到一个SELECT查询语句关联了大量的写，这可能表明该查询可能会有排序（哈希联接）溢出而且需要进一步调整来以避免数据溢出临时空间。数据，索引的Hit ratio（命中率）和临时l_reads来帮助用户轻松解决缓冲池大小是否需要调整。（AvgSort PerExec）和排序时间能计算出在一次执行期间进行了多少排序。db2top实用程序还提供了产生DB2EXPLN或db2exfmt报告

7、功能而无需手动运行该命令。通过动态SQL屏幕上输入一个大写L，它会提示你输入一个SQL字符串哈希。SQL散列字符串位于表中的第一列，例如“00000005429283171301468277.”用户可以复制该字符串并将其粘贴到光标提示处，按下Enter键，如图5： Figure 5. Dynamic SQL screen - Query text然后（rnhu），选择e选项生成（shn chn）DB2EXPLN输出（shch），或者选择x选项生成（shn chn）db2exfmt输出（shch）如果EXPLAIN.DDL已经导入到数据库中。Session （l）Figure 6. Sessio

8、n screen会话屏幕（p）提供每个应用程序会话（huhu）的详细信息。第一列显示了应用句柄，下面（xi mian）三列：CPU总计（zngj），IO总计（zngj），MEM总计表示本应用消耗资源的百分比。在大多数情况下，每个会话表示一个连接。在这些列之后还显示了应用状态，以及一些统计数据读写的列。用户还可以看到LocksHeld，Sort（sec），LogUsed信息在此屏幕上。当事务日志耗尽空间时LogUsed信息就很有帮助了。通过使用这种显示器的个监控元素，用户可以得到一些想法那些应用程序消耗大部分日志空间。虽然会话屏幕上的信息和数据库屏幕上的信息差不多，但是会话屏幕上的信息为每个应用

9、程序的。做性能分析要结合不同的屏幕。例如，当一些读问题显示在数据库屏幕上时可以进一步通过查看会话屏和动态SQL画面上以缩小它的特定应用程序或SQL。在session屏幕按i查找哪些正在等待Lock的应用Bufferpool （b）Figure 7. Bufferpool screen在此屏幕（p）上，db2top提供了每个缓冲池的信息（xnx）。用户可以看到的一些缓冲（hunchng）池的基本（jbn）信息，如读，写，和大小，还可以看到其他（qt）信息，如缓冲池命中率和异步读取率。Lock （U）Figure 8. Lock screen一个锁定的问题是应用程序诊断中最常见的问题之一。通过db

10、2top，用户可以很容易地列出了应用程序持有的锁。使用（shyng）db2top也更容易分析锁等待的问题（wnt）。下面图9，10和11显示（xinsh）其中（qzhng）一个db2bp应用程序正在（zhngzi）等待另一db2bp会话。Figure 9. Lock waiting - Application status在图9中，两代理（代理24和代理9）处于第一列：Agent Id（state）。你可以看到，在第三列（应用状态）其中一个代理（代理24）被卡在锁等待状态。Figure 10. Lock waiting - Lock status如果用户希望看到更多信息，请按键盘上的左箭头，如

11、图10。Figure 11. Lock waiting - Table name在这个（zh ge）特殊的例子中，如图11看到的那样（nyng），代理24试图（sht）去请求（qngqi）表TAOEWANG.T1上的S锁，但是（dnsh）它被拥有T1表IX锁的代理9锁定。db2to在此屏幕提供了另一个非常有用的功能：锁链分析。并不总是容易弄清楚锁等待的关系，如果有多个应用程序涉及。db2top实用程序提供了一个有用的特性来动态绘制锁链，使其更容易为用户了解应用程序之间的锁定关系。通过输入大写L，显示锁链。就像图12显示的这样：Figure 12. Lock waiting - Lock cha

12、inTable （T）Figure 13. Table screen表屏幕显示数据库中的表的信息（x一段时间中没有访问（fngwn）的表显示为白色。正在（zhi）存取（活跃（huyu）表显示（xinsh）绿色。有关于表本身的信息。列中的数据页（Data pages）和索引页（Index pages）代表多少页在表中。表类型和表大小也是表的很重要的属性。另一个重要的列是行溢出/秒（Rows Overflows/s），这表明每秒行溢出的数量。溢出的行表明发生数据碎片。如果这个数字很高，用户应该使用REORG实用程序，清理这种碎片重组表提高表的性能。Bottlenecks （B）Figure 14.

13、 Bottlenecks瓶颈（pn jn）分析对于（duy）一个（y ）DBA来说是不能忽视（hsh他们想知道哪个代理（dil）（应用）严重地限制了整个系统的性能。标题“瓶颈”右下角的方框是关于各种数据库操作的时序分析：The elapsed time used to calculate the percentage of each operation = （wait_lock_time + sort_time + bp_read_time + bp_write_time + async_read_time + async_write_time + prefetch_waite_time +

14、direct_read_time + direct_write_time）.以下为每个操作所估计的百分比：wait lock ms: （wait lock time）/（elapsed time） = 80%sort ms: （sort time）/（elapsed time） = 0bp r/w ms: （buffer pool read and write time）/（elapsed time） = 10%async r/w ms: （async read and write）/（elapsed time） = 6%pref wait ms: （prefetch_waite_time）/

15、（elapsed time） = 2%dir r/w ms: （direct read and write time）/（elapsed time） = 2%这个屏幕的主要显示部分为对于每一种系统资源哪个agent（应用）占用最大屏幕上显示的服务器资源显示db2top所监控的服务器资源：Cpu: Which agent consumes the most CPU time.SessionCpu: Which application session consumes the most CPU time.IO r/w: Which agent consumes the most I/O read

16、and write.Memory: Which agent consumes the most memory.Lock: Which agent is holding the most locks.Sorts: Which agent has executed the biggest number of sorting.Sort Times: Which agent consumes the longest sorting time.Log Used: Which agent consumes the most log space in the most recent unit of work

17、.Overflows: Which agent has the most number of sort overflows.RowsRead: Which agent has read the most number of rows of records.RowsWritten: Which agent has written the most number of rows of records.TQ r/w: Which agent has sent and received most number of rows on table queues.MaxQueryCost: Which ag

18、ent has the max SQL execution time estimated by the compiler.XDAPages: Which agent has the most number of pages for XDA data （available in V9.1GA and after releases）.例如（lr）：图14示出了代理（dil）683表明（biomng）db2bp（DB2 back end process）是很明显（mngxin）的瓶颈。内容总结（1）Database （d）在数据库屏幕，db2top提供了一组对整个数据库的性能监控单元（2）Delta逻辑读取（写）和Delta物理读取（写）（Delta 逻辑读（写入）和Delta 物理读（写入）说明这些表空间如何“忙”的