DB2性能监控 1——快照

</div>

你怎么知道什么地方是你的调整努力的焦点呢？还是做个快照吧。当你回顾我最近的专栏时，我总推荐DBA们在动手处理做性能调整当中一定要制定明确详细的计划；在头脑里一定要有个现实的可测量的目标。否则，就会成为一个无意义的练习。在改进数据库性能的时候，你必须首先清楚哪里会是性能的瓶颈并且有相应的对策。这就是DB2 UDB系列产品中性能监控工具的用武之地。从这个专栏开始我将为你讲述一系列如何使用这些工具来确定你应该关注调整效果地地方，并且发现是否调整有效的解决问题。 在这一部分，我将介绍可使用的工具同时将详细说明其中之一（快照监视器）以及与它相关的开关参数。在下个专栏中我将会介绍事件监视器。DB2 数据库系统监视器虽然它的名字听起来有些像是一个单独的工具，其实数据库系统监视器实际上是由两种不同类型的监视工具组成，他们负责捕获和返回系统信息：快照监视器和一个或者更多个事件监视器。快照监视器会让你获得在一个指定的时间点上的状态映像。 事件显示器在指定时间发生时获取监视器数据并且将它们记入日志文件。这两种类型所收集的信息都存储于监视器要素中（有时被认为是数据要素）；每个要素被设计成存储指定类型的信息。 下面列出的是可利用的监视器要素名单：计数器 用来保留活动或者事件发生次数的合计值（例如，对于一个数据库的已经执行的SQL语句的的总数)。计数器数值得增长贯穿监视器的生命周期；而在许多情况下它有可能会重置计数器监视器要素。 Gauges 表明一个项目的当前值（例如，当前连接到数据库的应用程序的数量。） 与计数器值不同于的是，Gauges的值可以变高或者变低；他们在任一被测量的点实时的值通常取决于数据库活动的级别。 Watermarks 表明一个指标在监视开始以后所能达到的最大值或最小值（例如，更新操作所影响的最大行数）。信息要素 提供所有监视活动执行的细节信息（例如，缓冲池名称、数据库名称和别名、详细路径等等）。时间戳 表明一个活动或者事件发生的日期和时间（例如，第一次连接数据库建立的日期和时间）。时间戳被看成是从1970 年1月1 日开始消逝的秒和微妙的数量的值。时间要素 记录时间被花费于执行一个活动或事件的成本（例如：进行排序操作时间花费）。时间要素的值会以从活动或事件开始所流逝的秒和微秒的数量形式来表现。一些时间要素可以被重置。数据库系统监示器使用这些要素的一些组合来获取监视数据并且为每一个要素的数据存储提供了几种选择。快照和事件监视器均可以给予你存放所有被收集的数据在文件或数据库表的选择权，通过屏幕察看或者使用一个定制的程序去处理它。数据库系统监视器通过一些使用自描述的数据流来将监视数据返回到客户端应用程序。使用快照监视应用程序，你可以调用适当的API 获得快照信息然后处理返回的数据流。使用事件监视应用程序，你事先准备从文件或命名管道来接收数据，激活相应的事件监视器，然后按照刚才接收数据那样处理数据流。快照监视器向我提到的一样，快照显示器被设计用于收集那些在它控制下的某一特定时间点的DB2 UDB实例和一些数据库的状态的信息。快照对于确定一个数据库系统的状态是非常有用的。采用固定的时间间隔，他们能够提供出一写让你观察取向和辨认潜在的问题范围的信息。快照监视通过在命令行处理器（CLP）中执行GET SNAPSHOT命令或者通过从应用程序中调用db2GetSnapshot()和db2gGetSnapshot()（如果使用除C或者C++之外的高级编程语言）API。 开关虽然快照监视器信息有助于辨认问题范围，收集数据经常会引起额外的处理负担。例如，为了计算执行SQL语句总的时间花费，DB2 数据库管理器必须在SQL语句执行前后去调用操作系统级命令用来获得时间戳信息。 这些系统级调用的成本可能是昂贵的。其它副作用是增加内存的使用：快照监视器数据是收集和存放在内存中而不是在某些特定的表或者外部文件中。为了有助于减少收集快照监视器数据的过载需求的数量，DB2推荐使用控制被收集新的的数量和类型的快照监视器开关。像其他基本开关一样，每个快照监视器都有开和关两种状态的设置。当快照监视器开关打开的时候，在这个开关控制之下的一些监视器要素的信息被收集起来。相反也是。（注意：一定数量的监视信息是不受这些开关的控制因此这些信息不管那些开关被设置成什么状态总会被收集的。）表1 列出了可利用的快照监视器开关参数并且描述了当这个开关被打开始后可以收集信息的类型。除了TIMESTAMP缺省值是打开的以外，所有可利用的快照显示器缺省都是关闭的。

 2 3 4  下一页</div> </div> </div> </div> </div>