请大家分析一下超烂系统的oracle AWR

西西梅丽

因为是第三方提供开发的程序，很多我们都不能修改，并且该oracle运行在虚拟机上，请大家指出问题点，以便于我们寻找开发商处理。谢谢各位。

lunar

提问，请说明：
1，OS平台，DB平台，版本
2，目前问题
3，系统资源情况

背向天堂

Elapsed:   5,592.74 (mins)     
DB Time:   4,464.01 (mins)

建议重新选择一个有代表性的时间点。awr的时间太长了。



Segments by Logical Reads
Owner Tablespace Name Object Name Subobject Name Obj. Type Logical Reads %Total
OAAPP1 USERS WF_PENDING   TABLE 2,001,428,448 61.31
YCSSO OA_DATA01 CASLOG   TABLE 332,627,440 10.19


Segments by Physical Reads
YCSSO OA_DATA01 CASLOG   TABLE 332,075,479 73.30
OAAPP1 USERS WF_ACTIVITY   TABLE 85,632,292 18.90

下面段统计里面的有几张表占用的io比例很大。建议检查下是否存在索引，或者是索引不合理。

西西梅丽

重新生成AWR报告
1月14日早上9点-11点
OS :  2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
ORACLE:    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options
ESXI5.0：虚拟磁盘

top - 10:54:58 up 34 days, 11:05,  2 users,  load average: 1.11, 1.29, 1.61
Tasks: 352 total,   1 running, 351 sleeping,   0 stopped,   0 zombie
Cpu(s): 21.4%us,  3.8%sy,  0.0%ni, 19.7%id, 54.1%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   6106868k total,  6064476k used,    42392k free,    15120k buffers
Swap:  5245212k total,   130928k used,  5114284k free,  3914440k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                             
5321 oracle    18   0 1187m 289m  21m S 11.6  4.9  12:04.92 java                                                
28684 oracle    15   0 2775m 529m 525m S  6.6  8.9   0:16.00 oracle                                               
28698 oracle    15   0 2777m 684m 680m S  5.0 11.5   0:17.77 oracle                                               
28996 oracle    15   0 2775m 116m 112m S  3.0  1.9   0:21.38 oracle                                               
24761 oracle    15   0 2779m 398m 392m S  2.7  6.7   4:52.42 oracle                                               
28638 oracle    15   0 2775m 632m 629m S  2.3 10.6   0:16.04 oracle                                               
28650 oracle    16   0 2775m 540m 535m D  2.3  9.1   0:16.08 oracle                                               
28668 oracle    15   0 2775m 639m 635m S  1.7 10.7   0:19.29 oracle                                               
28680 oracle    15   0 2777m 596m 592m S  1.7 10.0   0:16.72 oracle                                               
28641 oracle    15   0 2775m 615m 611m S  1.0 10.3   0:16.62 oracle                                               
28682 oracle    15   0 2775m 540m 536m S  1.0  9.1   0:15.83 oracle                                               
28722 oracle    15   0 2786m 588m 584m S  1.0  9.9   0:15.09 oracle                                               
  438 oracle    15   0 12876 1292  808 R  0.7  0.0   0:00.08 top                                                  
1898 oracle    15   0 2775m 487m 483m S  0.7  8.2   0:15.70 oracle         

背向天堂

主要的等待都是io相关的：
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
db file sequential read 1,725,934 44,276 26 65.41 User I/O
db file parallel read 8,394 9,659 1151 14.27 User I/O
read by other session 35,747 6,584 184 9.73 User I/O

逻辑读也很大：
Logical reads: 38,359.5 27,211.4     

这几个语句的io开销比较大。需要检查下，是否确实索引，或者执行计划走的有问题：
SQL ordered by Elapsed Time
1sgqm7hvgrks5
2dndq6gsk8v8u

SQL ordered by User I/O Wait Time
1sgqm7hvgrks5
2dndq6gsk8v8u

SQL ordered by Gets
d9qnrazcttcmh

SQL ordered by Reads
7dxuuhzp62v7n


IOStat by Filetype summary
Data File 391.3G 273.78 39.2319 594M 6.05 .058153 26.03 3.85

段统计：重点检查一下这几个对象，本身的io效率不高，表是不是可以进行分区，历史数据是不是可以进行清理。
Segments by Logical Reads
OAAPP1 USERS WF_PENDING   TABLE 244,103,216 62.30

Segments by Physical Read Requests
OAAPP1 USERS WF_HISTORY   TABLE 1,435,626 51.34

Segments by UnOptimized Reads
OAAPP1 USERS WF_HISTORY   TABLE 1,435,626 51.34

Segments by Direct Physical Reads
YCSSO OA_DATA01 CASLOG   TABLE 35,811,440 73.35
OAAPP1 USERS WF_ACTIVITY   TABLE 11,805,976 24.18