Oracle db 11.2.0.1 on windows 2008 R2 performance

orafans

OS :windows 2008 server R2 x64 with 2cpu(16cores,32GB ram,single 1GB network card,without shared storage)
DB :Oracle 11.2.0.1 x64
APP:web(windows)+JBOSS(windows)

symptom:

应用跑struts+jboss中间件，前端3台服务器负载均衡，后端DB单机.数据库的session一般保持在300以下.

在web页面做动态页面时，1GB 的速率可达到80%-90%，CPU利用率时常跑到100%，DB就HANG住。
在web页面做静态页面时，1GB 的速率则达到30%以下，CPU利用率比较低，DB正常，但是客户端反映不太好。

之前数据库服务器和web 应用服务器都有查出了木马类似程序。后来DB数据库完全重新安装。

开发人员说应用中的所有的SQL 语句以及生成的视图等是相关工具自动生成。

情况描述不清请跟贴。
附件有AWR，请大侠们看看DB的状况。

[ 本帖最后由 orafans 于 2012-3-20 12:45 编辑 ]

Maclean Liu(刘相兵

Elapsed:                 60.24 (mins)                  
DB Time:                 388.04 (mins)                  

AAS> 6 高DB负载

Logical reads:        178,731.8        32,161.8                  
Block changes:        59.1        10.6                  
Physical reads:        2,973.3        535.0                  
Physical writes:        12.8        2.3         


每秒逻辑读  =  178731 * 8k= 1396MB  逻辑读多

Top 5 Timed Foreground Events

Event        Waits        Time(s)        Avg wait (ms)        % DB time        Wait Class
DB CPU                 17,507                 75.19         
SQL*Net more data to client        43,392,220        2,338        0        10.04        Network
direct path read        2,043,850        245        0        1.05        User I/O


产生大量逻辑读的语句包括：
Buffer Gets         Executions        Gets per Exec         %Total        Elapsed Time (s)        %CPU        %IO        SQL Id        SQL Module        SQL Text
27,126,217        5,485        4,945.53        4.20        3,238.88        65.75        0.01        6dnhd625c5gz5         JDBC Thin Client         select servantapp0_.id as id49...
23,574,375        4,743        4,970.35        3.65        1,815.26        72.12        0.00        cj52cq1u1hbrf         JDBC Thin Client         select servantuse0_.id as id98...
18,979,084        2,246,340        8.45        2.94        339.83        97.75        0.00        akdb1nqh7k3wp         JDBC Thin Client         select columns0_.infoid as inf...
18,131,052        320,423        56.58        2.81        875.91        93.84        0.00        dhu478ugjs6j1         JDBC Thin Client         select infos0_.columnid as col...



SQL ID :6dnhd625c5gz5   平均一次 逻辑读 4,945
SQL ID: cj52cq1u1hbrf   平均一次逻辑读 4,970




可疑点：


index fast full scans (full)        3,249,123        898.99        161.77
index fetch by key        30,586,262        8,462.84        1,522.84

==>　INDEX FAST FULL SCAN的 次数很多

lob reads        2,809,938        777.48        139.90

==>  LOB READ 每秒 777次

table fetch by rowid        18,094,589        5,006.55        900.90
table fetch continued row        404,320        111.87        20.13


建议你调优 SQL ID :6dnhd625c5gz5 和 cj52cq1u1hbrf     优化执行计划 减少逻辑读，从而减轻CPU的使用率。

orafans

多谢LIU的分析。
问题基本有所缓和,DB的周边环境有问题,通过网络探测发现有DDOS攻击，致使消耗CPU过高，网络瓶颈大，通过AWR发现子表的外键没有索引而导致DB 的CPU消耗很高（基本90%消耗率）。
找到SID_ID所对应的表，创建外键索引解决。
解决办法：
1，创建子表的外键索引。------->解决TM - CONTENTION的问题，等待事件消除。
2，增加ddos硬件设备。现在目前DB服务正常。

[ 本帖最后由 orafans 于 2012-3-20 19:30 编辑 ]

orafans

LIU：

Buffer Gets         Executions        Gets per Exec         %Total        Elapsed Time (s)        %CPU        %IO        SQL Id        SQL Module        SQL Text
27,126,217       5,485        4,945.53        4.20        3,238.88        65.75        0.01        6dnhd625c5gz5         JDBC Thin Client         select servantapp0_.id as id49...
23,574,375       4,743        4,970.35        3.65        1,815.26        72.12        0.00        cj52cq1u1hbrf         JDBC Thin Client         select servantuse0_.id as id98...
18,979,084        2,246,340        8.45        2.94        339.83        97.75        0.00        akdb1nqh7k3wp         JDBC Thin Client         select columns0_.infoid as inf...
18,131,052       320,423        56.58        2.81        875.91       93.84        0.00        dhu478ugjs6j1         JDBC Thin Client         select infos0_.columnid as col...

图中的红色能说明什么？SID_ID为akdb1nqh7k3wp产生了2,246,340这么多次的excecution.消耗了93%的CPU。这个也需要调优吧。