ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 案例分析总结连载:第九章

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

原创 Linux操作系统 作者:db2ring 时间:2011-09-06 09:16:47 0 删除 编辑

案例分析总结

 

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

2010726   笔记整理                         地点:成都

在性能优化期间,我得知系统发生了严重的死锁。现场人员收集了大量日志,却一直无法定位问题点。建议使用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工具方式。

这个“手术”效果不错。可以看到,当推测由于锁问题导致性能降低时,不要想当然地就认为是死锁导致的。我们可以通过一些工具和日志分析来确认真正的问题所在。当然,可以使用“PAT方法”有思路、有步骤地去解开谜团。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/24801454/viewspace-706716/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-04-26

  • 博文量
    21
  • 访问量
    13706