ERP中磁盘阵列条带的划分-针对Oracle数据库

Oracle I/O和条带阵列如何相互作用
在几乎所有的大型数据库中，对磁盘进行条带化可以增 加磁盘I/O的速率，而不会因为要管理分布在多个单独磁盘上的数据文件而增加过多的负担。正如前面讨论的那样，可以利用应用数据库服务器上的卷管理器，专 用I/O子系统，或者是两者的结合将磁盘组织成磁盘阵列。
如果使用的Oracle发布没有提供ASM，那么你 在建立条带磁盘阵列的时候，可以设置用于给磁盘加条带的块大小。块大小就是数据迁移到阵列中的另一个磁盘之前写入当前磁盘的数据量。理解不同条带的块大小 与两种大小的Oracle I/O之间的相互作用，对于将I/O性能最大化非常关键。
假设一个Oracle数据块大小为8KB，并且 DB_FILE_MULTBLOCK_READ_COUNT初始化参数设为32。那么Oracle将支持两种大小的I/O：一个单独的8KB数据块，和一 个256KB的多块读（8KB的32倍）。然后假设为Oracle配置了一个包括4个磁盘的阵列，而块大小为64KB，那么256KB的数据库将会分散到 4个磁盘中，以及每个磁盘64KB数据。
每个8KB的I/O将命中一个轴，而这8KB的数据 将会置于一个64KB的块中。由于并发的最大化，建立条带可以提高小型I/O的性能，因为每个磁盘可以服务于不同的I/O。256KB的多块I/O将命中 所有4个磁盘。如果把块大小从64KB换成256KB，那么平均每个256KB的I/O请求只命中一个磁盘。在这种情况下，多块I/O就只需要更少的I /O调用，因为磁盘上的块大小比较大。无论是哪一种情况，磁盘都将会满足单数据库I/O调用。通过把一个I/O调用分散到多个磁盘上建立条带，可以提高大 规模读操作的I/O速率，在上面的64KB块大小和256KB多块I/O的例子中已经说明了这一点。
那么什么是条带化呢？条带化（Striping）是把连续的数据分割成相同大小的数据块，把每段数据分别写入到阵列中不同磁盘上的方法。此技术非常有用，它比单个磁盘所能提供 的读写速度要快的多，当数据从第一个磁盘上传输完后，第二个磁盘就能确定下一段数据。数据条带化正在一些现代数据库和某些RAID硬件设备中得到广泛应 用。
条带化的设置
由于现在的存储技术成熟、成本降低，大多数系统都采用条带化来实现系统的IO负载分担。如果操作系统有 LVM（Logical Volume Manager逻辑卷管理器）软件或者硬件条带设备，我们就可以利用这些攻击来分布IO负载。当使用LVM或者硬件条带时，决定因素是条带深度 （stripe depth）和条带宽度（stripe width）：
条带深度指的是条带的大小，也叫条带单元；
条带宽度指的是条带深度的产量或者一个条带集中的驱动数；
需要根据系统的IO要求来 合理的选择这些数据。对于Oracle数据库系统来数，比较合理的条带深度是从256K到1M。下面分析影响条带深度和条带宽度的影响因素。
条带深度
为了提高IO效率，我们要尽量使一次逻辑IO请求由一块磁盘的一次物理IO请求。因而影响条带的一个重要因素就是一次逻辑IO 请求的大小。
此外，系统中IO的并发度不同我们对条带的配置要求也不同。例如，在高并发度且IO请求的大小都比较小的情况下，我们希望一块磁盘能同时响应多 个IO操作；而在那些存在大IO请求的低并发度系统中，我们可能就需要多块磁盘同时响应一个IO请求。无论是一个磁盘还是多个磁盘响应IO请求，我们的一 个原则是让一次逻辑IO能被一次处理完成。
下面先看下影响IO大小的操作系统和Oracle的相关参数：
db_block_size：Oracle中的数据块大小，也决定了Oracle一次单个IO请求中的数据块的大小；
db_file_multiblock_read_count： 在多数据块读时，一次读取数据块的数量，它和参数db_block_size一起决定了一次多数据块读的大小，它们的乘积不能大于操作系统的最大IO大 小，在SAP中此值是默认的，SAP的Nots中不建议改到此参数即，此参数的大小为128
操作系统的数据块大小：这个参数决定拉Redo Log和Archive Log操作时的数据块大小，对于大多数Unix系统来说，该值为512K；
最大操作系统IO大小：操作系统最大的 I/O 大小对条带化深度的设置也产生着重要的影响。当逻辑 I/O 请求达到操作系统之后，如果逻辑 I/O 的大小超过了操作系统能处理最大的 I/O 大小，操作系统会根据自己能够处理的最大的 I/O 大小来分割逻辑 I/O 请求。操作系统决定了一次单个的IO操作的IO大小的上限，
对 于HP-UX系统来说，由参数max_io_size设置；
在 AIX 中，这个参数就是 LTG，也就是当逻辑 I/O 的大小超过了所在卷组的 LTG 的设置之后，AIX 会将逻辑 I/O 以 LTG 为单位进行分割之后，才会将分割好的 I/O 请求分发到物理存储中去。所以 LTG 的大小应该与条带深度大小相同或者是条带深度大小的整数倍。在 AIX V5.3 后，卷组的 LTG 参数是在 varyonvg 的时候指定的，语法如下：
varyonvg – M 512K vgname
上 面的语句将卷组“ vgname ”的 LTG 参数设置为 512K，每次在 varyonvg 卷组的时候可以设置不同的 LTG（在 AIX5.3 之前，LTG 是在创建卷组的时候设置，并且不能修改）。目前 LTG 的取值范围为：4K、8K、16K、32K、64K、128K、1M、2M、4M、8M、16M、32M 和 128M 。而且如果卷组中 PV 不能支持 LTG 的设置 varyonvg 命令将会失败。
sort_area_size：内存中sort area的大小，也决定了并发排序操作时的IO大小；
hash_area_size：内存中hash area的大小，也决定了哈希操作的IO大小。
其中，前面两个是最关键的两个参数。
在OLTP系统中，会存在大量小的并发的IO请求。这时就需要考虑选择比较大的条带深度。使条带深度大于IO大小就称为粗粒度条带 （Coarse Grain Striping）。在高并行度系统中，条带深度为（n * db_block_size），其中n为大于1的整数。通过粗粒度条带能实现最大的IO吞吐量（一次物理IO可以同时响应多个并发的逻辑IO）。大的条带深度能够使像全表扫描那样的多数据块读操作由 一个磁盘驱动来响应，并提高多数据块读操作的性能。
在低并发度的DSS系统中，由于IO请求比较序列化，为了避免出现热点磁盘，我们需要避免逻辑IO之由一块磁盘处理。这是，粗粒度条带就不适合 了。我们选择小的条带深度，使一个逻辑IO分布到多个磁盘上，从而实现IO的负载均衡。这就叫细粒度条带。条带深度的大小为（n * db_block_size），其中n为小于多数据块读参数（db_file_multiblock_read_count）大小的整数。
另外，IO过程中，你无法保证Oracle数据块的边界能和条带单元的大小对齐。如果条带深度大小和Oracle数据块大小完全相同，而它们 的边界没有对齐的话，那么就会存在大量一个单独的IO请求被两块磁盘来完成。
在OLTP系统中，为了避免一个逻辑IO请求被多个物理IO操作完成，条带宽度就需要设置为两倍或者两倍以上于Oracle数据块大小。例如， 如果条带深度是IO大小的N倍，对于大量并发IO请求，我们可以保证最少有（N-1）/ N的请求是由一块磁盘来完成。
条带宽度
正如我们前面所述，无论是一个还是多个磁盘响应一个逻辑IO，我们都要求IO能被一次处理。因而在确定了条带深度的基础上， 我们需要保证条带宽度 >= IO请求的大小 / 条带深度。
此外，考虑到以后系统容量的扩充，我们也需要规划好条带宽度。
如今大多数LVM都支持在线动态增加磁盘。也就是在磁盘容量不足时，我们可以随时将新磁盘加入到一个已经使用的逻辑卷中。这样的话，我们在设置 逻辑卷时就可以简单地将所有磁盘都归入到一个卷中去。