DB2 性能监控2[翻译]

性能监控 2

Performance Monitoring, Part 2

Roger Sanders 著

笑熬浆糊译

天堂鸟自由空间原创作品

转载请保持文档的完整性

访问更多可以浏览 http://hbird.vicp.net/myself.html

或 http://hbird.myrice.com/myself.html

Blog: http://blog.csdn.net/mr_bean

BBS 讨论 : http://hbird.vicp.net

mail:[email protected]

** 性能监控 2

Roger Sanders 著

笑熬浆糊译

** 原文出处：《 DB2 Magazine ** ** 》 Quarter 3, 2004 Vol. 9, Issue 3

** 英文原文（由于文章翻译未经授权，请在转载时保留原文链接）

事件监视器超越了性能线索快照。

在此系列的第一篇中，我指出 DB2 的性能监视工具趋向于一个有组织、有目标导向的调整结果。简单的说，他们能帮助你确定性能问题的症结所在并且给你一些改进的方法。

你也许还记得数据库系统监视器是由两种不同的监视工具组成：一个快照监视器和一个或多个事件监视器。在上个章节，我详细介绍了快照监视器以及它是怎样用于捕获实例或数据库在既定时间点上的当前状态信息。在本章，我将要来介绍事件监视器是怎么被用于捕获那些不能被快照监视器所抓取情况下的监视器数据。

事件监视器

事件监视器收集监视器数据例如特定事件或者事务发生。因此，事件监视器提供了一个当事件或者活动发生的时候不能使用快照监视器监视时搜集数据库系统监视器数据的方法。

例如，假设你想要捕获每当死锁周期的发生时的监视器数据。如果你对死锁的概念比较熟悉的话，你应该知道一个被称之为死锁监听器的特殊进程在后台安静的运行并且在预定的间隔时间内会“苏醒”用以为死锁周期扫描当前正在锁定的系统。如果死锁周期被发现，死锁监听器将会随机选择、回滚并且终止涉及在此次周期中的任意一个事务。结果，被选择出来的那个事务将会接受到是一个 SQL 错误代码，并且所有实际上已经获得的所被释放以便于剩下的事务能够继续执行。像这样一系列的事件信息不能被快照监视器所捕获，这有很大的可能是因为死锁周期可能在快照执行很久之前就已经被破坏了。然后，事件监视器却可以捕获该事件的重要信息，因为它可以在死锁周期被检测到的瞬间被激活。

这两种监视器的另外一个显著的不同是：快照监视器以后台进程的方式驻留，从一个数据库连接建立就开始捕获监视器数据；相反地，事件监视器必须在他们使用之前专门去建立和激活。几个不同的事件监视器可以共存，并且每个事件监视器只有在特定类型的事件或者事务发生的时候才会被激活。表 1 显示的就是可以导致事件监视器被激活的一些事件类型，以及被每个事件类型所搜集的监视器数据的种类。

表 1 事件类型和他们对应的数据

由于事件监视器是特殊的数据库对象因此它必须在使用之前创建，它们只能收集发生在它们被定义的数据库中事件或者事务的监视器数据。你不能在实例级使用事件监视器来收集监视器数据。

创建事件监视器

你可以直接在控制中心中创建事件监视器（从事件监视器菜单选择创建事件监视器），也可以通过执行 CREATE EVENT MONITOR 的 SQL 语句来创建它，它的基本语法如下：

说明：

_ Name _ 是被分配给这个事件监视器的名称
_ EventCondition _ 用于确定事件监视器将会为哪一个连接、语句或者事务收集数据的条件
_ GroupName _ 确定被定义的目标表上的逻辑数据群组（使用这个参数的可用值可以参见表 1 ）
_ TableName _ 确定指派给所有事件监视器写入的数据库表的名称
_ PipeName _ 确定指派给所有事件监视器写入命名管道的名称
_ DirectoryName _ 确定指派个包含事件监视器的一个或者多个文件写入目录的名称

注意：在尖括号中出现的参数是可选择的；出现在方括号里面的参数或者选择是必须的。察看 CREATE EVENT MONITOR SQL 语句的完整语法，参见 IBM DB2 Universal Database, Version 8 SQL Reference Volume 2 文档。

我们假设如果你想创建一个关于捕获所有应用级的计数器的值并且每当应用程序中止与数据库的时候把它们写入名为 CONN_DATA 的数据库表中的一个事件监视器。你可以执行下面的 CREATE EVENT MONITOR 语句来完成它。

` CREATE EVENT MONITOR CONN_EVENTS

FOR CONNECTIONS
WRITE TO TABLE CONN (TABLE CONN_DATA)

现在我们假使你要创建一个用来捕获缓冲池和表空间事件的监视器数据并且要把所有收集到的数据写入到一个名为 /export/home/bpts_data 目录的事件监视器。你可以执行下面的 CREATE EVENT MONITOR 语句来完成它。

` CREATE EVENT MONITOR BPTS_EVENTS

FOR BUFFERPOOLS, TABLESPACES
WRITE TO FILE '/export/home/BPTS_DATA'

正如你所看到的，当你创建一个事件监视器的时候你必须去指定激活监视器的事件的类型以及所有收集到的数据写入的地方。

一个事件监视器的输出可以写入到一个或者多个的数据库表、外部文件或一个命名管道。表和管道型的事件监视器流事件直接记录到指定表或者命名管道中。另一方面，文件型事件监视器流事件记录成一系列具有 .evt 扩展名的 8 位编码的文件（例如 00000000.evt, 00000001.evt 等等）。存储在这些文件中的数据也许被处理成类似于一个单独的数据流存储的一个单独的文件中。虽然这些数据实际上是被分割成许多小的数据块。（数据流开始于 00000000.evt 文件的第一个字节，结束于创建的最后一个文件的最后一个字节）

如果你指明事件监视器的输出会存储在数据库表里面的话，那么所有的目标表将会在 CREATE EVENT MONITOR 语句被执行的时候自动被创建。（如果由于一些原因创建表失败，那么会返回一个错误代码同时 CREATE EVENT MONITOR 语句执行也就失败）然而，如果你指明事件监视器的输出会写入一个或者多个外部文件，或者一个命名管道的时候，这个输出目录或者命名管道则必须事先存在并且当事件监视器被激活时 DB2 数据库管理器实例自身必须能够对它进行写入。另外，如果使用的是一个命名管道，应用程序监视的命名管道必须要运行同时它也必须在事件监视器被激活之前将管道打开准备读取信息。

开始和停止事件监视器

如果你在创建一个事件监视器的时候指明使用 AUTOSTART 选项，那么监视器将会在包含它的数据库开始的时候自动开始。（数据库开始于使用 ACTIVATE DATABASE 命令来激活或者第一个与该数据库连接建立的时候。）如果你使用 MANUALSTART 或者不知名任何选项（在这里， MANUALSTART 是缺省值），它的结果就是事件监视器不会收集监视器数据直至它开始活动。事件监视器可以通过执行 SET EVENT MONITOR SQL 语句来开始（停止）。它的基本语法如下：

` SET EVENT MONITOR [MonitorName] STATE < = > [MonitorState]

说明：

_ MonitorName _ 指明需要改变状态的事件监视器的名称
_ MonitorState _ 指明指派给需要修改状态的事件监视器的状态。想要开始事件监视器的话（换句话说，也就是把它置为激活状态），你要把它的值置为 1 。相反地，需要置为 0 。

现在我们假设你想要开始名为 CONN_EVENTS 的事件监视器，它创建的时候采用了 MANUALSTART 选项。你可以这么作：

` SET EVENT MONITOR CONN_EVENTS STATE 1

如果你想要得到与上面相反地结果，也就是说停止 CONN_EVENTS 事件监视器的话，你可以执行这句：

` SET EVENT MONITOR CONN_EVENTS STATE 0

同时，你也可以通过在控制中心的事件监视器菜单中选中并且选择你想要得动作来开始和停止事件监视器

事件监视器一旦开始运行，它就会在后台静静等待所为他设计的要监视的相应事件或者事务的出现。当这种情况出现的时候，事件监视器会收集合适的监视器数据信息并且将它们写入到监视器的输出对象中（表、目录或者命名管道）。在这个时候，这些步骤将由事件或者事务自身去控制；数据库管理员不需要去执行任何额外的步骤去收集事件监视器数据，这点与快照监视器在使用的时候是不同的。

强制输出

在有些时候，低记录执行频率的事件监视器（例如被设计于监视数据库事件的监视器）会把事件监视器数据存储在内存中而没有存储在事件监视器的目标空间上（因为这时候仅仅是部分事件记录存在）。如果你在此时想要去检查一下事件监视器的活动内部缓存里面的内容的话，可以执行 FLUSH EVENT MONITOR SQL 语句。该语句的语法是 FLUSH EVENT MONITOR [MonitorName]

  1<buffer> 。  MonitorName  指明你需要强制立即输出他的活动内部缓存到目标空间的事件监视器的名称。 
  2
  3##  强制将  CONN_EVENTS  事件监视器活动内部缓存的内容写入到相应的空间，你可以执行  FLUSH EVENT MONITOR CONN_EVENTS  语句。缺省情况下，早先被写入事件监视器目标空间的那些记录被记录在事件监视器日志当中并且打上了一个部分记录信息的标志。然而，如果你在执行  FLUSH EVENT MONITOR  的过程中指明了  BUFFER  选项的话，只有出现在事件监视器活动内部缓存的监视器数据才会被写入到事件监视器的目标空间中，同时在事件监视器日志中没有部分的记录被记录。 
  4
  5##  当事件监控器被清除后，计数器并没有复位。结果会造成，当事件监控器被正常触发时，已经被生成的没有使用  FLUSH EVENT MONITOR  语句的事件监控器记录，仍然会被生成。 
  6
  7###  事件监视器数据 
  8
  9##  有些时候，你想要察看事件监视器收集的数据。如果这些收集到的数据是写入到一个命名管道，那么在管道末端负责接受的应用程序通常是以在它接受到数据的时候显示出监视器数据的形式作为相应。如果事件监视器把数据写入表或者一系列文件中的话，你可以通过一个名为事件分析器（  Event Analyzer  ）的专用工具来察看数据或者使用  Event Monitor Productivity Tool  。 
 10
 11##  事件分析器是一个  GUI  工具，它可以通过在控制中心选中你所想得到的事件监视器并且从事件监视器菜单中选择适当的动作或通过执行  db2eva  命令来激活。图  1  显示事件分析器在它第一次激活时候的典型示例。 
 12
 13图  1  时间分析工具 
 14
 15##  一旦它被激活，事件分析器允许你向下挖掘并浏览一个详细的事件监视器捕获的信息。 
 16
 17##  事件分析器只能用于查看那些被收集并且存储与数据库表中的事件监视器数据。如果要查看被写入到文件或者命名管道里面的监视器数据，你将要使用基于文本的  Event Monitor Productivity Tool  ，它可以从一个事件监视器数据文件或命名管道中收取数据并且将这些数据处理成一个格式化的报告。（事件监视器文件和命名管道包含一个必须要在展示之前格式化的二进制逻辑数据群流） 
 18
 19##  通过  db2evmon  命令可以激活  Event Monitor Productivity Tool  。这个命令的基本语法是 
 20
 21` db2evmon -db [DatabaseAlias] -evm [MonitorName]  ` ` 或者  db2evmon -path [MonitorTarget] 
 22
 23`
 24
 25##  说明： 
 26
 27  * _ DatabaseAlias  _ 指明所要定义事件监视器的数据库的别名 
 28
 29  * _ MonitorName  _ 指明所分配的需要显示数据的事件监视器的名称 
 30
 31  * _ MonitorTarget  _ 指明已经被指定事件监视器收集的数据存储的位置（目录或命名管道） 
 32
 33
 34
 35
 36##  作为例子，为了格式化和输出被定义在  SAMPLE  数据库中的事件监视器  CONN_EVENTS  所有被收集的数据，你可以通过执行  db2evmon -db SAMPLE -evm CONN_EVENTS  命令来得到。 
 37
 38##  例如，假设你要使用下面的语句创建  CONN_EVENTS  事件监视器 
 39
 40` CREATE EVENT MONITOR CONN_EVENTS   
 41FOR CONNECTIONS   
 42WRITE TO FILE 'C:\MONDATA'   
 43AUTOSTART 
 44
 45`
 46
 47##  假设一个应用程序与  SAMPLE  数据库已经建立起一个连接（使事件监视器可以收集和记录监视数据）。  db2evmon -db SAMPLE -evm CONN_EVENTS  命令返回输出信息的文件头部分表  1  中的样例输出类似。 
 48
 49##  表  1  事件监视器  CONN_EVENTS  的输出样例 
 50
 51Reading C:\DBSIO\00000000.EVT ... 
 52
 53\----------------------------------------------------------------------- 
 54
 55EVENT LOG HEADER 
 56
 57Event Monitor name: CONN_EVENTS 
 58
 59Server Product ID: SQL08015 
 60
 61Version of event monitor data: 7 
 62
 63Byte order: LITTLE ENDIAN 
 64
 65Number of nodes in db2 instance: 1 
 66
 67Codepage of database: 1252 
 68
 69Territory code of database: 1 
 70
 71Server instance name: DB2 
 72
 73\----------------------------------------------------------------------- 
 74
 75\----------------------------------------------------------------------- 
 76
 77Database Name: SAMPLE 
 78
 79Database Path: C:\DB2\NODE0000\SQL00001\ 
 80
 81First connection timestamp: 03-24-2004 16:53:00.020233 
 82
 83Event Monitor Start time:  03-24-2004 16:53:00.155733 
 84
 85\----------------------------------------------------------------------- 
 86
 873) Connection Header Event ... 
 88
 89Appl Handle: 16 
 90
 91Appl Id: *LOCAL.DB  2.0120C  4215303 
 92
 93Appl Seq number: 0001 
 94
 95DRDA AS Correlation Token: *LOCAL.DB  2.0120C  4215303 
 96
 97Program Name  : db2evmon.exe 
 98
 99Authorization Id: RSANDERS 
100
101Execution Id  : RSANDERS 
102
103Codepage Id: 1252 
104
105Territory code: 0 
106
107Client Process Id: 1788 
108
109Client Database Alias: SAMPLE 
110
111Client Product Id: SQL08015 
112
113Client Platform: Unknown 
114
115Client Communication Protocol: Local 
116
117Client Network Name: 
118
119Connect timestamp: 03-24-2004 16:53:00.020233 
120
1214) Connection Event 
122
123Appl Handle: 16 
124
125Appl Id: *LOCAL.DB  2.0120C  4215303 
126
127Appl Seq number: 0003 
128
129Record is the result of a flush: FALSE 
130
131Application Status: SQLM_UOWWAIT 
132
133Lock Statistics: 
134
135Lock Waits: 0 
136
137Total time waited on locks (milliseconds): 0 
138
139Deadlocks: 0 
140
141Lock escalations: 0 
142
143X lock escalations: 0 
144
145Lock timeouts: 0 
146
147Sort Statistics: 
148
149Sorts: 0 
150
151Total sort time (milliseconds): 0 
152
153Sort overflows: 0 
154
155Hash Statistics: 
156
157Hash Joins: 0 
158
159Hash Loops: 0 
160
161Hash Join Small Overflows: 0 
162
163Hash Join Overflows: 0 
164
165Buffer Pool Statistics: 
166
167Buffer pool logical data page reads: 12 
168
169Buffer pool physical data page reads: 4 
170
171Buffer pool data page writes: 0 
172
173Buffer pool logical index page reads: 30 
174
175Buffer pool physical index page reads: 18 
176
177Buffer pool index page writes: 0 
178
179Buffer pool read time (microseconds): 0 
180
181Buffer pool write time (microseconds): 0 
182
183Time spent waiting for a prefetch: 0 milliseconds 
184
185Unread prefetch pages: 0 
186
187&lt;p   
188  
189---</buffer>