性能监控2
Performance Monitoring, Part 2
Roger Sanders 著
笑熬浆糊 译
天堂鸟自由空间原创作品
天堂鸟自由空间©2002-2005版权所有
转载请保持文档的完整性
访问更多可以浏览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:jackey.wu@163.com
性能监控2
Roger Sanders 著
笑熬浆糊 译
原文出处：《DB2 Magazine》 Quarter 3, 2004 Vol. 9, Issue 3
事件监视器超越了性能线索快照。在此系列的第一篇中，我指出DB2的性能监视工具趋向于一个有组织、有目标导向的调整结果。简单的说，他们能帮助你确定性能问题的症结所在并且给你一些改进的方法。你也许还记得数据库系统监视器是由两种不同的监视工具组成：一个快照监视器和一个或多个事件监视器。在上个章节，我详细介绍了快照监视器以及它是怎样用于捕获实例或数据库在既定时间点上的当前状态信息。在本章，我将要来介绍事件监视器是怎么被用于捕获那些不能被快照监视器所抓取情况下的监视器数据。事件监视器
事件监视器收集监视器数据例如特定事件或者事务发生。因此，事件监视器提供了一个当事件或者活动发生的时候不能使用快照监视器监视时搜集数据库系统监视器数据的方法。例如，假设你想要捕获每当死锁周期的发生时的监视器数据。如果你对死锁的概念比较熟悉的话，你应该知道一个被称之为死锁监听器的特殊进程在后台安静的运行并且在预定的间隔时间内会“苏醒”用以为死锁周期扫描当前正在锁定的系统。如果死锁周期被发现，死锁监听器将会随机选择、回滚并且终止涉及在此次周期中的任意一个事务。结果，被选择出来的那个事务将会接受到是一个SQL错误代码，并且所有实际上已经获得的所被释放以便于剩下的事务能够继续执行。像这样一系列的事件信息不能被快照监视器所捕获，这有很大的可能是因为死锁周期可能在快照执行很久之前就已经被破坏了。然后，事件监视器却可以捕获该事件的重要信息，因为它可以在死锁周期被检测到的瞬间被激活。这两种监视器的另外一个显著的不同是：快照监视器以后台进程的方式驻留，从一个数据库连接建立就开始捕获监视器数据；相反地，事件监视器必须在他们使用之前专门去建立和激活。几个不同的事件监视器可以共存，并且每个事件监视器只有在特定类型的事件或者事务发生的时候才会被激活。表1显示的就是可以导致事件监视器被激活的一些事件类型，以及被每个事件类型所搜集的监视器数据的种类。
表1 事件类型和他们对应的数据由于事件监视器是特殊的数据库对象因此它必须在使用之前创建，它们只能收集发生在它们被定义的数据库中事件或者事务的监视器数据。你不能在实例级使用事件监视器来收集监视器数据。创建事件监视器
你可以直接在控制中心中创建事件监视器（从事件监视器菜单选择创建事件监视器），也可以通过执行CREATE EVENT MONITOR 的SQL语句来创建它，它的基本语法如下：CREATE EVENT MONITOR [Name]
FOR [DATABASE |
BUFFERPOOLS |
TABLESPACES |
TABLES |
DEADLOCKS < WITH DETAIL > |
CONNECTIONS < WHERE [EventCondition] > |
STATEMENTS < WHERE [EventCondition] > |
TRANSACTIONS < WHERE
[EventCondition] > , ...]
WRITE TO [TABLE [GroupName] (TABLE
[TableName]) |
PIPE [PipeName] |
FILE [DirectoryName]]
[MANUALSTART | AUTOSTART]
说明：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] <BUFFER>。MonitorName指明你需要强制立即输出他的活动内部缓存到目标空间的事件监视器的名称。强制将CONN_EVENTS事件监视器活动内部缓存的内容写入到相应的空间，你可以执行FLUSH EVENT MONITOR CONN_EVENTS语句。缺省情况下，早先被写入事件监视器目标空间的那些记录被记录在事件监视器日志当中并且打上了一个部分记录信息的标志。然而，如果你在执行FLUSH EVENT MONITOR的过程中指明了BUFFER选项的话，只有出现在事件监视器活动内部缓存的监视器数据才会被写入到事件监视器的目标空间中，同时在事件监视器日志中没有部分的记录被记录。当事件监控器被清除后，计数器并没有复位。结果会造成，当事件监控器被正常触发时，已经被生成的没有使用FLUSH EVENT MONITOR语句的事件监控器记录，仍然会被生成。事件监视器数据
有些时候，你想要察看事件监视器收集的数据。如果这些收集到的数据是写入到一个命名管道，那么在管道末端负责接受的应用程序通常是以在它接受到数据的时候显示出监视器数据的形式作为相应。如果事件监视器把数据写入表或者一系列文件中的话，你可以通过一个名为事件分析器（Event Analyzer）的专用工具来察看数据或者使用Event Monitor Productivity Tool。事件分析器是一个GUI工具，它可以通过在控制中心选中你所想得到的事件监视器并且从事件监视器菜单中选择适当的动作或通过执行db2eva命令来激活。图1显示事件分析器在它第一次激活时候的典型示例。图1 时间分析工具
一旦它被激活，事件分析器允许你向下挖掘并浏览一个详细的事件监视器捕获的信息。事件分析器只能用于查看那些被收集并且存储与数据库表中的事件监视器数据。如果要查看被写入到文件或者命名管道里面的监视器数据，你将要使用基于文本的Event Monitor Productivity Tool，它可以从一个事件监视器数据文件或命名管道中收取数据并且将这些数据处理成一个格式化的报告。（事件监视器文件和命名管道包含一个必须要在展示之前格式化的二进制逻辑数据群流）通过db2evmon命令可以激活Event Monitor Productivity Tool。这个命令的基本语法是db2evmon -db [DatabaseAlias] -evm [MonitorName] 或者 db2evmon -path [MonitorTarget]
说明：DatabaseAlias指明所要定义事件监视器的数据库的别名
MonitorName指明所分配的需要显示数据的事件监视器的名称
MonitorTarget指明已经被指定事件监视器收集的数据存储的位置（目录或命名管道）
作为例子，为了格式化和输出被定义在SAMPLE数据库中的事件监视器CONN_EVENTS所有被收集的数据，你可以通过执行db2evmon -db SAMPLE -evm CONN_EVENTS命令来得到。例如，假设你要使用下面的语句创建CONN_EVENTS事件监视器CREATE EVENT MONITOR CONN_EVENTS
FOR CONNECTIONS
WRITE TO FILE 'C:\MONDATA'
AUTOSTART
假设一个应用程序与SAMPLE数据库已经建立起一个连接（使事件监视器可以收集和记录监视数据）。db2evmon -db SAMPLE -evm CONN_EVENTS命令返回输出信息的文件头部分表1中的样例输出类似。表1事件监视器CONN_EVENTS的输出样例
Reading C:\DBSIO\00000000.EVT ...
-----------------------------------------------------------------------
EVENT LOG HEADER
Event Monitor name: CONN_EVENTS
Server Product ID: SQL08015
Version of event monitor data: 7
Byte order: LITTLE ENDIAN
Number of nodes in db2 instance: 1
Codepage of database: 1252
Territory code of database: 1
Server instance name: DB2
-----------------------------------------------------------------------
-----------------------------------------------------------------------
Database Name: SAMPLE
Database Path: C:\DB2\NODE0000\SQL00001 First connection timestamp: 03-24-2004 16:53:00.020233
Event Monitor Start time: 03-24-2004 16:53:00.155733
-----------------------------------------------------------------------
3) Connection Header Event ...
Appl Handle: 16
Appl Id: *LOCAL.DB2.0120C4215303
Appl Seq number: 0001
DRDA AS Correlation Token: *LOCAL.DB2.0120C4215303
Program Name : db2evmon.exe
Authorization Id: RSANDERS
Execution Id : RSANDERS
Codepage Id: 1252
Territory code: 0
Client Process Id: 1788
Client Database Alias: SAMPLE
Client Product Id: SQL08015
Client Platform: Unknown
Client Communication Protocol: Local
Client Network Name:
Connect timestamp: 03-24-2004 16:53:00.020233
4) Connection Event
Appl Handle: 16
Appl Id: *LOCAL.DB2.0120C4215303
Appl Seq number: 0003
Record is the result of a flush: FALSE
Application Status: SQLM_UOWWAIT
Lock Statistics:
Lock Waits: 0
Total time waited on locks (milliseconds): 0
Deadlocks: 0
Lock escalations: 0
X lock escalations: 0
Lock timeouts: 0
Sort Statistics:
Sorts: 0
Total sort time (milliseconds): 0
Sort overflows: 0
Hash Statistics:
Hash Joins: 0
Hash Loops: 0
Hash Join Small Overflows: 0
Hash Join Overflows: 0
Buffer Pool Statistics:
Buffer pool logical data page reads: 12
Buffer pool physical data page reads: 4
Buffer pool data page writes: 0
Buffer pool logical index page reads: 30
Buffer pool physical index page reads: 18
Buffer pool index page writes: 0
Buffer pool read time (microseconds): 0
Buffer pool write time (microseconds): 0
Time spent waiting for a prefetch: 0 milliseconds
Unread prefetch pages: 0
Workspace Statistics:
Shared workspace high water mark: 0
Total shared workspace overflows: 0
Total shared workspace section lookups: 0
Total shared workspace section inserts: 0
Private workspace high water mark: 13746
Total private workspace overflows: 0
Total private workspace section lookups: 2
Total private workspace section inserts: 2
Direct I/O Statistics:
Sectors read directly: 14
Sectors written directly: 0
Direct read requests: 5
Direct write requests: 0
Direct read time: 0
Direct write time: 0
SQL Statement counts
Commit SQL statements: 1
Rollback SQL statements: 0
Dynamic SQL statements: 1
Static SQL stmts: 3
Failed SQL statements: 0
Select SQL statements: 2
Data Definition Language SQL statements: 0
Update/Insert/Delete SQL statements: 0
Internal counts
Internal auto rebinds: 0
Internal rows deleted: 0
Internal rows updated: 0
Internal rows inserted: 0
Internal commits: 0
Internal rollbacks: 0
Internal rollbacks due to deadlock: 0
Row counts
Rows deleted: 0
Rows inserted: 0
Rows updated: 0
Rows selected: 2
Rows read: 6
Rows written: 0
Binds/Precompiles: 0
Rejected block cursor requests: 0
Accepted block cursor requests: 0
Package Cache Statistics
Package Cache Lookups: 3
Package Cache Inserts: 2
Section Lookups: 3
Section Inserts: 2
Catalog Cache Statistics
Catalog Cache Overflows: 0
Catalog Cache High Water Mark: 0
Catalog Cache Lookups: 2
Catalog Cache Inserts: 0
CPU times
User CPU time: 0.000000 seconds
System CPU time: 0.000000 seconds
Memory usage:
Memory Pool Type: Other Memory
Current size (bytes): 16384
High water mark (bytes): 98304
Maximum size allowed (bytes): 1071644672
Memory Pool Type: Application Heap
Current size (bytes): 212992
High water mark (bytes): 212992
Maximum size allowed (bytes): 1277952
Memory Pool Type: Application Control Heap
Current size (bytes): 16384
High water mark (bytes): 16384
Maximum size allowed (bytes): 704512
Disconnection Time: 03-24-2004 16:53:00.191692
接下来
快照监视器和事件监视器被设计用于帮助你确定并修正那些已经影响数据库系统的性能问题。DB2 UDB v.8.1还提供了两种额外的工具（the Health Monitor and Health Center）来帮助你在它们变成真正的问题之前找出它的前兆来。这就是接下来的章节中要说的主题。 完整版本（包含图片的PDF文件）请到http://hbird.vicp.net/viewthread.php?tid=1486处下载
