io不好，oracle先看这里

如果觉得io不正常，例如top命令的wait%大于20%，会不会是导致数据库慢的原因呢？
先看这个

col name for a25

select m.intsize_csec,
       n.name ,
       round(m.time_waited,3) time_waited,
       m.wait_count,
       round(10*m.time_waited/nullif(m.wait_count,0),3) avgms
from v$eventmetric m,
     v$event_name n
where m.event_id=n.event_id
  and n.name in (
                  'db file sequential read',
                  'db file scattered read',
                  'direct path read',
                  'direct path read temp',
                  'direct path write',
                  'direct path write temp',
                  'log file sync',
                  'log file parallel write'
);

效果如下：

如果最右列的值大于20，则说明io的确有问题，不符合oracle预期。

操作系统层面呢？
最简单的方法可以试试cp一个1G的文件，读取速度如果小于50MB/s，说明速度不快，例如：
time cp /oradata/sysaux01.dbf /oradata/test1.log

我的虚拟机上效果：

读取速度是37MB/s

当然猎户座可以帮忙，orion
[oracle@db01 ~]$ orion -help


如果间歇性io慢怎么办？
osw 或者 sar -f /var/log/sa/sa28 看看wait%历史



展示一下IO等待统计结果

-- from tanelpoder.com

BREAK ON snap_begin SKIP 1 ON snap_end ON event_name

COL event_name FOR A40

SELECT
    CAST(begin_interval_time AS DATE) snap_begin
  , TO_CHAR(CAST(end_interval_time AS DATE), 'HH24:MI') snap_end
  , event_name
  , wait_time_milli
  , CASE WHEN wait_count >= LAG(wait_count) OVER (PARTITION BY event_name,wait_time_milli ORDER BY CAST(begin_interval_time AS DATE)) THEN
        wait_count - LAG(wait_count) OVER (PARTITION BY event_name,wait_time_milli ORDER BY CAST(begin_interval_time AS DATE))
    ELSE
        wait_count
    END wait_count
FROM
    dba_hist_snapshot
  NATURAL JOIN
    dba_hist_event_histogram
WHERE
    begin_interval_time > SYSDATE - 1/24
--AND event_name LIKE 'ASM file metadata operation'
--AND event_name LIKE 'flashback log switch'
-- AND event_name LIKE 'KSV master wait'
AND wait_class = 'User I/O'
ORDER BY
    event_name
  , snap_begin
  , wait_time_milli
/

效果如下：


如果io没有问题，那么就要分析方向就要转向是不是内存用完了，大量换页导致？
当然大部分是由于sql性能较差导致。