请求协助分析awr top 5

与晶之恋

这是同一个数据库的不同时间段的awr的Top 5 Timed Foreground Events，第一个是24小时的，第二个是0点到早上10点的，求指导分析下？

之前咨询过一些人说时间太长没有参考价值，但是两个都有同样的长等待，希望能有结论或者缩小优化范围。到时候会让现场再提供snap时间段更短的awr，


顺便贴下summary
WORKLOAD REPOSITORY report for
DB Name        DB Id        Instance        Inst num        Startup Time        Release        RAC
USASRAW        1210947079        USASRAW        1        27-Nov-12 11:11        11.2.0.2.0        NO
Host Name        Platform        CPUs        Cores        Sockets        Memory (GB)
RAWDB1        HP-UX IA (64-bit)         8         8         2         31.90
Snap Id        Snap Time        Sessions        Cursors/Session
Begin Snap:        14406        18-Jun-13 00:00:23        200         .9
End Snap:        14416        18-Jun-13 10:00:25        179         1.0
Elapsed:                  600.04 (mins)                  
DB Time:                  1,223.13 (mins)                  
Report Summary
Cache Sizes

Begin        End               
Buffer Cache:         5,344M         5,344M        Std Block Size:         8K
Shared Pool Size:         7,968M         7,968M        Log Buffer:         32,076K
Load Profile

Per Second        Per Transaction        Per Exec        Per Call
DB Time(s):         2.0         0.0         0.01         0.01
DB CPU(s):         0.6         0.0         0.00         0.00
Redo size:         298,041.2         4,543.5                  
Logical reads:         5,887.2         89.8                  
Block changes:         1,268.6         19.3                  
Physical reads:         224.8         3.4                  
Physical writes:         304.0         4.6                  
User calls:         344.1         5.3                  
Parses:         169.7         2.6                  
Hard parses:         32.1         0.5                  
W/A MB processed:         0.8         0.0                  
Logons:         3.1         0.1                  
Executes:         233.5         3.6                  
Rollbacks:         0.0         0.0                  
Transactions:         65.6                           
Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:         100.00        Redo NoWait %:         100.00
Buffer Hit %:         97.74        In-memory Sort %:         100.00
Library Hit %:         75.95        Soft Parse %:         81.07
Execute to Parse %:         27.30        Latch Hit %:         99.98
Parse CPU to Parse Elapsd %:         94.12        % Non-Parse CPU:         53.41
Shared Pool Statistics

Begin        End
Memory Usage %:         43.90         46.22
% SQL with executions>1:         73.85         72.77
% Memory for SQL w/exec>1:         64.86         57.70
Top 5 Timed Foreground Events

Event        Waits        Time(s)        Avg wait (ms)        % DB time        Wait Class
SQL*Net message from dblink        1,734,764        28,346        16        38.63        Network
DB CPU                 23,064                 31.43         
db file parallel read        198,989        7,026        35        9.57        User I/O
log file sync        2,425,344        3,082        1        4.20        Commit
db file sequential read        2,079,802        2,781        1        3.79        User I/O
Host CPU (CPUs: 8 Cores: 8 Sockets: 2)

Load Average Begin        Load Average End        %User        %System        %WIO        %Idle
0.23         0.07         9.3         5.0         13.5         85.7
Instance CPU

%Total CPU        %Busy CPU        %DB time waiting for CPU (Resource Manager)
10.6         74.4         0.0
Memory Statistics

Begin        End
Host Mem (MB):         32,666.5         32,666.5
SGA use (MB):         14,016.0         14,016.0
PGA use (MB):         711.5         526.2
% Host Mem used for SGA+PGA:         45.08         44.52

harry.ho

目测是这只有两个原因：
1.　网络问题，网络比较忙。
2.　SQL问题，据说使用DBLINK时，会将所有数据都将所有数据库都传送到本地再处理。ORACLE建议使用DBLINK时，不要直接使用远端的数据表，而是使用该表对应的视图先过滤一些记录，这样会减少编译时间和数据的传递。

dla001

harry.ho 发表于 2013-6-25 19:53
目测是这只有两个原因：
1.　网络问题，网络比较忙。
2.　SQL问题，据说使用DBLINK时，会将所有数据都将所 ...

dblink时，并不是将数据都传送到本地再处理。oracle可以做到在远端处理数据，然后将结果再传回到本地。
可以参考案例：
http://www.xifenfei.com/1492.html

使用dblink要注意的就是：
1.驱动表要正确。
2.表之间的连接方法的选择。
3.不要选取无用的字段。
4.网络环境。

与晶之恋

harry.ho 发表于 2013-6-25 19:53
目测是这只有两个原因：
1.　网络问题，网络比较忙。
2.　SQL问题，据说使用DBLINK时，会将所有数据都将所 ...

谢谢，最后是找了SQL ordered by Elapsed Time，里边有dblink时间较长的sql等待要求能不能优化，和检查网络，还有2条JOB等待比较恐怖也让业务侧去分析,顺便想问问为什么job的没有执行次数的？

与晶之恋

dla001 发表于 2013-6-26 09:56
dblink时，并不是将数据都传送到本地再处理。oracle可以做到在远端处理数据，然后将结果再传回到本地。
...

谢谢，这会作为优化的意见和参考提上去。

harry.ho

dla001 发表于 2013-6-26 09:56
dblink时，并不是将数据都传送到本地再处理。oracle可以做到在远端处理数据，然后将结果再传回到本地。
...

谢谢提醒了。记住了。

Hank-D

看你这个是OLTP的库，OLTP的库，则你的软解析做的不太好，需要优化

SKYLINE.LIU

dblink查询数据时关联两边的表的话性能会很差，还有就是每次处理数据的量也需要控制一下。