请教关于awr中userio占用高的分析

lxhbww

rac环境，在oel5+oracle11grac+dg
二节点出现
Top 5 Timed Foreground Events
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
db file sequential read 887,423 4,463 5 50.62 User I/O
DB CPU   3,364   38.15   
log file sync 40,808 455 11 5.16 Commit
db file scattered read 41,666 177 4 2.00 User I/O
gc current block 2-way 390,083 138 0 1.57 Cluster
出现db file sequential read怎么定位哪些有问题？尽量让这个降下来。详细见附件awr.

Maclean Liu(刘相兵

odm finding:

Elapsed:                 120.34 (mins)                  
DB Time:                 143.84 (mins)           ==> 负载轻微

Event        Waits        Time(s)        Avg wait (ms)        % DB time        Wait Class
db file sequential read        758,411        4,062        5        47.07        User I/O
DB CPU                 3,609                 41.82         
log file sync        46,317        453        10        5.25        Commit
db file scattered read        44,772        177        4        2.05        User I/O
gc current block 2-way        353,850        123        0        1.43        Cluster

db file sequential read ==》　avg wait 5ms 主要等待事件

Wait Class        Waits        %Time -outs        Total Wait Time (s)        Avg wait (ms)        %DB time
User I/O        856,588        0        4,441        5        51.46
DB CPU                          3,609                 41.82
Commit        46,317        0        453        10        5.25

User I/O 是2节点的主要性能瓶颈， 体现在db file sequential read上

Segments by Physical Read Requests

    Total Physical Read Requests: 929,502
    Captured Segments account for 57.6% of Total

Owner        Tablespace Name        Object Name        Subobject Name        Obj. Type        Phys Read Requests        %Total
USERHXRM        TSP_ZHUYUAN        Z_YIZHUFASONG                 TABLE        192,296        20.69
USERHXRM        TSP_ZHUYUAN        Z_FEIYONG                 TABLE        70,148        7.55


Segments by Physical Reads

    Total Physical Reads: 4,166,127
    Captured Segments account for 71.1% of Total

Owner        Tablespace Name        Object Name        Subobject Name        Obj. Type        Physical Reads        %Total
USERHXRM        TSP_ZHUYUAN        Z_YIZHUFASONG                 TABLE        2,216,970        53.21


对Z_YIZHUFASONG这张表的 物理读 占了总物理读的一半以上

值得注意的一点是

table fetch continued row        1,013,245        140.33        21.75

continued row fetch 每秒 有 140次 ， 说明系统中存在 链式行或迁移行 ， 可能就在Z_YIZHUFASONG 上，建议对该表做chained rows analyze .


Component        Min Size (Mb)        Max Size (Mb)        Avg Size (Mb)        Re- Sizes        Grows        Shrinks
DEFAULT buffer cache        2,016.00        2,016.00        2,016.00        12        0        12
shared pool        2,464.00        2,464.00        2,464.00        12        12        0

buffer cache 发生过 12次 shrink

从 Buffer Pool Advisory 看 加大 buffer cache 可以有效减少物理读，

根据Buffer Pool Advisory 若buffer cache 加大到3,840MB         ， 可以减少 70%的物理读。

lxhbww

谢谢刘大精彩点评.

lxhbww

从 Buffer Pool Advisory 看 加大 buffer cache 可以有效减少物理读，
根据Buffer Pool Advisory 若buffer cache 加大到3,840MB         ， 可以减少 70%的物理读。

我的内存采用自动管理memory_target 7331643392 给了7G多，而从awr报告中都只看到
Host Mem (MB): 16,022.9 16,022.9
SGA use (MB): 4,560.0 4,560.0
PGA use (MB): 687.7 691.9
% Host Mem used for SGA+PGA: 32.75 32.78
为什么设置了7G多，二台都sga+pga都只用到5G左右？

buffer cache 加大到3,840MB 要怎么改？
是不是要改成手动管理才能去调大buffer cache?
一般内存管理建议用手动还是自动？

Maclean Liu(刘相兵

Answer:


"为什么设置了7G多，二台都sga+pga都只用到5G左右？"


PGA 是按需分配的， PGA虽然有一个target值(可以从V$memory_Dynamic_Components视图中查询到pga target的current size可能远大于pga_aggregate_target(这里查询出来的current size仅代表pga的一个目标值，不是pga当前实际占用的内存))

"一般内存管理建议用手动还是自动？"

不同的场景 不同的应用 ， 不同的建议

是不是要改成手动管理才能去调大buffer cache?

不是

"buffer cache 加大到3,840MB 要怎么改？"

在AMM 下 加大sga_target的 同时 加大 db_cache_size到 3840MB

popowin

table fetch continued row        1,013,245        140.33        21.75

continued row fetch 每秒 有 140次 ， 说明系统中存在 链式行或迁移行 ， 可能就在Z_YIZHUFASONG 上，建议对该表做chained rows analyze .


存在链式行和迁移行仅仅参考table fetch continued row 这个Activity有点不妥吧，结合table fetch by rowid  如果这个值也很大，那对链式行或迁移行的判断就有点模糊了，不知道这么理解对不对

Maclean Liu(刘相兵

Table Fetch by Continued Row

You can detect migrated or chained rows by checking the number of table fetch continued row statistic in V$SYSSTAT. A small number of chained rows (less than 1%) is unlikely to impact system performance. However, a large percentage of chained rows can affect performance.

Chaining on rows larger than the block size is inevitable. You might want to consider using tablespace with larger block size for such data.

http://docs.oracle.com/cd/B19306_01/server.102/b14211/instance_tune.htm#sthref662




table fetch by rowid


Number of rows that are fetched using a ROWID (usually recovered from an index)

table fetch by rowid

When rows are fetched using a ROWID (usually recovered from an index), each row returned increments this counter.

This statistic is an indication of row fetch operations being performed with the aid of an index. Because doing table scans usually indicates either non-optimal queries or tables without indexes, this statistic should increase as the above issues have been addressed in the application.


Table Fetch by Continued Row 可以用来评估系统中的 migrated or chained rows

table fetch by rowid 反应使用ROWID (往往来源于索引) 来fetch 表上的row的记录数，和 链式行、迁移行没有直接关系