ITPub博客

首页 > 数据库 > Oracle > 2010年8月的一次调优

2010年8月的一次调优

原创 Oracle 作者:oracle_mao 时间:2014-01-17 08:58:32 1 删除 编辑
翻出2010年刚工作的时候的笔记,感觉那时候解决问题的思路好笨拙。以下所遇问题和解决思路。  
2010年8月:
坐下来将最近一个月的调优问题一步步的记下来,虽然最终问题解决了,但是解决的方法真的是很简单,但是调优的过程还是比较令人回味的!里面有我的日日夜夜,几天几夜都没有睡好。哎!!! 
  从11月20日发现问题,最开始是上海的ridb模块先入库,具体就是ridb模块会将GRO文件处理并将文件内容入report库。这个文件一般都3.4M,由于数据库在以前部署的时候很多参数都是默认的,当然redo日志的大小也是默认的50M,问题产生的时候大家都不知道ridb入库很慢,因为在测试机上测试的时候是很快的(测试机的数据很少,表也很小,几乎是空表。),在模块入库时不断的发生针对一张分区表做insert和update操作,update的sql语句的where msg_id=v_msg_id其中msg_id是哦varchar类型,并且是索引列
病状:1.入库很慢,因为可以看到22万行的语句要处理30分钟,最终导致入库延迟
      2.日志文件切换很频繁,2s就切换一个50M的日志文件。
      3.产生太多的归档文件,将空间占满


解决顺序:
1. 将report改为非归档。
a) 这样解决了空间被疯狂占满的问题
2. 将日志文件增大到500M
a) 切换为30s切换一次。
3. 根据update的执行计划发现update没有走索引,将where条件改为
where msg_id=to_char(v_msg_id) 
a) 速度快了点,仿佛日志切换更频繁了,大概25s就切换一次redo日志
4. 将update语句的表后面加了指定分区
a) 入库快了许多,日志切换好多了,大概4分钟切换一次。
5. 由于从开始到最后,开发人员认定update只是改了一条语句,所以从没怀疑过他的话,直到12月17号,突然发现每次update更改了不仅仅是一条记录,而是5条以上。
a) 将where后面加限制条件。
b) 速度迅速提升。日志切换大概为2小时切换一次!
c) 问题解决!


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

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

注册时间:2011-03-28

  • 博文量
    94
  • 访问量
    753980