AIX系统性能管理之Oracle案例分析

    　　我想，在这里我们对比cpu time和Elapsd time就可以发现，这里I/O等待的情况非常严重。当然，也可以进一步检查过程内语句的执行计划情况，看是否合理。在这里，还是来关注io的情况。

    　　在表空间的io统计中，比较繁忙的表空间是：

    ->ordered by IOs (Reads + Writes) desc
    Tablespace
    ------------------------------
                     Av      Av     Av                    Av        Buffer Av Buf
             Reads Reads/s Rd(ms) Blks/Rd       Writes Writes/s      Waits Wt(ms)
    -------------- ------- ------ ------- ------------ -------- ---------- ------
    TBS_MCN_HIS_IDX
           109,393      61   94.2     1.0      421,033      233      8,004    1.8
    TBS_MCN_LOG_IDX
           101,915      56   74.3     1.0      416,523      231     34,705    2.8
    TBS_MCN_MAIN_IDX
           110,871      61   43.9     1.0      200,902      111     15,797    1.4
    TBS_MCN_MAIN_DAT
           108,012      60   79.2     1.2       68,267       38      9,668    0.9

    　　在看file io之前，先看一下hdisk4和hdisk5的各自拥有的lv情况。

    #lspv -l hdisk4
    hdisk4:
    LV NAME               LPs   PPs   DISTRIBUTION          MOUNT POINT
    lv_data052            64    64    00..00..64..00..00    N/A
    lv_data009            64    64    00..64..00..00..00    N/A
    lv_data053            64    64    00..00..64..00..00    N/A
    …
    #lspv -l hdisk5
    hdisk5:
    LV NAME               LPs   PPs   DISTRIBUTION          MOUNT POINT
    lv_data143            64    64    00..00..64..00..00    N/A
    lv_data100            64    64    00..64..00..00..00    N/A
    lv_data244            64    64    00..00..00..00..64    N/A
    lv_data142            64    64    00..00..64..00..00    N/A
    lv_data099            64    64    00..64..00..00..00    N/A

    　　通过观察，可以分布的大致情况是，080以上的lv基本在hdisk5中，080以下lv基本都在hdisk4中。现在再对比一下file io的统计：

    　　根据file io的统计，去计算一下，在hdisk4和hdisk5中的物理读的数量差不多是

    　　Hdisk4：132,578

    　　Hdisk5：261,996

    　　Hdisk5的io量差不多就是hdisk4的两倍。这和前面iostat的统计的结果也基本差不多。

    　　下面几个是file io统计中最繁忙的几个lv。

    TBS_MCN_LOG_IDX          /dev/rlv_data096
            50,938      28   74.8     1.0      209,422      116     17,496    2.6
                             /dev/rlv_data097
            50,977      28   73.7     1.0      207,101      115     17,209    3.0
    TBS_MCN_MAIN_DAT         /dev/rlv_data009
            15,625       9   20.6     1.0          985        1          0
                             /dev/rlv_data010
            33,026      18   18.0     1.5       26,717       15      9,658    0.7
                             /dev/rlv_data091
            37,009      21  118.5     1.2       38,190       21          9  107.8
                             /dev/rlv_data092
            22,352      12  145.5     1.0        2,375        1          1   70.0

    TBS_MCN_MAIN_IDX         /dev/rlv_data018
            26,666      15   17.6     1.0       35,333       20      4,023    1.8
                             /dev/rlv_data019
            26,661      15   17.3     1.0       35,216       20      3,368    0.9
                             /dev/rlv_data020
            30,600      17   17.1     1.0       93,095       52      4,274    1.1
                             /dev/rlv_data093
            26,944      15  126.8     1.0       37,258       21      4,132    1.8

    再来统计一下，表的读写情况。

    　　通过上面的file io以及表的统计，再结合实际的业务情况，可以明确，这里最繁忙的是表空间TBS_MCN_LOG_DAT中的表T_MC_SMS_SMSNOTI以及其上位于表空间TBS_MCN_LOG_IDX中的索引。并且，这两部分全部集中再hdisk5上，所以后面的平衡io的优化操作就是将该表以及索引部分分布到hdisk4上。

 

 

上一页  [1] [2] [3] [4]