您的位置:首页技术文章
文章详情页

[Oracle]一次数据库性能问题的tuning

【字号: 日期:2023-11-22 08:53:17浏览:80作者:猪猪
基本情况: 系统是一个基于web的业务系统,以online查询为主,数据更新以批量为主,晚上执行。应该说系统还不算负载太大。5-1之后上班的时候客户反映很慢,察看DB的cpu慢慢长到100%状态。服务基本处于不可用状态。i/o wait也挺高的。 经检查,前些天的批量竟然有达到20多小时才完成,导致次日批量都跑不起来。 打开statspack收集信息 从系统中发现本应该夜间执行的批量作业还在运行。停掉后,rollback做了4个小时!(因为一个transaction中只有一个复杂的、数据量巨大的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个小时内完成。 其实是一个很简单的系统,但是做到这种样子,尤其是从设计到编码都存在问题。呵呵,说真的,不是在优化语句的,而是从头开始看设计。
标签: Oracle 数据库