DB2性能监控 1——快照

性能监控 1——快照

 Performance Monitoring, Part 1: It@#s a Snap(shot)

Roger Sanders 著

笑熬浆糊 译

 

天堂鸟自由空间原创作品

天堂鸟自由空间©2002-2005版权所有

转载请保持文档的完整性

访问更多可以浏览http://hbird.myrice.com/myself.html

mailto:jackey.wu@163.com



 

性能监控 1——快照

Roger Sanders 著

笑熬浆糊 译

 

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

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

 

 
你怎么知道什么地方是你的调整努力的焦点呢？还是做个快照吧。当你回顾我最近的专栏时，我总推荐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缺省值是打开的以外，所有可利用的快照显示器缺省都是关闭的。


表1 。 快照监视器开关参数
查看开关设置在某种程度上，由于快照监视器开关控制着当一个快照被打开时缩搜集到的信息的类型和数量，因此你应该在开始你的监视进程之前搞清楚哪些开关是打开的而那些是关闭的。获得这些信息最简单的方法就是通过在CLP中执行GET MONITOR SWITCHES命令。在多分区数据库环境下它的基本语法是：GET MONITOR SWITCHES < AT DBPARTITIONNUM [PartitionNum] > PartitionNum 参数用来说明你需要获取快照监视器开关参数状态的数据库分区。注: 尖括号（<>）显示的参数是可选的参量，而在方括号（[ ]）里面的参数是必须的。获取和显示一个单独分区数据库的快照监视器开关的状况，可以执行GET MONITOR SWITCHES命令。假定均使用缺省的设置，结果如清单1所示.


清单1 。 运行GET MONITOR SWITCHES命令的结果。
从上面可以看到，TIMESTAMP这个快照监视器开关的状态是ON而其他的都是OFF。在这个开关状态后面显示的是这个开关打开的精确日期和时间。改变开关参数 在你知道了每一个可用的快照监视器开关的当前状态以后，你就想在你开始监测之前去改变其中的一个或者多个开关的设置。你可以通过改变相对应的数据库管理器配置参数（参见表 1）或者调用应用程序级db2MonitorSwitches() API函数或执行UPDATE MONITOR SWITCHES命令在实例级修改快照监视器开关的设置（该设置在实例重启后依然有效） 这个命令的基本语法：
UPDATE MONITOR SWITCHES USING [[SwitchID] ON | OFF ,...]
SwitchID 指明一个或者多个需要改变状态的快照监视器开关。（该参数可以是以下其中的一部分或者是全部：BUFFERPOOL, LOCK, SORT, STATEMENT, TABLE, TIMESTAMP, UOW。）要将LOCK和Sort快照监视器开关参数状态设置为ON（实例级别），可以执行UPDATE MONITOR SWITCHES USING LOCK ON SORT ON命令。获取数据 当数据库被激活或者与数据库的连接被建立的时候，快照显示器自动地开始收集监视器数据。但是，在你能够观看被收集的数据之前，你必须选取一个快照。（快照看起来就像是当时那个时间点上的监视要素的映像。）你可以通过调用db2GetSnapshot() API或者执行GET SNAPSHOT命令来得到快照。清单2指明了这个命令的基本语法，DatabaseAlias 用来说明需要手机快照监视器信息的数据库别名。


清单2 。 GET SNAPSHOT命令的句法。
仅仅想得到在工资数据库中被应用程序保持的锁定的快照信息，可以执行 GET SNAPSHOT FOR LOCKS ON PAYROLL命令。该命令输出的工作产品类似于清单3中的结果 (需要注意的是这只是一个非常简单的例子。真正监视器返回的监视数据通常要比这个大得多)


清单3 。 对一个数据库使用GET SNAPSHOT FOR LOCKS命令得到的快照输出的样本。
正如你所看到的，使用GET SNAPSHOT命令(或者db2GetSnapshot() API)可以使用于获取几种不同的类型监视数据，它们包括：DB2 数据库管理器实例数据 同一实例控制下所有活动数据库的数据库数据 应用程序数据 缓冲池活动数据 表空间数据 表数据 锁数据(关于所有保持锁定的锁的信息) 动态SQL 数据(在SQL语句缓存中的当时关于SQL语句的信息) 。 需要注意的是，在快照监视器开关之间有一种直接交互作用可利用并且当某一个快照打开的情况下会收集到不同类型的监视数据。 如果在一个细节描述的快照显示器开关关闭的情况下选取与它相关联的监视元素的快照，那么监视数据不会返回任何信息。（在早先例子中，被列为“未收集”信息的原因就是LOCK的快照监视器开关被设置为关闭状态了。如果在快照打开的状态下没有获取到锁定信息，那么“保持的锁定”的值就会为0并且锁定信息列表就不会被提供出来。） 使用SQL来捕获数据 在DB2 UDB的早些版本中，获取快照监视器数据唯一的方式就是去执行GET SNAPSHOT命令或者从应用程序中调用它对应的API函数。而在DB2 UDB 8.1中，你还可以通过引用20个可用的快照监视器表函数中的一个来构造查询去收集快照数据。表2列出了这些函数以及指明他们所能获取的具体快照信息。


表2. 快照监视器的表函数
用下面的语法将会创建一个引用非数据库管理器级表函数的查询：
SELECT * FROM TABLE ( [FunctionName](@#[DBName]@#,[PartitionNum]) AS [CorrelationName]
在这里FunctionName 用来说明所使用得快照监视器的表函数； DBName 指明需要从那个数据库的快照监视器中搜集数据； PartitionNum 说明需要从那个数据库分区的快照监视器中搜集数据； CorrelationName 则是查询产生的结果数据集的名称。 构造一个引用数据库管理器级的快照监视器表函数查询的语法也是一样的。不同的是：DBName 参数不使用。如果你想要获取一个分区数据库环境里当前分区的快照监视器数据，你可以将PartitionNum参数的值设置为-1；如果你希望获取所有分区的快照监视器数据，可以把它设置为-2。同样，如果你想获取当前连接数据库的快照信息，你可以把DBName参数设定成一个空值，也可以使用一对空的单引号或者用一个CAST操作——例如：CAST (NULL AS CHAR)如果你想要通过使用快照监视器的表函数SNAPSHOT_LOCk来抓取包含被应用程序相关联的当前连接的数据库的锁定数据的快照信息，可以执行下面的语句：
SELECT * FROM TABLE (SNAPSHOT_LOCK (CAST (NULL AS CHAR), -1) AS LOCK_INFO
如果我们使用PAYROLL数据库（先前的例子） 作为当前的被连接的数据库，那么执行GET SNAPSHOT FOR LOCKS ON PAYROLL命令返回的信息将会与先前的那个非常的相似（表3）。重置计数器 另一个监视器要素被称为计数器，它保存一个运行期间的具体活动或事件发生的次数的数量的累积。 典型的计数开始于快照监视器开关打开或与数据库的连接被建立(如果实例级别的监视器被使用，计数开始于应用程序第一次建立与该实例控制下的数据库连接的时候) 。计数一旦开始，他将一直继续到适当的快照显示器开关被关闭或直到所有数据库连接被终止。 但是, 但有时候也可以在你没有改变一个或更多快照显示器开关状态和没有终止和重建所有当前活动数据库的连接情况下可以去重置所有计数器为零。在这种情况下，所有的监视器的计数器可以通过执行RESET MONITOR命令去将他们归零。这个命令的基本语法是：RESET MONITOR ALL 或者 RESET MONITOR FOR [DATABASE | DB] [DatabaseAlias]  [DatabaseAlias]指明名你想要将快照监视器的计数器归零的数据库别名。如果你想要重置一个实例控制下的所有数据库快照监视器的计数器，可以切换到这个实例下执行RESET MONITOR ALL命令。另一方面，如果你只是想要把与PAYROLL数据库相关联的快照监视器的计数器重置为0的话，那么你可以这么做——执行RESET MONITOR FOR DATABASE PAYROLL命令。记住，你不能使用RESET MONITOR命令来有选择性地对快照监视器开关所控制的特殊的监视器组重置他们的计数器。 反而，你必须将适当的快照监视器开关关闭和然后再打开或者终止并且重建数据库连接。  接下来快照监视器只是DB2 UDB可利用的监视工具当中的一个，并且在有些时候快照并不是很好的选择。 在下个章节中, 我将介绍入何时用事件监视器去收集那些快照监视器所没有办法处理的事件或者活动的监视数据。

原文转自：http://www.ltesting.net