AWR一例，请大家帮忙分析一下！

chinadm123

下面是我拙劣的分析，请大家帮忙看一下，有不妥的地方烦请大家指出。被兄弟们笑比被客户笑强^_^

一、数据库总体业务量

        Snap Id        Snap Time        Sessions        Cursors/Session
Begin Snap:        42174        24-Jun-13 09:01:08        78        6.7
End Snap:        42175        24-Jun-13 10:01:23        90        7.6
Elapsed:                 60.25 (mins)                  
DB Time:                 536.38 (mins)                  
从上表中看出，在1个小时的抽样中，平均每个 session打开cursor的数量为7，说明数据库并发度并不高。数据库消耗的总时间为536.38 (mins), 536.38 (mins)/ 60.25 (mins)=9，说明在抽样的时间段内数据库对系统资源消耗比较多，算是一个中等负载的数据库。

二、Top 5 Timed Events

Event        Waits        Time(s)        Avg Wait(ms)        % Total Call Time        Wait Class
enq: JI - contention        6,182        15,094        2,442        46.9        Other
log file sync        7,026        6,408        912        19.9        Commit
log buffer space        5,143        4,806        935        14.9        Configuration
log file parallel write        647        2,902        4,485        9.0        System I/O
rdbms ipc reply        1,551        2,552        1,646        7.9        Other

由上表可以看出，数据库enq: JI – contention事件平均等待时间达2.442ms,属于比较严重的等待,此等待是需要materialized view operations释放lock，可能是由于materialized view operations操作过于频繁所致。
log file sync， log file parallel write等待事件均与redo log相关，主要是IO写性能不足。
log buffer space 可能与lob buffer 太小导致，但从下面数据可以看出log buffer 14M,应该不小，很有可能仍与log file write性能差相关。
Log Buffer:        14,408K


三、Oracle Buffer使用率

Buffer Nowait %:        99.96        Redo NoWait %:        99.99
Buffer Hit %:        85.25        In-memory Sort %:        100.00
Library Hit %:        90.38        Soft Parse %:        70.73
Execute to Parse %:        72.28        Latch Hit %:        99.98
Parse CPU to Parse Elapsd %:        38.13        % Non-Parse CPU:        98.23
从上表可以看出，Buffer Hit %及Library Hit %较低，需要适当增加SGA及shared pool 大小。

四、数据库redo I/O

        Per Second        Per Transaction
Redo size:        260,761.72        1,112,905.46

Statistic        Total        per Second        per Trans
redo size        942,630,924        260,761.72        1,112,905.46
user commits        841        0.23        0.99

Statistic        Total        per Hour
log switches (derived)        5        4.98


从上面可以看出，redo 每秒产生260,761.72bytes,在一个小时内产生942,630,924bytes redo，发生5次日志切换，说明数据库产生的redo并不多.但从Top 5 Timed Events中分析得到log sync/write 性能并不佳，再次证明redo log file所在的磁盘性能较差。


五、解析与硬解析

        Per Second        Per Transaction
Parses:        5.43        23.18
Hard parses:        1.59        6.79


Statistic Name        Time (s)        % of DB Time
parse time elapsed        54.09        0.17
hard parse elapsed time        45.75        0.14

有一定比例的硬解析，但解析所占用的时间，% of DB Time并不高，不足以明显影响性能。


六、有问题的SQL

Elapsed Time (s)        CPU Time (s)        Executions         Elap per Exec (s)         % Total DB Time        SQL Id        SQL Module        SQL Text
19,376        231        2        9688.10        60.21        36vuvyy7vj8s6
          BEGIN PKG_VCC.PRC_MATERIAZEDVI...
1,693        205        2        846.53        5.26        8jxcfdffptvwu
          /* MV_REFRESH (DEL) */ delete ...
SQL ID 为36vuvyy7vj8s6和8jxcfdffptvwu的两个语句占% Total DB Time的65.5%，
迫切需要优化。

下面是这两个SQL的内容：
SQL Id        SQL Text
36vuvyy7vj8s6        BEGIN PKG_VCC.PRC_MATERIAZEDVIEWFRESH(:1, :2); END;
8jxcfdffptvwu        /* MV_REFRESH (DEL) */ delete from "FNMS_KS"."EBB41"


总结：
1，redo log IO性能问题重点关注。
2，materialized view operations需要重点关注。
3，占用CPU过多SQL需要优化。
4，Buffer Hit，Library Hit命中率不足，需要增大SGA。

Ling.QIu

发点差异看看 用zip压缩 谢谢

stevendba

看Tablespace IO Stats，File IO Stats 磁盘速度较差41.57  15.33，redo也生成的非常多，Redo size:30,412.54，平均每秒14M,系统在做什么？

chinadm123

stevendba 发表于 2013-7-3 10:10
看Tablespace IO Stats，File IO Stats 磁盘速度较差41.57  15.33，redo也生成的非常多，Redo size:30,412. ...

Tablespace IO Stats，File IO Stats 磁盘速度较差  这里判断好坏有没有一个稍微量化的范围？
redo 不多吧，我看到每秒不到1M。您是在哪里看到的?

stevendba

你的系统现在是不是很慢，看一下等待事件log file sync，这个事件平均等待超过20ms就说明磁盘的速度很差。我以前碰到过类似的问题。
http://blog.csdn.net/guogang83/article/details/8791622

Hank-D

物化视图的刷新频率过高，查看物化视图定义是不是 on commit。 可调整为按时间刷新。因为每次commit 的时候刷新，所以parallel write 和 sync 都显高，并且伴随 buffer busy（commit慢，释放锁也就慢，所以就抢）.  处理物化视图后，应该会缓解很多。请处理完 再发一封AWR上来