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

    #netstat -i
    Name  Mtu   Network     Address            Ipkts Ierrs    Opkts Oerrs  Coll
    en7   1500  link#2      0.14.5e.c5.5d.2e  3133315897     0 2978410586     4     0
    en7   1500  10.33.102.9 jsdxh_db_svc      3133315897     0 2978410586     4     0
    en9   1500  link#3      0.14.5e.c5.64.b8  16814726     0  3897247     3     0
    en9   1500  192.168.0   jsdxh_db01_stby   16814726     0  3897247     3     0
    lo0   16896 link#1                        13949555     0 13969868     0     0
    lo0   16896 127         loopback          13949555     0 13969868     0     0
    lo0   16896 ::1                           13949555     0 13969868     0     0

    　　从上面对数据库主机的操作系统层面的情况检查来看，大致可以判断造成问题主要应该是在io上面。尤其是hdisk5，hdisk5的io负担过重，可以考虑与分担一部分的量到hdisk4上，以平衡磁盘io，减少io等待。下面对数据库部分的分析也主要在io这一块，其他方面在这里就不作分析了。

    　　下面对数据库部分的分析思路大致如下：找到读写最频繁读写的lv(有可能是表，索引或者其他的)，分布其流量。

    下面再对数据库来作分析。

    1、检查了一下alert日志。

    $ tail -100 alert_ora92.log |more
    Thu Oct 25 17:43:29 2007
    Thread 1 advanced to log sequence 68444
      Current log# 3 seq# 68444 mem# 0: /dev/rlv_redo13
      Current log# 3 seq# 68444 mem# 1: /dev/rlv_redo16
    Thu Oct 25 17:47:26 2007
    Thread 1 advanced to log sequence 68445
      Current log# 4 seq# 68445 mem# 0: /dev/rlv_redo11
      Current log# 4 seq# 68445 mem# 1: /dev/rlv_redo14
    Thu Oct 25 17:51:16 2007
    Thread 1 advanced to log sequence 68446
      Current log# 5 seq# 68446 mem# 0: /dev/rlv_redo12
      Current log# 5 seq# 68446 mem# 1: /dev/rlv_redo15

    　　从日志中看，redo切换的频率相当高，基本上是4分钟不到，就会作一次日志的切换操作。Redo是3个组，每组2个member，每个member 500M。

    2、statspack

    Top 5 Timed Events
    ~~~~~~~~~~~~~~~~~~                                                     % Total
    Event                                               Waits    Time (s) Ela Time
    -------------------------------------------- ------------ ----------- --------
    log file sync                                     483,667      84,354    64.69
    db file sequential read                           469,344      35,231    27.02
    enqueue                                            82,536       5,747     4.41
    CPU time                                                        2,150     1.65
    db file parallel write                             11,919       1,245      .96

    从top 5事件看，

    　　日志的写入速度太慢。这需要对应用作调整，将频繁commit的改为批量提交。但是在这里我想可能更大的原因是磁盘io的原因。检查一下相关的日志文件，以及相关redo的lv情况：

    QL> /
        GROUP# STATUS  TYPE    MEMBER
    ---------- ------- ------- ------------------------------
             3         ONLINE  /dev/rlv_redo13
             3         ONLINE  /dev/rlv_redo16
             4         ONLINE  /dev/rlv_redo11
             4         ONLINE  /dev/rlv_redo14
             5         ONLINE  /dev/rlv_redo12
             5         ONLINE  /dev/rlv_redo15
    SQL> !
    $ lslv -l lv_redo13
    lv_redo13:N/A
    PV                COPIES        IN BAND       DISTRIBUTION
    hdisk4            008:000:000   0%            000:000:000:000:008
    $ lslv -l lv_redo16
    lv_redo16:N/A
    PV                COPIES        IN BAND       DISTRIBUTION
    hdisk5            008:000:000   0%            000:000:008:000:000
    $ lslv -l lv_redo11
    lv_redo11:N/A
    PV                COPIES        IN BAND       DISTRIBUTION
    hdisk4            008:000:000   0%            008:000:000:000:000
    $ lslv -l lv_redo14
    lv_redo14:N/A
    PV                COPIES        IN BAND       DISTRIBUTION
    hdisk5            008:000:000   0%            008:000:000:000:000
    $ lslv -l lv_redo12
    lv_redo12:N/A
    PV                COPIES        IN BAND       DISTRIBUTION
    hdisk4            008:000:000   0%            000:000:000:000:008
    $ lslv -l lv_redo15
    lv_redo15:N/A
    PV                COPIES        IN BAND       DISTRIBUTION
    hdisk5            008:000:000   0%            008:000:000:000:000

    　　在这里，每个组中的两个member一个在hdisk4，一个在hdisk5，分布在磁盘的边缘。可以考虑改变一下内策略，将redo分布调整到磁盘的中间位置。因为本身是raid10的方式，或者干脆不要两个member，只使用其中的一个member，这个有可能带来其他的问题，如果非不得已，不考虑这种方法。

    　　另外一个等待事件，顺序读。这个事件一般是由于不当的选择索引或者表的连接。但在这里，我想可能并不是这个原因，而主要还是磁盘繁重的io造成的。看一下物理读排序的SQL语句：

    SQL ordered by Reads for DB: ORA92  Instance: ora92  Snaps: 47 -48
    -> End Disk Reads Threshold:      1000
                                                         CPU      Elapsd
     Physical Reads  Executions  Reads per Exec %Total Time (s)  Time (s) Hash Value
    --------------- ------------ -------------- ------ -------- --------- ----------
            170,449      206,955            0.8   33.1   279.55  20719.02 4053432766
    Module: Das.exe
    BEGIN  p_mc_sce_addsms(:p0,:p1,:p2,:p3,:p4,:p5,:p6,:p7,:p8); END
    ;
            142,856      233,890            0.6   27.8    74.05   9616.88 1594289970
    Module: Das.exe
    SELECT MAX(T.ACTIVE_FLAG), MAX(T.SECOND_NO) FROM T_MC_MCN_USERIN
    FO T WHERE T.USER_NO = :B1 AND T.PARTCOL_USERNO = SUBSTR(:B1 , -
    3, 2) AND ROWNUM <= 1

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

【责编:Ken】