DB2 Performance Expert 简化性能管理和调优 2(5)

出处:51CTO.com整理　 

 

方法
在 System Overview 面板中选择 Applications in Lock Conflicts，显示锁冲突所设计的所有应用程序，当您选择 Locking Conflicts时，这些应用程序都与一个特殊的资源相关联。

Application in Lock Conflicts 面板显示了 holder 和 waiter 应用程序，其中包括应用程序的状态、锁的模式、锁等待时间等。

Application Details 视图中的 SQL Statement and Package 展示了加锁的应用程序的 SQL 语句。

Application Details 视图中的 Locks 显示了详细的加锁信息，例如应用程序所持有的锁、检测到的死锁、锁升级、等待锁的代理等。

Application Details 视图中的 Identifcation 显示了有关正在运行该应用程序的用户的详细信息。

应用程序所持有的锁：
这个数字说明当前的应用程序持有多少个锁。

如果监视信息是在数据库级上进行的，那么该值就是数据库中所有应用程序所持有的锁的总数。如果监视信息是应用程序级的，那么该值就是这个应用程序的所有代理目前持有的锁的总数。

从连接以来等待的锁：
这个数字是应用程序或连接已经等待锁的次数。

在数据库级上，该值是应用程序在这个数据库上等待锁的次数。而在应用程序连接级上，该值是在某个连接请求一个锁但由于另外一个连接正持有该数据的锁而必须等待的次数。可以使用该元素计算在数据库级上等待一个锁的平均等待时间。这种计算可以在数据库级或应用程序连接级上进行。如果锁的平均等待时间很长，那么您应该查看一下持有很多锁的应用程序；或者如果是这种情况导致等待时间过长，就对该锁进行升级，从而重点对应用程序进行调优，以改进并发性。如果升级是导致锁平均等待时间很长的原因，那么可能是 locklist 或 maxlocks 这两个配置参数值中的一个太小了，也可能这两个参数值都太小了。

锁升级
这个数字说明了某个锁作为锁升级的一部分被升级的次数。升级的范围可以从（一个表中的）许多行锁到单独某个表锁。

可以使用这个元素更好地理解死锁的原因。如果您曾经碰到过有关应用程序执行锁升级而导致死锁的情况，那么就可能希望增加锁内存的数量（locklist）或修改一个应用程序可以请求某个锁的百分比（maxlocks）。

检测到的死锁
该值是已经出现死锁的总数。

可以用该元素来判断应用程序正出现争用问题。这些问题可能是由于以下情形引起的：

• 数据库中正在进行锁升级。
• 应用程序可能在系统生成足够多的行锁时显式地对表进行锁定。
• 应用程序可能在绑定时使用了不恰当的隔离级别。
• 为了可以重复读而锁定目录表。
• 应用程序正在对不同的订单使用相同的锁，从而导致死锁。

您可以通过判断死锁是在哪个应用程序（或应用程序进程）上产生的来解决问题。然后可以修改应用程序，使其能够更好地并行执行。然而，有些应用程序可能不能并行运行。您可以使用连接的时间戳监视元素，判断死锁的严重性。例如，在 5 分钟之内出现 10 次死锁就比在 5 小时内出现 10 次死锁严重得多。对上面列出的这些相关元素的描述还提供了其他一些调优建议。

等待锁的代理：
该值说明了等待某个锁的代理个数。

这个元素是应用程序等待某些锁的百分比的一个指示器。如果这个数字很大，那么您的应用程序可能存在并行问题，您应该对现在持有锁或者长期持有互斥锁的应用程序进行分析。

结论:
检查 waiter 和 holder 应用程序的 SQL 语句，确定诸如应用程序中频繁进行提交操作而导致释放锁或检查应用程序使用的隔离级别之类的操作。当执行很多更新时，在更新之前，要在整个事务的持续时间内锁定整个表。虽然这样可以只使用一个锁，同时还可以防止其他锁妨碍更新操作，但是这样做会减少数据对于其他用户的并发能力。

经常使用 cache 包中的 SQL 语句进行检查

DB2 PE 步骤

1. 在 System Overview 面板中选择 Statistic Details。
2. 在 Statistic Details 视图中选择 Dynamic SQL Statements。

   图 17. Dynamic SQL Statements
   

3. 下拉滚动条，查看语句的详细资料。
   

   图 18. 语句的详细资料
   

方法
Statistic Details 中的 Dynamic SQL Statements 视图给出了有关 SQL 语句的详细信息，其中包括访问的数据库、执行次数、已经过去的执行时间、最差和最佳的准备时间、排序，以及在选中 Receive statement cache information时每条语句占用的 CPU 时间等。

通过点击如 图 17所示的标题中的 Executions列，可以按照执行次数对 SQL 语句进行降序排列，这样就可以看到执行最频繁的 SQL 语句。

执行次数
该值是一条 SQL 语句已经被执行的次数。您可以使用该元素来判断系统中执行最频繁的 SQL 语句。

每条语句占用的 CPU 时间
这个数字说明了一条 SQL 语句占用的所有 CPU 时间。可以将该元素与“已经过去的执行时间”和“每条用户语句占用的 CPU 时间”一起使用，来评价语句的最大花费。

最佳准备时间：
该值是准备一条特定的 SQL 语句所需要的最短时间。可以用该值来判断编译耗时的 SQL 语句。

最差准备时间：
该值是准备一条特定的 SQL 语句所需要的最长时间。可以用该值来判断编译耗时的 SQL 语句。

结论
这个执行监视元素可以您帮助判断系统中执行最频繁的 SQL 语句。在本例中，某个查询运行了 500 次，并且进行了 500 次排序。这是进行查询优化的很好的一个选择，可以检查排序值，并验证是否需要创建新的索引。