2、I/O配置：


2.1、条带化的设置
如果os有LVM（Logical Volume Manager 逻辑卷管理器） 软件或者硬件条带设备，我们就可以利用这些攻击来分布IO负载。
当使用LVM或者硬件条带时，决定因素是条带深度（stripe depth)和条带宽度(stripe width):


条带深度：条带的大小，也叫条带单元
条带宽度：条带深度的产量或者一个条带集中的驱动数


对于Oracle数据库系统来数，比较合理的条带深度是从256K到1M。


2.1.1 条带深度


影响IO大小的os和Oracle的相关参数：
（1）db_block_size:Oracle中的数据块大小，也决定了Oracle一次单个IO请求中的数据块的大小
（2）db_file_multiblock_read_count:在多数据块读时，一次读取数据块的数量，它和参数db_block_size一起决定了一次多数据块读的大小，
它们的乘积不能大于os的最大IO大小。
（3）os的数据块大小：这个参数决定了Redo Log和Archive log操作时的数据块大小，对于大多数Unix系统来说，该值为512K
（4）最大osIO大小：决定了一次单个的IO操作的IO大小的上限，对于大多数Unix系统来说，由参数max_io_size设置
（5）sort_area_size:内存中sort area的大小，也决定了并发排序操作时的IO大小
（6）hash_area_size:内存中hash area 的大小，也决定了哈希操作的IO大小
其中，前面两个是最关键的两个参数。




在OLTP系统中，会存在大量小的并发的IO请求，这时就需要考虑选择比较大的条带深度。
使条带深度大于IO大小就称为粗粒度条带（Coarse Grain Striping).
在高并行度系统中，条带深度为（n*db_block_size)，其中n为大于1的整数。


在低并发度的DSS系统中，由于IO请求比较序列化，为了避免出现热点磁盘，我们需要避免逻辑IO之由一块磁盘处理。
我们选择小的条带深度，使一个逻辑IO分布到多个磁盘上，从而实现IO的负载均衡。
这个叫细粒度条带。
条带深度的大小为(n*db_block_size),其中n为小于多数据块读参数（db_file_multiblock_read_count)大小的整数。


在OLTP系统中，为了避免一个逻辑IO请求被多个物理IO操作完成，条带宽度就 设置为两倍或者两倍以上于Oracle数据块大小。
例如，如果条带深度是IO大小的N倍，对于大量并发IO请求，我们可以保证最少有（N-1）/N的请求是由一块磁盘来完成。




2.1.2、条带宽度


条带宽度>=IO请求的大小/条带深度


2.1.3、人工条带
有许多DBA会将那些使用频率非常高的表和它的索引分开存储。
但是实际上这种做法并不正确。
在一个事务中，索引会先被读取到然后再读取表，它们的IO操作是有前后顺序的，因此索引和表存储在同一磁盘上是没有冲突的。


为了正确分布文件，我们首先必须先了解各个数据库文件的IO负载需求以及IO系统的处理能力，鉴定出每个文件的IO吞吐量，找出哪些文件的IO吞吐率最高而哪些IO量很少，将它们分散分布到所有磁盘上去以平衡IO吞吐率。




2.2、文件分离


除了IO吞吐率，在决定是否分割文件时，我们还需要考虑可恢复性以及数据容量扩张问题。
但是在分割文件之前，一定要确认存在IO瓶颈，然后再根据产生IO瓶颈的数据定位到存在高IO吞吐率的文件（热点文件）。


2.3、表、索引、临时表空间
（1）如果具有高IO吞吐率的数据文件属于包含表和索引的空间，我们就需要找出这些文件的iO是否可以通过SQL语句调优或者优化应用程序来降低。
（2）如果属于临时表空间，我们就需要检查是否可以通过避免或者调优SQL的排序操作来降低IO
（3）经过应用调优后，如果IO分布仍然无法满足IO吞吐的要求，我们就需要考虑分离高IO吞吐率的数据文件了。


2.4、Redo Log文件
如果具有高IO吞吐率的文件是Redo Log文件，则需要考虑将Redo Log文件与其他文件分离，可以通过以下配置来实现：
（1）将所有Redo Log文件放到没有任何其他文件的磁盘上去，考虑到可恢复性，需要将一个Redo Log组中的成员文件分别放到不同的物理磁盘上去。
（2）将每一个Redo Log组放到一个没有任何其他文件的单独磁盘上
（3）通过os条带化工具，将Redo Log文件条带化分布到多个磁盘上去
（4）不要将Redo Log文件放到RAID 5上去


Redo Log文件是由LGWR进程序列化的写入的。如果在同一个磁盘上不存在并发的其他IO操作，写入效率就更高。
我们需要确认已经没有其他优化调整空间再考虑分割Redo Log文件，如果系统支持AIO但还没有激活该特性，可以考虑激活AIO看是否能够解决Redo Log性能瓶颈。


2.5、归档Redo Log
如果归档变慢，我么也许可以通过使LGWR的写操作与Archive进程的读操作分离来避免LGWR进程与Archive进程直接的IO冲突。
我们可以同交替成存放Redo Log文件来实现。
例如，我们有四组Redo Log，每组包含两个Log文件：（A1，A2）、（B1，B2）、（C1、C2）、（D1，D2）。
我们就可以以下面这种存放方式将它们分布存储到四个磁盘上去来实现磁盘分离访问：（A1，C1）、（A2，C2）、（B1，D1）、（B2，D2）。


当LGWR进程做日志切换时，如从A组切换到B组，LGWR开始向B组写Redo Log（第三、四块磁盘），而Archive进程则从B组读取数据（第一、二块磁盘）写入归档文件中去，他们分别访问的是不同磁盘，因为避免了IO冲突。


2.6、三种简单的配置方法
（1）将所有文件条带化到所有磁盘上去
IO配置最简单的方法就是建立一个大的逻辑卷，将所有磁盘都条带化到这个卷中去。考虑到可恢复性，这个卷需要被镜像（RAID1）。
每个磁盘的条带深度必须大于频繁执行的IO操作的最大IO大小。
（2）将归档日志放到另外的磁盘上去
在归档模式下，如果归档文件也和其他文件放在同一个条带化的卷中，那么当归档进程对Redo Log进行归档时，会大大增加磁盘的IO负载。
将归档日志转移到其他磁盘上有如下好处：
a）归档进程效率提高
b）当归档时，其他进程不受到归档进程的影响


归档日志的磁盘数由归档日志产生的频率以及归档存储容量决定。


（3）将Redo Log文件放到另外的磁盘上去
在更新非常频繁的OLTp系统中，Redo Log的写操作非常频繁。将Redo Log文件转移到其他磁盘上可以有如下好处：
a）写Redo Log的读写效率最高，因而事务的执行也能获得最佳性能。
b）写Redo Log操作不会影响任何其他IO操作


Redo Log的磁盘数量有Redo Log的大小决定。由于现在的磁盘容量都非常大，通常配置两个磁盘（如果做镜像则需要四块）就足够了，并且，根据我们前面的分析，将Redo Log文件交互的存放到两块磁盘上去能避免LGWR进程的写操作与ARCH进程读操作之间的IO冲突。