性能监控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显示的就是可以导致事件监视器被激活的一些事件类型，以及被每个事件类型所搜集的监视器数据的种类。
由于事件监视器是特殊的数据库对象因此它必须在使用之前创建，它们只能收集发生在它们被定义的数据库中事件或者事务的监视器数据。你不能在实例级使用事件监视器来收集监视器数据。
创建事件监视器
你可以直接在控制中心中创建事件监视器（从事件监视器菜单选择创建事件监视器），也可以通过执行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]
