大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE使用 1年只要46元 售后保障 童叟无欺

目录

1.db2top命令语法

2.db2top运行模式

2.1 交互模式

2.2 批量模式

3.db2top监控模式

3.1 数据库监控 (d)

3.2 表空间监控 (t)

3.3 动态SQL监控(D)

3.4 会话监控 (l)

3.5 缓存池监控(b)

3.6 锁监控(U)

3.7 表监控 (T)

3.8 瓶颈监控 (B)

4.其他

---

1.db2top命令语法

可使用命令行 db2top –h 查看，这里就不做赘述了。

2.db2top运行模式

db2top一般有两种运行模式， 交互模式和批量模式。

交互模式下，用户可直接输入命令后，等待系统响应。注意键盘上的方向左键“←”和方向右键“→”，可用来滚动查看对应方向上的隐藏列。而批量模式下，可无需用户交互即可执行一系列操作。

2.1 交互模式

执行如下命令:

db2top –d sample

图1. 将db2top运行在交互模式

图1中的屏幕，最上方有状态栏:

[\]15:38:20, refresh=2secs(0.003) AIX, part=[1/1],SHENLI:SAMPLE

· [/]: 当该值滚动时，代表db2top正处在2次快照之间，否则，代表db2top正在等待DB2的响应

· 15:38:20: 当前时间

· refresh=2secs: 刷新时间间隔

· refresh=!secs: 如果出现感叹号，代表处理DB2快照用时比刷新时间间隔要长。这种情况下，db2top刷新时间间隔高了50%。如果由于数据库系统繁忙导致感叹号出现的太过频繁，你可以将刷新时间间隔改高（I选项），或者只监控单独的数据库分区（选项P），又或者关掉额外的监控展示模式(选项X)。

· 0.003: DB2处理快照的内部耗时。

· AIX: DB2运行平台

· Inactive: 代表数据库还未启动，否则代表数据库已启动。

· part=[1/1]: 启动的数据库分区数量/总数据库分区数量。举个例子, part=[2,3] 代表3个数据库分区中有1个数据库分区未启动(活动2, 总数3).

· SHENLI: 实例名

· SAMPLE: 数据库名

[d=Y,a=N,e=N,p=ALL] [qp=off]

· d=Y/N: 代表增量或累计快照指示(命令行 -k 或 选项 k)

· a=Y/N: 代表只显示已启动对象或显示所有对象 (命令行-a 或者选项i)

· e=Y/N: 代表是否显示额外项

· p=ALL: 所有数据库分区

· p=CUR: 当前数据库分区(命令行-P且未指定数据库分区号)

· p=3: 目标数据库分区号: 如3

· db2top 可用来监控DPF环境。如果命令行未指定-P,则将生成全局快照。

· qp=off/on: 查询动态指示 (DYNMGMT 数据库配置参数) db2top所属的数据库分区

状态栏下方有一个用户手册，可按对应按键选择

2.2 批量模式

你可使用db2top 的批量模式来静默地监控数据库。用户可在后台记录性能信息和存储历史数据，以供后续分析。

下列代码列出了如何把db2top在批量模式运行一段时间（例如，总计运行8小时，每15秒收集一次快照数据）:

db2top -d sample -f collect.file -C -m 480 -i 15

should I create a named pipe instead of a file [N/y]? N

注意：请确保输入 N应答系统提出的这个问题

数据收集至文件后，用户可用下列命令运行db2top的回放模式，来分析收集的数据：

db2top -d sample -f collect.file -b l -A

选项-A 支持自动性能分析。所以上面的命令将会分析大多数的活动会话，也会占用更多的CPU资源。

也可用下列命令运行db2top的回放模式，来分析指定时间的数据：

db2top -d sample -f collect.file /HH:MM:SS

例如，如下命令，用户可重启db2top至回放模式，并跳转到上午2点时的数据：

db2top -d sample -f collect.file /02:00:00

之后，用户可输入I来分析当时会话的行为。

3.db2top监控模式

3.1 数据库监控 (d)

图2.监控数据库

数据库监控模式下，db2top为整个数据库提供一套性能要素的监控。用户可以监控活动会话(MaxActSess)，排序内存(SortMemory)，以及日志空间(LogUsed)。这些监控要素可以帮助用户识别这些要素的当前使用率。如果这些要素其中一个的使用率开始升高甚至达到百分之百，用户应当研究相关的原因。

计算当前时间和Start Time差值，可知数据库已经启动了多久。这个数值在配合其他的监控要素，来解决已经持续一段时间的问题时，就会非常有用。锁使用(LockUsed) 和锁升级(LockEscals)对解决锁相关问题很有帮助。如果观察到大量的锁升级，最好改大数据库的两个参数：LOCKLIST 和MAXLOCKS，或者重点关注那些可能需要大量锁的错误语句。

L_Reads， P_Reads，以及A_Reads分别代表逻辑读，物理读，和异步读。结合命中率(HitRatio)，这些变量可重点用来衡量大多数读操作发生在内存I/O还是磁盘I/O。由于磁盘I/O比内存慢很多，用户应尽量通过内存使用数据。当看到命中率降低时，这就是关注缓存池是否不足，或者是否有需要太多表扫描和内存磁盘交换的错误查询的最好时机。

类似读操作，A_Writes代表异步写，这表示在需要缓存池空间之前，数据页是通过异步页清除器代理执行写操作的。知道了db2top的刷新用时期间的写次，用户也可以了解数据库执行了多少写请求。这可以计算每次写操作的瓶颈用时，然后可以用来分析由I/O 瓶颈导致的性能问题。另外，用户可能希望通过计算A_Writes/Writes的最大值来得知的写I/O的最佳性能。

SortOvf代表排序溢出。如果用户发现这个值非常高，这时最好看下查询语句。排序溢出发生在排序堆不足时，所以SORT或者 HashJoin操作可能把数据溢出到临时空间去。有时候这值会因排序堆调大而下降，但在其他的情况下，如果被排序的数据套比存收集到的排序堆的内存大很多，则会不起作用。在那种情况下，排序溢出会成为一个主要瓶颈。如果数据量需要比缓存池临时空间能承受大，就需要物理I/O来处理 SORT或者Hash Join。因此优化查询来减少排序溢出能够显著地提升系统性能。

数据库监控模式的最后四个条目显示的是平均物理读取时间(AvgPRdTime)，平均直接读取时间 (AvgDRdTime)，平均物理写入时间(AvgPWrTime)，以及平均直接写入时间(AvgDWrTime)。这四个条目直接反应了I/O子系统的性能。如果用户在各项读操作和写操作中，观察到不寻常的大量时间消耗，此时用户应当深入分析I/O子系统。

3.2 表空间监控 (t)

图3.表空间监控

表空间监控模式为每一个表空间提供详细的监控信息。列Hit Ratio%和列Async Read%对很多用户来说非常重要。在数据库级别下只监控缓存池命中率，你可能得不到足够精确的信息。在包含许多表空间的环境下，一个发生在单个表空间的错误查询语句会因平均所有表空间的命中率而被掩盖。在表空间层级上监控列Hit Ratio%和Async Read% 可以有效分析系统的工作细节。

增量逻辑读取(写入)和增量物理读取(写入) (Delta l_reads(writes) 和 Delta p_reads(writes))说明了那些表空间有多 “忙碌”。 一些表空间可能没有很高的缓存池命中率，但它们也可能没有太多活动。在大多数情况下，最好将更多的调优工作放在活动更多的表空间，而不是那些空闲的表空间中。

键盘上的方向左键“←”和方向右键“→”可以将列向左或向右滚动。表空间监控模式和一些其他的监控模式可能有多个且不能显示在同一屏的列。通过按方向左键“←”或方向右键“→”，用户可以滚动屏幕以展示更多列。

按方向左键“←”，用户可以看到更多的读/写条目。另外，平均读/写时间(vg RdTime/Avg WrTime)可被用于理解表空间中每次读/写平均耗时。

列Space Used，列Total Size，以及列% Full能够简单方便地理解每个表空间的大小和使用率。

同样还有几个列能用于了解表空间的类型，例如DMS或SMS，以及CIO/DIO是否启用。

3.3 动态SQL监控(D)

图4.动态SQL监控

动态SQL监控模式提供了每一个缓存的SQL语句的详细信息。用户也可以用这个监控模式给指定查询生成db2expln和db2exfmta。

执行次数(Num Execution) 和平均执行时间(Avg ExecTime) 可用于了解指定查询执行了多少次以及平均运行时间是多少。平均CPU时间(Num Execution)可用于与平均执行时间(Avg ExecTime)进行比较，以了解花在CPU活动上的时间百分比，或花在等待锁或I/O上的大部分时间。平均执行时间(Avg CpuTime)

读取行和写入行对于理解查询的行为很有用。例如，如果用户看到一个select查询与大量的写入关联，这可能表明该查询可能存在排序（哈希连接）溢出，需要进一步调整以避免临时空间中的数据溢出。

db2top工具还计算了数据、索引和临时l_reads的命中率(Hit%)，以帮助用户轻松定位出是否需要调整缓冲池大小。平均每次执行排序(AvgSort PerExec) 和排序时间(Sort Time)是两个很好的指标，可以显示执行期间完成了多少排序。

db2top工具还提供了生成db2expln或db2exfmt报告的功能，而无需手动运行命令。通过在动态SQL监控模式下输入大写L，它将提示您输入SQL对应的哈希字符串。SQL哈希字符串是在表的第一列中显示的字符串，例如“00000005429283171301468277”。用户可以复制该字符串并将其粘贴到提示中，然后单击Enter，如图5所示：

图5.动态SQL监控模式-查询文本

然后，选择此屏幕上的e选项生成db2expln输出，或者选择x选项生成db2exfmt输出（如果explain.ddl已导入数据库）。

如果解释表不存在或与当前使用schema不同，将显示一个空屏幕。如果需要，用户可以执行以下命令生成解释表：

3.4 会话监控 (l)

图6.会话监控

会话监控模式提供每个应用程序会话的详细信息。第一列显示Application Handle，以下三列：Cpu%Total、IO%Total、Mem%Total表示此应用程序正在使用的资源的百分比。在大多数情况下，每个会话表示来自应用程序端的一个连接。

列Application Status和一些读写行的统计信息显示在这些列之后。用户还可以在此屏幕上看到LocksHeld，Sorts(sec)和LogUsed信息。当事务日志空间不足时，列LogUsed信息可能会对用户有所帮助。通过使用这个监视元素，用户可以了解哪些应用程序在占用更多的日志空间。

会话监控模式下包含的信息与用户在数据库监控模式下可以看到的信息类似，但会话监控模式下的信息适用于每个应用程序。通常情况下，最好把不同监控模式下的数据组合起来进行性能分析。例如，通过查看会话监控模式和动态SQL监控模式，可以进一步分析显示在数据库监控模式的大量读取的问题，以便把问题涉及范围缩小到特定的应用程序或SQL。

3.5 缓存池监控(b)

图7.缓存池监控

在此监控模式下，db2top提供有关每个缓冲池利用率的信息。用户可以看到缓冲池的一些基本信息，比如读取、写入和大小，还可以看到更高级的矩阵，如Hit Ratio%(缓冲池命中率)和(Async Reads%)。

一般来说，缓冲池命中率可用如下公式计算：

对应文本：

1 – ((pool_data_p_reads + pool_xda_p_reads +

  pool_index_p_reads + pool_temp_data_p_reads

  + pool_temp_xda_p_reads + pool_temp_index_p_reads )

  / (pool_data_l_reads + pool_xda_l_reads + pool_index_l_reads +

  pool_temp_data_l_reads + pool_temp_xda_l_reads

  + pool_temp_index_l_reads )) * 100%

3.6 锁监控(U)

图8.锁监控

锁定问题是应用程序诊断过程中最常见的问题之一。使用db2top工具，用户可以轻松列出应用程序中的锁。

使用db2top分析锁等待问题也更容易。下面的图9、10和11是在db2bp应用程序正在等待另一个db2bp会话的测试场景中获取的。

图9.锁等待–Application status

在图9中，第一列Agent Id(State)中列出了两个代理（代理24和代理9）。你可以在第三列Application Status(应用程序状态)中看到，其中一个代理（代理24）处于锁定等待状态(Lock Waiting status)。

图10.锁等待–Lock status

如果用户希望在锁监控模式下中看到更多信息，通过按键盘上的左箭头“←”，会显示更多的列，如图10所示。在锁状态列(Lock Status)中，除一个锁外，所有锁都处于已授权状态(Granted status)：“-”状态的锁是阻塞的锁。在锁模式列（Lock Mode）中，显示了包括请求的锁模式(S)和正在保持的锁（IX）等。

图11.锁等待–Table name

如图11所示，在这个特别的例子里，代理24正试图请求表TAOEWANG.T1的S锁，可它已被持有TAOEWANG.T1表上IX锁的代理9锁定。

在锁监控模式中db2top提供的另一个非常有用的特性是锁链分析。如果问题涉及到多个应用程序，那么想找出锁等待关系就不那么容易。因此为了使用户更方便地理解应用程序之间的锁关系，db2top工具提供了一个有用的特性：动态地绘制锁链。

通过输入大写L可展示锁链，如图12所示：

图12.锁等待–Lock chain

3.7 表监控 (T)

图13.表监控

表监控模式显示数据库中的表信息。在当前时间内未被访问的空闲表以白色显示。正在访问（活动）的表以绿色显示。

列Delta RowsRead(Written)/s表示在使用时间内读写的行除以时间间隔。这个数字显示各表在当前时间的使用频率。

另外还有关于表本身的信息。列数据页（Data Pages）和索引页（Index Pages）表示表中有多少页。表类型（Table Type）和表大小（Table Size）对于理解表的属性也很有用。

另一个重要的列是Rows Overflows/s，它表示在当前时间内每秒多少行数据发生了溢出。溢出的行会产生数据碎片。如果这个列数值过高，用户应该通过使用REORG重新构建表来清除碎片，以提高表的性能。

3.8 瓶颈监控 (B)

图14.瓶颈监控

瓶颈分析是DBA不能忽视的过程。他们想知道哪个代理（应用程序）严重限制了整个DB2系统中特定组件的性能或容量，而db2top通过显示关键服务器资源的主要消费方，可解决这个问题。而且工具中会显示消耗每个类别大部分资源的代理ID。

标题“Bottleneck”下的方框用于各种数据库操作的时间分析：

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 + direct_read_time + direct_write_time).

{用于计算每个操作的百分比所用的时间= (等待锁定时间+排序时间+bp读取时间+bp写入时间+异步读取时间+异步写入时间+预取等待时间+直接读取时间+直接写入时间) }

下列是每个操作的预估百分比：

· wait lock ms: (wait lock time)/(elapsed time) = 80%

· sort ms : (sort time)/(elapsed time) = 0

· bp 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)/(elapsed time) = 2%

· dir r/w ms: (direct read and write time)/(elapsed time) = 2%

·

“Bottleneck”瓶颈监控模式下的主体显示每个服务器资源中哪个代理是瓶颈。

“Bottleneck”瓶颈监控模式下的第一列，Server Resource，展示监控的服务器资源类型：

· 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 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.

· 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 agent 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).

例如：图14显示了代理683，即db2bp（DB2后端进程），显然是瓶颈。

至于内存使用瓶颈分析，您可以在图14中看到以下内容：

这表明在所有的代理中，代理17，即另一个db2bp（DB2后端进程），消耗了最多的内存：17.11%，共计832.0K。

4.其他

db2top工具的设计理念和DB2 Health Monitor工具大不相同。DB2 Health Monitor设置了一组阈值，并持续的监控这些矩阵，一但达到阈值，DB2 Health Monitor则会触发告警机制。db2top是一款可以周期地获取快照基础工具，它让用户无需分析快照文件而直观地得出结果。

db2top能让用户能够在文本构成的图形界面中监控DB2系统。它可用于确定DB2在一段时间的运行中内是否存在问题，并缩小问题的根因范围。用户会发现在监控实时系统和调试日常工作中的问题方面，这是一个很实用的工具。