一次数据库性能问题的调试（转）
一次数据库性能问题的调试,性能调试,性能调优
基本情况：
系统是一个基于web的业务系统，以online查询为主，数据更新以批量为主，晚上执行。应该说系统还不算负载太大。5-1之后上班的时候客户反映很慢，察看DB的cpu慢慢长到100%状态。服务基本处于不可用状态。i/o wait也挺高的。
经检查，前些天的批量竟然有达到20多小时才完成，导致次日批量都跑不起来。
打开statspack收集信息
从系统中发现本应该夜间执行的批量作业还在运行。停掉后，rollback做了4个小时?a href="http://www.learners.cn" target="_blank">。ㄒ蛭?桓鰐ransaction中只有一个复杂的、数据量巨大的insert语句）
然后做statspack分析，
系统中存在问题：等待事件较严重，缓存命中率较低，
语句分析：
1、一些大量执行update/delete语句竟然没有建立索引，其实可以建立pk，根据pk处理。
where中使用常量（引起parse）
2、存在大量这样的语句：
SELECT fieldx FROM Tablesname where trim（ServiceNUM） = 'DDDDDD' - 在ServiceNUM字段上是唯一索引，因为trim就不能使用index（败笔） ——改！
- 使用常量查询，造成每次查询都要parse，没有必要的占用的CPU —— 改！
3、在批量的存储过程中，
所有语句基本都是全表扫描！ —— 和开发人员沟通，需要修改逻辑。改进之后效果还是蛮大的。
另外发现一个问题：
客户需要的是n百万用户数据中的活动用户万数据，他们却全部把n百万数据从其他系统中收集到自己的系统中，在批量的时候又使用full table scan，性能自然不会好。系统从刚开始设计的时候就存在隐患。这个问题就需要从长计议了。
修改后，CPU高峰时间基本稳定在30-40%之间。
批量基本在2个小时内完成。
其实是一个很简单的系统，但是做到这种样子，尤其是从设计到编码都存在问题。
基本情况：
系统是一个基于web的业务系统，以online查询为主，数据更新以批量为主，晚上执行。应该说系统还不算负载太大。5-1之后上班的时候客户反映很慢，察看DB的cpu慢慢长到100%状态。服务基本处于不可用状态。i/o wait也挺高的。
经检查，前些天的批量竟然有达到20多小时才完成，导致次日批量都跑不起来。
打开statspack收集信息
从系统中发现本应该夜间执行的批量作业还在运行。停掉后，rollback做了4个小时?a href="http://www.learners.cn" target="_blank">。ㄒ蛭?桓鰐ransaction中只有一个复杂的、数据量巨大的insert语句）
然后做statspack分析，
系统中存在问题：等待事件较严重，缓存命中率较低，
语句分析：
1、一些大量执行update/delete语句竟然没有建立索引，其实可以建立pk，根据pk处理。
where中使用常量（引起parse）
2、存在大量这样的语句：
SELECT fieldx FROM Tablesname where trim（ServiceNUM） = 'DDDDDD' - 在ServiceNUM字段上是唯一索引，因为trim就不能使用index（败笔） ——改！
- 使用常量查询，造成每次查询都要parse，没有必要的占用的CPU —— 改！
3、在批量的存储过程中，
所有语句基本都是全表扫描！ —— 和开发人员沟通，需要修改逻辑。改进之后效果还是蛮大的。
另外发现一个问题：
客户需要的是n百万用户数据中的活动用户万数据，他们却全部把n百万数据从其他系统中收集到自己的系统中，在批量的时候又使用full table scan，性能自然不会好。系统从刚开始设计的时候就存在隐患。这个问题就需要从长计议了。
修改后，CPU高峰时间基本稳定在30-40%之间。
批量基本在2个小时内完成。
其实是一个很简单的系统，但是做到这种样子，尤其是从设计到编码都存在问题。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/10294527/viewspace-122151/ ，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
