案例分析总结连载：第九章

最新推荐文章于 2019-12-01 12:41:10 发布

csdnw1018

最新推荐文章于 2019-12-01 12:41:10 发布

阅读量116

点赞数

文章标签：数据库运维

案例分析总结

第8章结尾我们看到，优化小组艰难地完成了大规模SQL优化的任务。期间，我被告知系统发生了严重的死锁。下面记录了如何诊断出锁的问题及解锁的思路和方法。

2010年7月26日笔记整理地点：成都

在性能优化期间，我得知系统发生了严重的死锁。现场人员收集了大量日志，却一直无法定位问题点。建议使用db2support收集问题发生时段的数据库日志，却被拒绝了，理由是——几十个分公司的业务掺杂在一起，很难定位问题。

我不得不掰出手指头，告诉他们我在浙江、上海遇到过类似问题，用的都是这种方法。摆阅历有时很奏效，运维人员很快送来了db2support命令收集到的信息。我们首先打开db2diag.log，通过查看时间戳确认了是原始的诊断日志，接着搜索关键字“Lock”，发现日志中有大量的“Lock Wait”和“Lock Timeouts”字样出现。

那些天系统非常慢，5楼的DBA诊断后一直围着死锁转，解决不了问题。现在就可以把问题范围收缩到锁等待和锁超时上。又经过核实，最后得出一致结论：是锁等待导致系统变慢。

接着要制订针对锁等待的优化方案。其中当务之急是找出造成锁等待的所有SQL语句。这需要PAT方法学的第一步：问题监控。首先打开数据库锁监控开关，接着使用DB2表函数SNAPSHOT_LOCKWAIT编写一个每隔10秒钟运行一次的监控SQL脚本，这个脚本会按照时间先后顺序排列出所有造成锁等待的SQL语句。完成问题定位后，开始执行PAT第二步：配置检查。发现参数LOCKTIMEOUT的设置是10s。随后，执行PAT第三步，设计检查。就第一步中检测到的SQL语句进行设计层面的分析。发现有的SQL语句效率低下，有的SQL语句没有创建合理的索引。我们对这些情况都做了详细记录，为下一步优化环节做准备。完成了设计检查，开始PAT第四步：性能优化。由于银行信贷系统是事务和分析类混合工作负载，LOCKTIMEOUT目前为10s，这个值稍偏小一些，在性能优化方案中，我们建议DBA将其调整为20s 。针对引起锁等待的SQL语句，在方案中我们建议采用手工和Design Advisor两种方式。对效率低下的SQL语句使用手工调整，对没有建立合理索引的SQL语句使用Design Advisor工具方式。