針對oracle性能的io調優(摘自老白-一個金牌DBA的故事)

關於io調優
   在海量數據的狀況下，數據庫的性能問題有80%以上和IO有關，所以I/O優化是貫穿海量數據庫管理全過程的重要工做。
I/O優化牽涉的面比較廣，如今就從Oracle 數據庫優化的一些主要方面詳細闡述一下。在海量數據庫環境下，Oracle數據庫優化
    面臨的最重要的任務是I/O優化，由於絕大多數大型數據庫都或多或少存在I/O性能問題。
數據庫的I/O性能涉及面十分廣，所以I/O性能優化也是ORACLE數據庫優化工做中最複雜的工做。進行I/O性能優化，基本的步驟是
這樣的:
採集系統數據，定位I/O性能問題；
分析並制訂解決方案；
調整系統，解決問題；
評估優化結果。
  優化ORACLE數據庫的I/O性能，不能簡單地從I/O入手，須要遵循數據庫優化工做的基本原則。首先數據庫優化的目的是提升系統的
總體處理能力，提升事務響應速度。全部的優化工做都須要圍繞這個目的來進行。數據庫性能優化的手段有兩個方面，一是減小處理
時間，二是減小等待事件。減小處理時間要求應用編寫得高效合理。減小等待時間要求系統的各類資源合理分配，不出現任何瓶頸。
數據庫使用的系統資源包括CPU、內存、存儲和網絡。數據庫優化的目的是合理分配這些資源，確保任何一種資源都不出現瓶頸。
  根據上述原則，Oracle數據庫的I/O性能優化不能只經過從新組合系統資源來達到提高數據庫整體性能（包括I/O性能）的目的。
另外一個方面，在優化I/O時也要考慮到其餘資源的狀況。
  若是I/O單方面提高致使其餘資源出現瓶頸，那麼也會致使系統整體性能降低。特別是針對資源有限的系統的優化，如何有效利用
不足的系統資源進行最優化的組合，在保證沒有一種資源過載的狀況下儘量利用資源，是系統優化的關鍵。
  如何肯定系統的主要問題是I/O問題，並進一步定位I/O問題的根本緣由是解決Oracle I/O性能問題的關鍵。I/O性能不佳，多是多
方面的問題。進行優化的第一步就是肯定關鍵的性能瓶頸。

   影響ORACLE數據庫I/O性能的問題覆蓋面十分廣，根據做者多年從事Oracle數據庫管理的經驗，下面幾個方面是影像數據庫I/O性能的
主要問題.
  存儲性能瓶頸:控制器不足、cache偏小，Cache設置不合理、I/O通道容量不足等。
  磁盤性能瓶頸：磁盤數量過少、使用了速度比較低的磁盤等
  使用了不合理的RAID模式。
  在使用RAID的狀況下，存在I/O熱點，多個熱點文件使用同一個磁盤。
  異步I/O配置不正確
  數據庫各類緩衝區設置不合理，緩衝命中率太低
  PGA的各類緩存設置太小，（對於Oracle 9i，在使用自動管理模式的狀況下，PGA設置太小），致使大量的臨時表空間操做
  重作日誌存在性能瓶頸
  重作緩衝區設置不合理
  存在熱點數據
  表空間碎片嚴重
  表和索引的存儲參數不合理
  行遷移比較嚴重
  存在大量大表掃描的SQL
  SQL執行選擇了很差的執行計劃

  當系統出現I/O問題時，數據庫管理員最大的挑戰是如何儘快找到問題的最根本緣由。I/O問題的調整是十分複雜的，在沒有找到根本緣由
以前進行調整每每沒法達到最終的優化目標。須要注意的是I/O問題每每和大型的SQL語句有關。若是某個系統忽然發生I/O性能問題，第一步須要
排除一切I/O以外的問題。
  肯定I/O性能瓶頸的存在，並定位存在I/O性能瓶頸的設備是解決I/O性能問題的第一步。使用操做系統的監控工具能夠實時監控I/O的狀況。第一種
方法是使用vmstat工具。使用該工具，能夠查看b列的值，若是該值比較高，那麼說明等待I/O的進程比較多，I/O可能存在問題:

$vmstat 1  10
     procs             memory
r    b    w          avm    free
2    12   0     14572705   92752
2    12   0     14572705   93548
2    12   0     14572705   92910
2    12   0     14572705   93467
2    12   0     14572705   93546
2    12   0     14572705   93864
2    12   0     14572705   94557
2    12   0     14572705   93952
2    12   0     14572705   94017
2    12   0     14572705   93047

若是上述命令發現b比較大，那麼說明可能存在I/O等待的現象，經過sar命令或者iostat命令能夠進一步確認。若是用sar 命令監控時發現
wio 比較大（好比超過40，這個值是經驗值，根據不一樣的系統，這個值能夠調整）,那麼基本能夠肯定存在I/O性能瓶頸，以下所示

$sar 1  10
HP-UX cuyn16  B.11.11 U 9000/800
15:01:44      %usr       %sys        %wio        %idle
15:01:45        16          3          57           24
15:01:45        15          2          59           19
15:01:45        21          3          57           16
15:01:45        20          2          63           14
15:01:45        17          2          67           12
15:01:45        12          1          75           7
15:01:45        16          2          75           5
15:01:45        10          1          84           1
15:01:45        18          2          79           6

若是發現wio值長時間高於40，那麼說明I/O等待比較嚴重。此時能夠經過sar -d 命令來監控，看看哪些I/O設備存在性能問題
。若是發現某個設備的繁忙度長時間超過90%，就說明該設備比較繁忙。若是該設備的avserve 比較大或者比其餘設備高不少，
就說明該設備存在性能問題。好比下面的例子:

15:02:01      device     %busy     avque     r+w/s      blks/s     avwait     avserv
Average      c0t0d0        2.00     0.50         6          27      3.62        6.03
Average      c3t8d0        1.10     0.50         4          16      3.23        5.69
Average     c55t0d5       99.40     0.50        18          73      5.41       54.50
Average     c55t1d0        4.20     0.50         5          15      5.39        8.49
Average     c55t1d1       79.52     0.76        24         810      9.09       81.99
Average    c55t11d0       68.33     0.52        23        2909      5.60       72.40
Average    c55t11d2       31.07     1.14        25        1630     10.95       28.05
Average    c55t11d3       16.98     0.51        22        3075      5.24       13.39
Average    c55t11d5       71.83     2.59        26        1643     42.18       82.78
Average    c55t11d6       76.12     0.50        23        3012      5.58       76.47
Average    c55t12d0       30.57     1.02        26        1637     10.86       30.59
Average    c55t12d1       21.48     0.50        20        2826      5.12       19.55
Average    c55t12d3       80.72     2.74        29        1880     42.78       84.38
Average    c55t12d4       70.03     0.52        23        2887      5.83       66.85
Average    c55t14d1      100.00    54.57       104        6630   1315.98       71.54
Average    c55t13d1       77.72     0.55        19         297      5.79       80.19

從上面的數據能夠看出，部分設備(好比C55t14d1)的等待事件比較長，而且avwait+avserv的時間比較長，說明該設備存在
性能瓶頸。而大部分HDISK的avwait+avserv還比較正常，這說明存儲系統並不存在廣泛性的性能瓶頸，而性能瓶頸主要集中在
熱點盤組上。

經過Oracle的STACSPACK工具也能夠檢查系統的I/O問題。若是系統的性能不佳，而且可從報告中看到的sequential read等待
事件是系統等待事件中排在前幾位的事件，佔系統總等待時間的比例比較高，那麼系統極可能存在I/O性能問題。能夠經過檢查
文件I/O狀況來進一步確認並找出存在性能問題的設備。方法是經過檢查文件I/O的平均讀響應時間。若是某個文件的平均讀響應
時間超過20ms，那麼說明該文件所屬的文件系統可能存在性能問題。應該注意的是，20ms是一個相對參數，在不一樣的應用環境下
該值可能會有所不一樣。經過比對操做系統的狀況，數據庫管理員應該很快就能肯定你所管理的系統的平均讀響應時間和操做系統
I/O狀況的對應關係。

檢查讀平均響應時間時還要注意幾個問題。第一個問題是在報告時間區域內的I/O量，若是某個文件在報告時間區間內的I/O數量很小，
那麼此平均響應時間可能缺少表明性，能夠經過檢查存放在相同設備上的其餘文件來進一步確認。另一種狀況是平均每次讀的
數據量比較多（每次讀的塊數比較多),那麼略高的平均讀響應時間也是正常的。下面的數據就是從I/O存在問題的數據庫上取下的
STATSPACK數據:
Top 5  Timed Events
------------------------
Event                                          waits               Time（s)        %Total Ela Time
--------------------------------------------------------------------------------------------------
db file sequential read                        661,802           45,404                    60.79
SQL*Net more data from dblink                 3180,371            7,894                    10.57
CPU time                                                          5,077                     6.80
db file scattered read                          56,959            3,846                     5.15
buffer busy  waits                              42,376            2,541                     3.40

能夠看出，db file sequential read 是等待事件中的第一位事件，佔整個等待事件的60%以上，而且每次平均等待的市建委
69ms.這是一個典型的I/O存在性能瓶頸的例子，經過STATSPACK 報告文件I/O性能分析數據，能夠進一步檢查到底哪些文件
出現了問題:
INDEX_SPACE_OTHER                  /dev/vg10xp/rls_2g_vol05
         9,171            2        52.2        1.0    7,911
                                   /dev/vg10xp/rls_2g_vol106
         8,016            2        22.8        1.0    8,292
                                   /dev/vg10xp/rls_2g_vol107
         7,567            2         9.8        1.0    8,058
                                   /dev/vg10xp/rls_2g_vol108
         5,456            1        46.7        1.0    6.180
                                   /dev/vg10xp/rls_2g_vol109
         5,925            2        57.3        1.0    6,265
                                   /dev/vg10xp/rls_2g_vol110
        10,462            3       147.7        1.0    6,867
                                   /dev/vg10xp/rls_2g_vol111
         6,071            2       130.0        1.0    5,638
                                   /dev/vg10xp/rls_2g_vol112
        15,624            4       226.9        1.0   15,736
                                   /dev/vg10xp/rls_2g_vol112
        14,421            4       206.2        1.0   17.136
                                   /dev/vg10xp/rls_2g_vol112
        13,677            4       229.9        1.0   11.828
    ...

   能夠看出/dev/vg10xp 上部分文件的平均讀相應時間超過了200ms，存在嚴重的性能問題。經過驗證，/dev/vg10xp是c55t14d1上的邏輯卷。

STATSPACK 報告之I/O問題分析

I/O性能分析是STATSPACK 分析中的重要部分。對於I/O的分析能夠基於兩個方面，第一個方面是在Wait Events for DB中，好比下面的數據
                                                                              Avg
                                                            Total wait        wait            waits
Events                            waits      Timeouts          time（s)        (ms)              /txn
db file sequential             13,409,809           0           424,347         29              93.6
SQL*NET more data to client     1,187,633           0             8,024          7               7.7
buffer busy waits                 212,482           0             5,888         28               1.4
db file scatter read              143,778           0             3,154         22               0.9
從上面看，db file sequential read(29ms) 和 db file scatter read(22ms) 的等待時間都很高，說明I/O存在明顯的性能
問題。對於不一樣的系統，這些值的正常範圍都不大相同，能夠經過長期的積累，造成基線數據。不過，通常來講超過10ms就應該關注
了，超過20ms，I/O子系統就可能存在問題了。從本例來講，系統的I/O性能存在必定的問題。爲了肯定猜想，能夠進一步檢查文件I/O
詳細信息:

File IO Stats DB:HSCP Instance :hcsp Snaps :21 - 33
->ordered by Tablespace,File

Tablespace                         Filename
-----------------------   -----------------------------------------------------------------------
                     Av          Av      Av                           Av              BUFFER     Av  Buf
     Reads        Reads/s     Rd(ms)   Blks/Rd           Writes   Writes/s              Waits      Wt(ms)
-------------    -------     ------   -------    -------------   --------       ------------   ---------
   HAIER_TEST_DATA              /dev/vgrac/rhaier_test_data02
      132            0        163.6     2.5               65        0                   0
   HCSP_AI_DATA                 /dev/vgrac/rHCSP_AI_DATA_01
        1,363            0         19.1     1.0            1,349        0                  0
   HCSP_AI_INDEX                /dev/vgrac/rHCSP_AI_INDEX_01
        4,649            1         17.5     1.0            3.614        0                  2          0.0
   HCSP_BASE_DATA               /dev/vgrac/rhcsp_base_data01
      329,857           38         14.3     2.8          77,415         9              33,510         11.2
   HCSP_BASE_INDX               /dev/vgrac/rhscp_base_index01          
       72,577            8         14.7     1.0             419         0                 111          3.2
   HCSP_COMM_DATA               /dev/vgrac/rhcsp_comm_data01
       7,789             1        112.1     2.7             692         0               3,884          87.5

  從上面的數據能夠看出，大多數的文件訪問的平均讀響應時間都超過20ms.基本上咱們能夠得出結論，系統的I/O存在問題。