10.2.0.5 RAC 响应慢

aaaaaaaa2000

附件是awr，请飞总帮忙看一下多谢

xifenfei

DB Name	DB Id	Instance	Inst num	Release	RAC	Host
ORCL	1369647711	orcl1	1	10.2.0.5.0	YES	rac1

	Snap Id	Snap Time	Sessions	Cursors/Session
Begin Snap:	551	24-Mar-14 10:21:56	46	3.0
End Snap:	553	24-Mar-14 11:02:37	131	19.2
Elapsed:		40.69 (mins)
DB Time:		468.52 (mins)

Cache Sizes

	Begin	End
Buffer Cache:	25,696M	25,360M	Std Block Size:	8K
Shared Pool Size:	4,256M	4,592M	Log Buffer:	14,304K

Load Profile

	Per Second	Per Transaction
Redo size:	3,012,070.37	11,831.37
Logical reads:	595,804.79	2,340.31
Block changes:	21,399.18	84.06
Physical reads:	694.70	2.73
Physical writes:	295.79	1.16
User calls:	6,410.62	25.18
Parses:	2,378.61	9.34
Hard parses:	234.14	0.92
Sorts:	525.40	2.06
Logons:	0.09	0.00
Executes:	2,566.83	10.08
Transactions:	254.58

top 等待事件

Event	Waits	Time(s)	Avg Wait(ms)	% Total Call Time	Wait Class
CPU time		21,916		78.0
log file sync	675,664	1,708	3	6.1	Commit
direct path read	1,498,110	743	0	2.6	User I/O
library cache lock	560,537	645	1	2.3	Concurrency
enq: RO - fast object reuse	58,630	563	10	2.0	Application

系统情况

Statistic	Total
BUSY_TIME	2,313,720
IDLE_TIME	5,499,303
IOWAIT_TIME	97,385
NICE_TIME	51
SYS_TIME	133,792
USER_TIME	2,115,042
LOAD	7
RSRC_MGR_CPU_WAIT_TIME	0
VM_IN_BYTES	13,991,230,464
VM_OUT_BYTES	14,082,662,400
PHYSICAL_MEMORY_BYTES	2.7E+11
NUM_CPUS	32
NUM_CPU_SOCKETS	4

这个库，主要是事务数比较高，其他等待都还好，因此优化这个库，可能主要考虑：
1.优化一些top sql（l）
2.事务是否可以做批量处理？
3.业务逻辑上的优化

travel.liu

看着awr报告压力不大啊 ！这个服务器的内存250G?配置大页了吗？SGA才25G,可能会的调整下，在优化下SQL ordered by Gets的top sql

aaaaaaaa2000

本身库就不大，库只有50G左右，我看到direct path read这个等待事件，但是我在dba_hist_acctive视图中没有找到任何的session在等待这个，不知道为啥...
select * from dba_hist_active_sess_history where snap_id  in (553,551) and event like '%read';
哪位给说说这啥原因....

travel.liu

direct path read 这个等待可以忽悠 ！

yrg5101

direct path read  在IO差的系统中，这个等待事件多 也不好吧？ 这样 总是直接从磁盘中读