昨晚在做測試環境資料遷移的時候，遇到了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.
Consider slowing down RMAN or Data Pump activity, or scheduling these
jobs when user activity is lower.
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點開始會做備份到錄音帶庫中。
問題一下子有了一種峰回路轉的感覺。最後一定位，在結合一些相關的資料來做分析，道理就說得通了。
在有些場合中，官方的報告要好于一些主觀的資料分析。
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)