    被一個問題困惑了n久，終於有點眉目了，但是還不確定最後的原因，希望在這方面有經驗的朋友能幫忙看看，我的推測是否正確。

1. 問題描述
   大概20G左右的dmp檔案，做imp：
   一臺windows的機器
                   (只有2個盤)（很老的機器）
                   imp需要2:30小時
   一臺Linux 64位的機器 Linux 2.6.9-67.ELlargesmp
                   8快硬碟，做raid1+0
                   imp卻需要4-5個小時。
   2個資料庫都是noarchivelog的。

2. 故障排除思路
   1.增加redo log
     在linux做imp的時候，發現v$log中的status總是為1個current和多個active，考慮會不會是oracle再等待redo log的寫，所以加大成員和組數。
     現在linux的redo log每組的大小和組數都>>(遠遠大於)windows的機器。但是速度快了一些，可還是不如windows的機器（鬱悶）。

   2.懷疑磁碟IO負載
     做imp時，iostat取樣

     [root@ntkdb oradata]# iostat -x 1 10
     Linux 2.6.9-67.ELlargesmp (ntkdb) 07/15/2009

     avg-cpu: %user   %nice    %sys %iowait   %idle
                0.00    0.00    0.00    6.25   93.75

     Device:    rrqm/s wrqm/s   r/s   w/s rsec/s wsec/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await svctm %util
     cciss/c0d0   0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     cciss/c0d1   0.00 162.00 0.00 162.00    0.00 2592.00     0.00 1296.00    16.00     0.99    6.12   6.12 99.10
     cciss/c0d2   0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     cciss/c0d3   0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-0         0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-1         0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-2         0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-3         0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-4         0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-5         0.00   0.00 0.00 0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
     dm-6         0.00   0.00 0.00 324.00    0.00 2592.00     0.00 1296.00     8.00     1.98    6.11   3.06 99.10

     備註：
     rrqm/s:   每秒進行 merge 的讀運算元目。即 delta(rmerge)/s
     wrqm/s:   每秒進行 merge 的寫運算元目。即 delta(wmerge)/s
     r/s:      每秒完成的讀 I/O 裝置次數。即 delta(rio)/s
     w/s:      每秒完成的寫 I/O 裝置次數。即 delta(wio)/s
     rsec/s:   每秒讀扇區數。即 delta(rsect)/s
     wsec/s:   每秒寫扇區數。即 delta(wsect)/s
     rkB/s:    每秒讀K位元組數。是 rsect/s 的一半，因為每扇區大小為512位元組。(需要計算)
     wkB/s:    每秒寫K位元組數。是 wsect/s 的一半。(需要計算)
     avgrq-sz: 平均每次裝置I/O操作的資料大小 (扇區)。delta(rsect+wsect)/delta(rio+wio)
     avgqu-sz: 平均I/O佇列長度。即 delta(aveq)/s/1000 (因為aveq的單位為毫秒)。
     await:    平均每次裝置I/O操作的等待時間 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
     svctm:    平均每次裝置I/O操作的服務時間 (毫秒)。即 delta(use)/delta(rio+wio)
     %util:    一秒中有百分之多少的時間用於 I/O 操作，或者說一秒中有多少時間 I/O 佇列是非空的。即 delta(use)/s/1000 (因為use的單位為毫秒)

     如果 %util 接近 100%，說明產生的I/O請求太多，I/O系統已經滿負荷，該磁碟可能存在瓶頸。
     cciss/c0d1明顯看出i/o負載過重。估計是資料檔案劃分的不合理。

     當初規劃的時候，是這樣考慮的。

     a. vgdisplay
     [root@ntkdb oradata]# vgdisplay -s
       "VolGroup03" 136.69 GB [97.78 GB used / 38.91 GB free]
       "VolGroup02" 136.69 GB [58.59 GB used / 78.09 GB free]
       "VolGroup01" 136.69 GB [117.19 GB used / 19.50 GB free]
       "VolGroup00" 136.56 GB [73.28 GB used / 63.28 GB free]

     b. bdf
     [root@ntkdb oradata]# df -k
     Filesystem           1K-blocks      Used Available Use% Mounted on
     /dev/mapper/VolGroup00-LogVol00
                           30254032   9830088 18887128 35% /
     /dev/cciss/c0d0p1       101086     14733     81134 16% /boot
     none                   8205024         0   8205024   0% /dev/shm
     /dev/mapper/VolGroup00-orainstall(ORACLE_BASE 目錄，包括redo log 檔案)
                           30254032   3886328 24830888 14% /u01/orainstall
     /dev/mapper/VolGroup01-oradata(資料檔案)
                           60475476 54322692   3080784 95% /u02/oradata
     /dev/mapper/VolGroup02-oraindex(index)
                           60475476 49441188   7962288 87% /u02/oraindex
     /dev/mapper/VolGroup03-orabackup(存放其他檔案)
                          100920744 22308440 73485752 24% /u03/orabackup
     /dev/mapper/VolGroup01-oradata02(擴充的資料檔案)
                           60475476 46210964 11192512 81% /u03/oradata

     但是我們明顯看到了磁碟的IO全部聚集到了cciss/c0d1 --》VolGroup01上，明顯是當初考慮劃分lv的時候，沒有考慮分散磁碟io的問題。
     初步查明原因，想把/dev/mapper/VolGroup01-oradata02下的資料檔案挪到 /dev/mapper/VolGroup03-orabackup下，是24小時的測試環境，如果有機會的話，我試一下移動資料檔案，看看磁碟io的問題是不是得到了緩解，imp是否可以縮短時間。
[root@ntkdb oradata]# dmsetup ls
VolGroup01-oradata02 (253, 6)
VolGroup01-oradata (253, 5)
VolGroup03-orabackup (253, 3)
VolGroup00-orainstall (253, 2)
VolGroup00-LogVol01 (253, 1)
VolGroup00-LogVol00 (253, 0)
VolGroup02-oraindex (253, 4)

[root@ntkdb oradata]# hdparm -t /dev/cciss/c0d0
/dev/cciss/c0d0:
Timing buffered disk reads: 236 MB in 3.02 seconds = 78.11 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

[root@ntkdb oradata]# hdparm -t /dev/cciss/c0d1
/dev/cciss/c0d1:
Timing buffered disk reads: 256 MB in 3.01 seconds = 84.98 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device

參考文獻：
        1.

        2.

iostat -x 1 10

相關文章