通過addm分析io問題

昨晚在做測試環境資料遷移的時候，遇到了io的問題，本來預計2，3個小時完成的資料匯入工作最後竟然耗了7個多小時。在資料的匯入中，使用了10個並行的session，每個session都啟用的並行度為8,在表級，索引級都做了nologging設定，在insert的時候使用了append模式，結果本來資料的匯入還是比較順利的，突然在8點左右開始就一下子直線下降。
在使用top命令檢視程式的使用情況時，留意到rman的一些程式正在執行。但是大晚上的哪找客戶的人來確認這個，使用dd來測試io的效能，建立一個200M的檔案，不到1秒鐘，還是比較快的。
但是可以看到iowait很高。
這個問題造成的影響還是比較嚴重的，因為目前為止還沒有完全確定問題的根源，如果是後臺的一些程式在執行，影響到底有多少，還沒有估量，但是可以明顯的看到資料庫是不給力的，undo的空間到後面的資料匯入中不僅足夠充裕，還不斷釋放一些空間，讓人感覺很鬱悶，但是又插不上什麼手。

下午的時候，和客戶的儲存部門，unix部門等的人一起開會，大家都列除了昨晚的一些問題總之就是發現了問題，但是因為那個段知道的動作就是我們在做資料匯入，還沒法確定到底是不是他們的問題。所以大家雖然能夠列出一些圖表資料，說明問題但是還是沒有能夠明確的定位問題。

我拿出了資料庫層面反應資料庫繁忙程度的一個指標，redo的切換率，在週一做的一次資料遷移中，redo在一個小時甚至達到了200多次。redo日誌是1個G左右的樣子。

DBNAME    TIME_STAMP
--------- --------------------
PRODB   2014-Aug-14 23:09:09

    GROUP#    THREAD#  SEQUENCE#    MEMBERS    SIZE_MB ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
         1          1       3389          2       1024 YES INACTIVE
         2          1       3390          2       1024 YES INACTIVE
         3          1       3391          2       1024 NO  CURRENT
         4          1       3388          2       1024 YES INACTIVE

Redo Switch times per hour                                              PRODB                                                   2014-Aug-14 23:09:09
MON DA   00   01   02   03   04   05   06   07   08   09   10   11   12   13   14   15   16   17   18   19   20   21   22   23
--- -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
07  31    0    0    1    0    0    0    0    0    0    0    0    0    0    0    1    1    5    1    0    4    1    0    0    2
08  01   35   51   19    0    0    1    0    0    1    0    1    4    2    1    2    9    5    4    3    4    3    2    2    2
08  02    1    1    1    8    0    1    0    1    1    1    1   11    0    0    1    0    0    1    0    0    1    0    0    1
08  03    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    2    2    3    1    0    0    1
08  04    0    0    1    0    0    1    0    0    1    0    0    1    1    1    3    3    2    3    1    1    1    0    0    1
08  05    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1
08  06    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1
08  07    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    4    6    1    0    0    1
08  08    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1   14    0    7    2    0    3    0    1    1
08  09    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    1    0    1    0    0    1
08  10    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1
08  11    0    0    1    0    0    1    0    0    1    0  109  207   34    0    1    0    0    1    0    0    1    0    0    1
08  12    0    1    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1
08  13    0    0    1    0    0    1    0    0    1    0    0    1    0    0    1    0    1   24  123   65   25   22   22   19
08  14   22   29   30   25   21   16    0    0    1   27   42    1    0    0    2   22    2    5    5    5    4    5    3    0

但是在昨晚的時候，簡直是慘淡。到後面自己都不忍看這個速度了，眯了好一會，還在慢慢的做資料匯入。
我提到了rman的影響，但是似乎客戶那邊還不是很確定是這個問題影響的。因為據他們說之前一直沒有碰到過io的問題，上一次做資料匯入的時候還是在白天，更不能說明了。

在大家都有依據，但是沒有方向的，聽聽oracle怎麼說，得到一個詳盡的addm報告，然後就可以看到裡面清晰的分析了io的一些問題，有很大一部分是由於rman導致的。
亮點是最後兩處。

Finding 8: I/O Throughput
Impact is .8 active sessions, 2.23% of total activity.
------------------------------------------------------
The throughput of the I/O subsystem was significantly lower than expected.

   Recommendation 1: Host Configuration
   Estimated benefit is .8 active sessions, 2.23% of total activity.
   -----------------------------------------------------------------
   Action
      Consider increasing the throughput of the I/O subsystem. Oracle's
      recommended solution is to stripe all data files using the SAME
      methodology. You might also need to increase the number of disks for
      better performance.
   Rationale
      During the analysis period, the average data files' I/O throughput was
      61 M per second for reads and 42 M per second for writes. The average
      response time for single block reads was 1.3 milliseconds.

   Recommendation 2: Host Configuration
   Estimated benefit is .27 active sessions, .76% of total activity.
   -----------------------------------------------------------------
   Action
      Consider slowing down RMAN or Data Pump activity, or scheduling these
      jobs when user activity is lower.
   Rationale
      The I/O throughput on data and temp files was divided as follows: 34% by
      RMAN, 0% by Data Pump, 0% by Recovery and 65% by all other activity.

   Symptoms That Led to the Finding:
   ---------------------------------
      Wait class "User I/O" was consuming significant database time.
      Impact is 12.58 active sessions, 35% of total activity.

有了這些分析，也有了一些說服力，他們開始查詢問題發生的那個時間段的一些可能影響，結果網路組的人發現從8點開始網路頻寬消耗異常的高。但是我們做資料匯入是不依賴網路的。
然後他們繼續排查，備份組發現設定了crontab，從8點開始會做備份到磁帶庫中。
問題一下子有了一種峰迴路轉的感覺。最後一定位，在結合一些相關的資料來做分析，道理就說得通了。
在有些場合中，官方的報告要好於一些主觀的資料分析。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23718752/viewspace-1251527/，如需轉載，請註明出處，否則將追究法律責任。