10.2.0.5 RAC 响应慢
附件是awr，请飞总帮忙看一下多谢DB NameDB IdInstanceInst numReleaseRACHost
ORCL1369647711orcl1110.2.0.5.0YESrac1
Snap IdSnap TimeSessionsCursors/Session
Begin Snap:55124-Mar-14 10:21:56463.0
End Snap:55324-Mar-14 11:02:3713119.2
Elapsed: 40.69 (mins)
DB Time: 468.52 (mins)
Cache Sizes
BeginEnd
Buffer Cache:25,696M25,360MStd Block Size:8K
Shared Pool Size:4,256M4,592MLog Buffer:14,304K
Load Profile
Per SecondPer Transaction
Redo size:3,012,070.3711,831.37
Logical reads:595,804.792,340.31
Block changes:21,399.1884.06
Physical reads:694.702.73
Physical writes:295.791.16
User calls:6,410.6225.18
Parses:2,378.619.34
Hard parses:234.140.92
Sorts:525.402.06
Logons:0.090.00
Executes:2,566.8310.08
Transactions:254.58
top 等待事件
EventWaitsTime(s)Avg Wait(ms)% Total Call TimeWait Class
CPU time
21,916
78.0
log file sync675,6641,70836.1Commit
direct path read1,498,11074302.6User I/O
library cache lock560,53764512.3Concurrency
enq: RO - fast object reuse58,630563102.0Application
系统情况
StatisticTotal
BUSY_TIME2,313,720
IDLE_TIME5,499,303
IOWAIT_TIME97,385
NICE_TIME51
SYS_TIME133,792
USER_TIME2,115,042
LOAD7
RSRC_MGR_CPU_WAIT_TIME0
VM_IN_BYTES13,991,230,464
VM_OUT_BYTES14,082,662,400
PHYSICAL_MEMORY_BYTES2.7E+11
NUM_CPUS32
NUM_CPU_SOCKETS4
这个库，主要是事务数比较高，其他等待都还好，因此优化这个库，可能主要考虑：
1.优化一些top sql（l）
2.事务是否可以做批量处理？
3.业务逻辑上的优化
看着awr报告压力不大啊 ！这个服务器的内存250G?配置大页了吗？SGA才25G,可能会的调整下，在优化下SQL ordered by Gets的top sql 本身库就不大，库只有50G左右，我看到direct path read这个等待事件，但是我在dba_hist_acctive视图中没有找到任何的session在等待这个，不知道为啥...
select * from dba_hist_active_sess_history where snap_idin (553,551) and event like '%read';
哪位给说说这啥原因.... direct path read 这个等待可以忽悠 ！ direct path read在IO差的系统中，这个等待事件多 也不好吧？ 这样 总是直接从磁盘中读
页:
[1]