简介： Optim Performance Manager for DB2 V4.1 (本文中简称为 OPM ) 是数据库性能监控工具，能够灵敏的捕获数据库的各种信息并以警报形式迅速发布信息，通过图表直接展示系统运行情况，其详细信息界面深入地揭示问题的根源，帮助数据库管理员“防患于未然”。本文介绍如何使用 OPM 监控锁信息,解决死锁、锁等待以及应用程序挂起等问题。
DB2 通过使用锁 把事务彼此隔离开来。锁是一种用来将数据资源与单个事务关联起来的机制，其用途是当某个资源与拥有它的事务关联在一起时，控制其他事务如何与该资源进行交互。（我们称与被锁定的资源关联的事务持有 或拥有 该锁）DB2 数据库管理程序用锁来禁止事务访问其他事务写入的未提交数据（除非使用了未提交的读隔离级别），并禁止其他事务在拥有锁的事务使用限制性隔离级别时对这些行进行更新。一旦获取了锁，在事务终止之前，就一直持有该锁；该事务终止时释放锁，其他事务就可以使用被解锁的数据资源了。
尽管可以通过建立锁超时来避免一个事务无限期地等待另一个事务释放锁的情况，但是锁超时无法解决两个或更多事务对锁的争用。这种情况称为死锁 或死锁循环。说明死锁的发生原因的最佳方式是举例说明：假定事务 1 在表 A 上获取了互斥（X）锁，而事务 2 在表 B 上获取了互斥（X）锁。现在，假定事务 1 尝试在表 B 上获取互斥（X）锁，而事务 2 尝试在表 A 上获取互斥（X）锁。这两个事务的处理都将被挂起，直到同意第二个锁请求为止。但是，因为在任何一个事务释放它目前持有的锁（通过执行或回滚操作）之前，这两个事务的锁请求都不会被同意，而且因为这两个事务都不能释放它目前持有的锁（因为它们都已挂起并等待锁），所以它们都陷入了死锁循环。当死锁循环发生时，除非某些外部代理进行干涉，否则所涉及的所有事务将无限期地等待释放锁。在 DB2 UDB 中，用于处理死锁的代理是称为死锁检测器 的异步系统后台进程。死锁检测器的惟一职责是定位和解决在锁定子系统中找到的任何死锁。通过本文就可以了解到， 如何通过 OPM 快速的定位，解决死锁问题。
每当一个事务在特定数据资源（例如，表或行）上持有锁时，直到持有锁的事务终止并释放它所获取的所有锁之前，其他事务对该资源的访问都可能被拒绝。如果没有某种锁超时检测机制，则事务可能无限期地等待锁的释放。这种情况就叫锁等待，例如，有可能出现这种情况：一个事务在等待另一个用户的应用程序所持有的锁被释放，而该用户离开了他或她的工作站，但忘了执行一些允许应用程序终止拥有锁的事务的交互。显然，此类情况会导致极差的应用程序性能。要避免发生此类情况时阻碍其他应用程序的执行，可以在数据库的配置文件中指定锁超时值（通过 locktimeout 数据库配置参数）。该参数控制任何事务等待获取所请求的锁的时间。如果在指定的时间间隔过去之后还未获得想要的锁，则等待的应用程序接收一个错误，并回滚请求该锁的事务。但是，在没有设定锁超时的情况下或者未到锁超时时间限定范围内，我们如何知道已经造成了锁等待？又如何去解决呢？本文将介绍如何通过 OPM 去解决这些问题。
IBM Optim Performance Manager for DB2 简介
IBM Optim （原 Data Studio）软件家族作为 IBM 软件产品组合的新成员，有效集成了数据库应用程序的设计、开发、部署、操作、优化、治理这几个数据生命周期阶段，并实现不同 IT 角色之间的统筹协作。在为应用程序和工作负载进行前摄性的规划和优化领域，Optim 家族提供了 Optim Query Tuner、Optim Performance Manager、Optim pureQuery Runtime 等调优工具。而 Optim Performance Manager，简称 OPM, 其前身是 Optim Performance Expert。在数据管理生命周期中处于以下位置：
OPM 是一款基于 Web 开发的数据库性能监控工具，同时作为一款 B/S 产品，OPM 具有非常强的可操作性。具备以下功能：
- 对多个 DB2 实例进行统一的监控；
- 对 DB2 引擎和应用的监控；
- 分析和控制，提供实时及历史数据；
- 可读性强的图表；
- 多分区上的性能管理；
- 集成对操作系统的监控；
- 集成对操作系统的监控；
- 监控资源消耗 ,SQL 语句及事务 , 锁冲突等。
首先，打开 OPM 监控主页，并切换到管理数据库连接界面。如图 2 所示：
点击“添加（Add …）”按钮，输入用户验证信息，在弹出的界面中设置添加需要监控的数据库（本文以数据库 GSDB 为例）即可，点击“确定（OK）”后，被监控数据库（GSDB）即被添加到 OPM 监控数据库，如下图所示：
数据库添加成功后，需要设置监控项目，OPM 按照摄制的选项对数据库性能进行监控。切换到图 2 所示的数据库管理连接界面，进行设置，选中要监控数据库的节点，点击“配置监视 (Configure Monitoring … )”如图 4 所示：
选择想要监控的项目，如图 5 所示：
从“任务管理器（Task Manager）”—〉“正在运行的仪表板（Inflight Dashboards）”—〉“锁定（Locking）”，切换到锁界面，选择监控数据库，然后点击“更改配置（Change Configuration）”，开启“启用死锁警报（Enable deadlock alert）”。
在设置生效后，OPM 会监控所设置数据库，以及其应用程序中的锁信息，一旦有锁的问题就会写入数据库监控信息。首先从 OPM 警报（Alert）界面进行分析。
从这个界面我们可以看到所有被监控数据库的所有时间段所发生的死锁，包括锁得发生时间。选中其中一条记录，就可以看到所得更为详尽的信息，包括使用者，应用程序，IP 地址等。警报界面还提供了送邮件功能从“配置 (Configure)”按钮设置接受邮件地址，即可在相应邮箱及时地收到问题报告。在警报界面只给出了一个笼统的信息，要想详细分析锁信息还需要切换到锁界面。
通过点击图 7 中“锁定仪表盘（Locking Dashboard）”或者从“任务管理器（Task Manager）”—〉“正在运行的仪表板（Inflight Dashboards）”—〉“锁定（Locking）”进入锁界面。
从图 8，可以看到按分 2 大部分，一部分是数据库信息，一部分是锁信息。纵览可以看到死锁的总数量，锁事件，锁等待等信息。下面分别详述。
数据库信息部分按照用户信息 ID、应用程序名、主机名和应用程序类型来分类。每一类展开都会显示详细的项目信息。此处一目了然的可以看到 test1 用户在执行 product Viewing 这个操作的时候产生了 3 个死锁。同时也可以看到这是一个 WAS 的应用程序，执行在 IP 地址为 9.181.142.50 的客户端上。
图 10 列出了所有的锁事件，包括问题的严重程度，此处是 Problem 。
通过上面的数据库，应用程序整体信息，现在来详细分析死锁的问题。从图 10 中选中其中一条记录，通过点击“分析（Analyze … ）”按钮查看分析详细的死锁信息。
图 11 是死锁的一个概括信息，显示出了数据库版本信息，锁警告时间，应用程序 ID 等信息。
选择“显示 / 高亮不同（Show/highlight differences ）”、“语句（Statement ）”、“锁（Locks ）”、“应用（Application ）”、“表（Table ）”，图 12 中 OPM 在同一页面中以对比模式清晰地展示了不同的参与者的以下信息：
参与类型、应用程序、应用程序处理、客户端名称、锁名称、锁类型、SQL 语句操作，等等。
用户可以在这里看到锁是怎样产生的同时，也可以通过看到导致锁产生的语句。此页面主要信息包括：
- 按参与者分类的锁
- 被特别指出的中断参与者
- 死锁中包含的锁 .
- 死锁中被特别指出的中断锁
从此界面进一步分析，可以看到此死锁是由于两个“UPDATE ”语句互相等待造成的。
从图 14 可以看到所有导致或者涉及锁的 SQL 语句，选择任何一条都可以得到以下信息：
- 详细的 SQL 语句
- 参数标记值（如果有的话）
- 跟选择语句相关的锁详细信息
这里需要注意的是，如果历史语句是启用的，只有最后一条语句显示在这里。此处对于正在执行或者无限等待的语句，可以通过“停止当前语句（Stop Current Statement …）”去停止该语句的执行。也可以通过“调整（Tune） ”按钮开启 Optim Query Tuner (OQT) 对该语句进行分析调优，该功能后面将详细介绍。
图 15 详细地展示了锁名称，属性，模式，以及相关的表空间，表模式，表名，锁状态等信息。
应用程序在执行中发生连接等待、锁等待问题也会被 OPM 监控到，并且将主要信息展示出来。这些信息包括应用程序名称、应用程序标识、等待时间、客户机工作站名称、客户机应用程序名称等，如下图所示：
选中一条等待的连接纪录，点击“分析（Analyze …）”进行详细分析。
从图 17 可以看到等待的时间，以及相关的表空间，表名，锁类型，锁等待时间，SQL 语句，应用程序详细信息，同时还有所有活动的信息， 读取数据信息。如果想得到正在执行的 SQL 语句的详细地执行信息，可以通过点击“到活动 SQL 仪表盘（Go to the Active SQL Dashboard ）”进入到“活动 SQL ”界面，在这里可以看到 SQL 语句的开始，结束时间，CPU 消耗，读取行数，缓冲池命中率，排序时间等等。如图 18 所示：
系统运行中给定权限的用户，可以强行终止或者取消当前活动，对于给定了用户名和密码的用户通过图 14 和图 17 可以看到 OPM 提供了便捷的图形化工具。点击“强制终止应用程序（Force Application）”即可停掉执行无法结束的程序，等到下面的提示信息。
有些锁问题，是由于 SQL 语句执行时间过长造成，可以直接点击“停止当前语句 (Stop Current Statement)”取消正在执行的 SQL，同时需要分析、优化 SQL 语句以提高 SQL 的执行性能，OPM 与 Optim Query Tuner( 本文简称 OQT) 产品也作了集成，所以对于需要定位、分析、调优 SQL 语句问题，通过选定 OPM 相应的界面“Tune”按钮（本文中涉及到的有图 14，图 17 和图 18），即可切换到 OQT。注意：如果想 OPM 顺利的切换到 OQT 需要做两点：（1）将 OQT 打开 （2）启动数据桥接服务器。
从 OPM 切换到 OQT，OQT 会自动写入 OPM 监控数据库的监控信息，提示输入登陆信息，如下图所示：
登录数据库以后，从 OPM 选择的 SQL 语句会自动的加载到 OQT 的 Query Text，如图 21 所示，点击”选择调整活动 (Choose Tuning Activities)” ，“调整查询 (Tune Query) ”或者“生成报告摘要 (Generate Summary Report) ”选择想跳的优化选项。具体 OQT 操作可参考：有效使用 Optim Query Tuner 工具进行 SQL 查询语句的优化 一文。
数据库使用管理中，经常会发生死锁，程序不响应，运行速度慢等问题。通过本文可以看到 OPM 会就这些问题生成一份完整地分析报告，帮助用户及时、有效、准确地解决以下问题：
- 准确定位出出现死锁的 DB2 应用程序
- 找到哪些应用程序允许处理
- 得到足够的信息告诉决定如何避免死锁
- 得到 DB2 Event Monitor 的所有重要信息
作为一款优秀的数据库监控工具，OPM 监控数据库的各种信息，提供多分区监控检测分区间问题和分区比较从而得找到系统级的问题，针对数据库突发状况迅速做出反应，简化数据库管理，精确地调试和有效地优化数据库性能。数据库监控是一个非常复杂的过程，本文仅从锁的角度使用了 OPM，OPM 还有很多更强大的功能，比如监控 I/O，监控端到端的应用程序以及 SQL 语句执行情况等等。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/15082138/viewspace-671081/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/15082138/viewspace-671081/
183
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
