针对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存在问题。