处理速度慢，各位诊断。附awr报告

yobyin

目前这个主机上呢，跑了两个实例，所以sga_max_size 基本到了最大。此系统是一个olap的数据库
最近运行比较慢。
我初步诊断了一下，buffer_cache 有点小，logic reads 太高达到每秒70w blocks .

请各位高手，再瞧一下我分析的对不对

[ 本帖最后由 yobyin 于 2012-5-22 10:15 编辑 ]

ruideliang

看看，结果分不够！晕

yobyin

改了，改了，for free 的

ruideliang

从awr报告看，buffer cache不需调整，主要逻辑读集中在merge的几个语句上，olap亦意味大数据量的读，Buffer Hit %:99.97很不错了

Maclean Liu(刘相兵

Linux x86 64-bit  +         11.1.0.7.0  RAC=NO


Logical reads:        526,850.6        732,606.6          每秒逻辑读 4116 MB

Host CPU (CPUs: 16 Cores: 16 Sockets: 4)           16core

Event        Waits        Time(s)        Avg wait (ms)        % DB time        Wait Class
DB CPU                 44,665                 89.28         
db file sequential read        4,113,358        5,156        1        10.31        User I/O

TOP 5中 DB CPU 占了大头


CPU Time (s)        Elapsed Time (s)        Executions         CPU per Exec (s)        % Total        % Total DB Time        SQL Id        SQL Module        SQL Text
5,848        5,932        2        2924.04        11.45        11.31        4w3hv8m3t8n4x         JDBC Thin Client         merge into INDICATOR_20398_1 t...
5,842        5,927        2        2921.07        11.43        11.30        a2zkkyuwt6p5v         JDBC Thin Client         merge into INDICATOR_20404_1 t...
5,576        5,658        2        2788.16        10.91        10.79        27wq448z9ndrg         JDBC Thin Client         merge into INDICATOR_20424_1 t...
5,567        5,646        2        2783.34        10.90        10.76        77bp0shay1kaj         JDBC Thin Client         merge into INDICATOR_20417_1 t...
5,479        5,592        2        2739.57        10.72        10.66        fk7x594y5w5vj         JDBC Thin Client         merge into INDICATOR_20394_1 t...
4,897        5,177        1        4896.69        9.58        9.87        d0cjz4k9v95m3         JDBC Thin Client         merge into INDICATOR_20408_1 t...
1,582        1,583        120        13.18        3.10        3.02        dn07zhxsf7wbm         JDBC Thin Client         select indicatorid, sourcemot...


Buffer Gets         Executions         Gets per Exec         %Total        CPU Time (s)        Elapsed Time (s)        SQL Id        SQL Module        SQL Text
429,466,232        2        214,733,116.00        11.40        5848.08        5932.42        4w3hv8m3t8n4x         JDBC Thin Client         merge into INDICATOR_20398_1 t...
429,464,270        2        214,732,135.00        11.40        5842.15        5926.98        a2zkkyuwt6p5v         JDBC Thin Client         merge into INDICATOR_20404_1 t...
412,473,134        2        206,236,567.00        10.95        5576.31        5657.84        27wq448z9ndrg         JDBC Thin Client         merge into INDICATOR_20424_1 t...
412,203,228        2        206,101,614.00        10.94        5566.67        5645.51        77bp0shay1kaj         JDBC Thin Client         merge into INDICATOR_20417_1 t...
401,970,344        2        200,985,172.00        10.67        5479.14        5592.45        fk7x594y5w5vj         JDBC Thin Client         merge into INDICATOR_20394_1 t...
349,568,508        1        349,568,508.00        9.28        4896.69        5176.81        d0cjz4k9v95m3         JDBC Thin Client         merge into INDICATOR_20408_1 t...



消耗 大量 buffer gets的语句 对应于 消耗大量cpu time的语句，  都是只 执行2次的 merge select *  语句 ，这些语句 耗费大量的逻辑读 单次达到214,733,116 ，   建议你考虑调优SQL 减少逻辑读 。


或者你希望通过增加cpu负载来加速merge的话  ， 考虑使用并行查询。

yobyin

谢谢各位点评， 谢谢。

不了峰

非常不可理解的 Parse CPU to Parse Elapsd %: 0.01.  这个指标.


(说明 在解析时,遇上了大量的等待) ,但是纵观整个业务的执行sql语句的次数不算多.(这个描述可能不准确)唯一多的是 96g93hntrzjtr,db78fxqxwxt7r 分别查询的是 hist_head$  ,histgrm$ 表
--难道柱状图信息非常 多?

楼主能描述一下  处理速度慢  这个是哪里慢,查询慢,或是insert慢.
是olap系统?

是不是表的字段非常 多?  表的统计信息是如何收集的?

majuthink

DB Name DB Id Instance Inst num Startup Time Release RAC
MOSC03 3891756183 MOSC03 1 04-May-12 02:05 11.1.0.7.0 NO

Per Second Per Transaction Per Exec Per Call
DB Time(s): 7.0 2.2 0.05 0.04
DB CPU(s): 6.2 2.0 0.04 0.04
Redo size: 1,918,042.7 607,398.2     

Execute to Parse %: 44.23

Statistic Name Time (s) % of DB Time
sql execute elapsed time 49,116.36 98.18
DB CPU 44,664.60 89.28

Wait Class Waits %Time -outs Total Wait Time (s) Avg wait (ms) %DB time
DB CPU     44,665   89.28
User I/O 4,175,984 0 5,369 1 10.73

Event Waits %Time -outs Total Wait Time (s) Avg wait (ms) Waits /txn % DB time
db file sequential read 4,113,358 0 5,156 1 181.99 10.31
根据以上的数据库CPU使用情况重点查看占用CPU比例较高的SQL
Foreground Wait Events中db file sequential read 排第一战用% DB time=10.31找到相应的SQL
SQL ordered by CPU Time
1,300 1,356 3 433.27 2.91 2.71 dm6hs2as9vkba JDBC Thin Client  merge into BH_24096 tt using (...

可以对该SQL进行执行计划分析，对SQL进行优化找出最优执行计划来减少逻辑读，减少cpu time的消耗。

或者如坛主所说：或者你希望通过增加cpu负载来加速merge的话  ， 考虑使用并行查询。

[ 本帖最后由 majuthink 于 2012-5-22 16:28 编辑 ]

yobyin

谢谢，谢谢。大家辛苦

wanglixue2012

看不到AWR报告，晕倒！！！

yobyin

通过开启 适当并行来提高执行速度