确保分条大小与操作系统和数据库的数据块大小一致

在具体实现RAID 0、RAID 5或者基于软件分条时，正确地决定最佳的分条结构 ( s t r i p )大
小非常关键。在决定分条大小时，有3个因素必须考虑：
* 主要应用程序（O LT P或者D S S）的内在特性。
* 操作系统与数据库的数据块大小。
* 分条列（磁盘阵列）中的硬盘数目。
几乎每一本D B A手册都会说明保证数据库的数据块大小是操作系统数据块大小倍数的重
要性（笔者也赞成这种观点，请参见第 7章）。因此，笔者在这里将假设用户可以很方便地读
取数据，并且用户操作系统的数据块大小与数据库的数据块大小兼容。这个规则同样也适用
于所有分条集合中的分条大小：也就是说，分条大小必须是操作系统数据块大小的整数倍。
如果使用的是原始设备，那么就可以仅仅考虑操作系统的物理数据块大小。 U N I X系统中的物
理数据块大小是5 1 2字节，在使用Logical Volume Manager(LV M )时，操作系统的逻辑数据块
大小将覆盖操作系统的物理数据块大小。在 LV M中，逻辑数据块的缺省大小为 8 K B。这也许
不是一个大问题，因为 5 1 2字节与8 K B很容易整除通常使用的 s t r i p大小（6 4 K B、1 2 8 K B、
2 5 6 K B、5 1 2 K B等等）。因此，在这方面出问题的可能性不大。实际上，上面列出的第三个因
素才是大多数人需要进行深入考虑的。
分条可以按照水平方向（跨越每个硬盘控制器）进行，也可以按照垂直的方向（跨越硬
盘集合）进行。通常，对硬盘进行分条动作的目的是为了使用多个硬盘控制器以便达到对数
据的并行访问，因此必须考虑系统中可用的硬盘控制器数目以及每个分条集合中的成员数目。
下面将假设系统中有四个硬盘控制器可供使用，并且每个分条集合中有四个成员（通常，不
应该使得分条集合中的成员数目多于系统中可用的硬盘控制器数目，否则将会不能很好地实
现进行硬盘分条的目标，这个目标就是将数据分散到系统中可用的多个资源上，以便实现数
据的并发访问）。如果假设操作系统与数据库的数据块大小都是 8 K B，那么系统为了实现对四
个分条集合的并行访问，那么每次就应该至少读写 3 2 K B（8 K B×4个硬盘控制器）的数据。
在这里，需要假设这个容量的数据为当前被处理的流量，而在任何多用户环境中，这并不是
一种很好的方法。但是，上面给出的这个简单例子说明了在这种环境下，既使是系统需要进
行触发并行访问的操作企图，也必须要求进行 3 2 K B分条大小的数据交换。这样，对于少量信
息的访问请求将不能达到访问时间的优化。而在 O LT P环境下，数据访问请求中的数据块大小一般都比较小（只有少数大于 3 2 K B的）。在D S S应用程序中，数据访问请求中的数据块大小
一般都比较大，从而必须保证有较大的分条大小。关于数据库数据块大小与最佳分条大小
（基于每个分条集合中的硬盘数目）之间的关系