数据库性能优化-熟悉AWR的高手帮忙看看:
目前存在的问题:
单用户顺序请求时平均耗时在2秒以内;100个用户并发执行时耗时在10秒左右;
经过分析,时间的开销都在执行sql语句上了,并发以后每个sql语句的执行时间放大了10陪左右。AWR文件位置:
http://webmail.mail.yeah.net/app/wp/doGetFile.jsp?sid=EAkzhSCCoohbTbgEBYCCYJoGdoQcgXpZ&mode=download&mid=8:1tbiCAROBkoc9A-H3wABsw

解决方案 »

  1.   

    AWR文件位置:
    http://blog.163.com/guohai_shan@yeah/blog/static/120977411201152852946226/上面的打不开。
      

  2.   


    半个小时的AWR:1. 硬解析有点多
    User calls: 32.86 25.49 
    Parses: 12.31 9.55 2. Top  event
    log file sync 11,973 75.29 9,871 824 5.90 
    log file parallel write 1,558 0.00 1,391 893 0.77 
    db file parallel write 6,111 0.00 1,120 183 3.01 
    db file sequential read 14,046 0.00 753 54 6.92 
    log buffer space 681 73.42 588 864 0.34 
    buffer busy waits 323 71.52 255 790 0.16 
    log file switch (checkpoint incomplete) 649 20.34 199 306 0.32 
    log file switch completion 224 56.70 154 688 0.11 
    control file parallel write 1,086 0.00 65 60 0.54 
    db file scattered read 1,099 0.00 38 35 0.54 
    写log 频繁,减少commit, 存在checkpoint incomplete, redo log group 不够用,需要新增加group。检查下相关SQL,是否有全表扫描和热快。
    11,001,490 0 
     86.56 133.96 1546.77 8wg10y5j99xwy PBoxRateBatchSvr@pingantest (TNS V1-V3)  delete from PBOX_RATETMP where... 8wg10y5j99xwy delete from PBOX_RATETMP where to_char(UPDATEDTIME, 'hh24:mi:ss') < '09:00:00' or to_char(UPDATEDTIME, 'hh24:mi:ss') > '18:15:00' 
    3. PGA 有点小,建议改到300M4.  设计如下2张Table 的业务需要检查一下,能够减少commit和select。 不能减少的话,看能否对表的数据进行转历史,减小表中记录的数量。 还有相关的索引。
    PBOX_RATETMP 和 IDMAPPING 5. cursor reload 太多
    Namespace Get Requests Pct Miss Pin Requests Pct Miss Reloads Invali- dations 
    BODY 274 0.00 5,695 0.23 13 0 
    CLUSTER 62 0.00 129 1.55 2 0 
    INDEX 39 0.00 95 9.47 9 0 
    SQL AREA 3,369 91.27 64,818 10.50 618 0 
    TABLE/PROCEDURE 938 0.00 44,780 1.16 308 0 
    TRIGGER 4 0.00 4 100.00 4 0 这个和前面提到的硬解析过多有关,检查下相关SQL,能否使用绑定变量。
      

  3.   

    你物理内存多少? 把PGA修改为400或更好的600M, 然后你再看看100用户时查询时间如何?
      

  4.   

    先改改“把PGA修改为400或更好的600M”测试下看看效果了。
                                                                                                             Oracle太深奥了。