ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 利用ASm分析性能分析一例

利用ASm分析性能分析一例

原创 Linux操作系统 作者:onlinedog 时间:2009-06-08 12:42:58 0 删除 编辑
上周五测试组机器特别慢,几乎瘫痪。分析了分析ASH报告,定位原因是由于这条sql造成的:
 
MERGE INTO AC03 USING AC03_TEMP ON (AC03.AAC001 = AC03_TEMP.AAC001 AND AC03.AAB001 = AC03_TEMP.AAB001 AND AC03.AAE002 = AC03_TEMP.AAE002) WHEN MATCHED THEN UPDATE SET AC03.AAE060=AC03_TEMP.AAE060, AC03.AAC003=AC03_TEMP.AAC003, AC03.AAC040=AC03_TEMP.AAC040, AC03.AIC020=AC03_TEMP.AIC020, AC03.AKC010=AC03_TEMP.AKC010, AC03.AJC020=AC03_TEMP.AJC020, AC03.ALC001=AC03_TEMP.ALC001, AC03.AMC001=AC03_TEMP.AMC001, AC03.AIC010=AC03_TEMP.AIC010, AC03.AKC001=AC03_TEMP.AKC001, AC03.AJC010=AC03_TEMP.AJC010, AC03.AAE101=AC03_TEMP.AAE101 WHEN NOT MATCHED THEN INSERT VALUES ( AC03_TEMP.AAB001, AC03_TEMP.AAE002, AC03_TEMP.AAC001, AC03_TEMP.AAE060, AC03_TEMP.AAC003, AC03_TEMP.AAC040, AC03_TEMP.AIC020, AC03_TEMP.AKC010, AC03_TEMP.AJC020, AC03_TEMP.ALC001, AC03_TEMP.AMC001, AC03_TEMP.AIC010, AC03_TEMP.AKC001, AC03_TEMP.AJC010, AC03_TEMP.AAE101 )
     
问题分析过程如下:
     
1. 查看top等待事件。
 
 
注意几个重要的等待时间都出现了,说明数据库存在严重的问题。
 
db file sequential read :说明存在大量索引的访问。
db file scattered read : 说明存在大量全表扫描。
log file sync :说明日志同步频繁。当数据缓存的脏数据写入数据文件时,日志必须同步完成。
                    如果日志更新频繁(大量commit,roll back操作),就会造成此等待事件。
tx :事务锁,行级锁。进行dml操作是,需要对表先加tm锁,再加事物锁,加锁的同时,别的事务需要等待。
log file parallel write:缓存大量写入数据文件,启动并行写。
 
 
2. 查看top sql语句
 
 
从上面可以看出,第1,3,4,5语句的执行等待事件是wait for cpu(当然第1个语句还存在大量的索引扫描),
wait for cpu主要是等待获得cpu资源,可忽略。最终定为问题sql是第2个sql语句。
 
3. 查看top db objects
 
大量的等待都花销在ac03表上面。
 
4. 最终和张勇沟通此sql,问题得以清晰。
 
 ac03_temp表,临时表。
 ac03表,正常表。
 通过merge语句,将临时表的数据更新到ac03表里去。
 
 正常情况下是没有问题的,测试组为了某项操作,将ac03_temp变为正常表,并插入了2w多条数据。 问题就出现了:

 再执行merge操作时,由于数据量的变化,导致oracle的执行计划发生变化,变成了全表扫描访问ac03,ac03_temp。
  
 这样就造成了大量的全表扫描读等待事件,由于是更新操作,也造成了大量的锁等待事件,这是数据库瘫痪的直接原因。
 
 
 总结:数据库出现性能问题一般都是由某一个原因造成的,由于连锁反应,才造成了数据库出现问题,快速定位原因才能从根本上解决问题。

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

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

注册时间:2008-09-16

  • 博文量
    106
  • 访问量
    203415