【赛迪网－it技术报道】很多人都知道，oracle io子系统是数据库中一个非常重要的组成部分。 由于很多软件系统的瓶颈都是由disk io引起的，系统花费了大量的cpu_times用于等待i/o行为的完成。

在我们设计数据库的io子系统的时候，应该考虑以下因素：

■ 存储，最小的磁盘容量

■ 可用性，诸如(24 x 7) 不间断的服务

■ 性能，诸如i/o的吞吐量和系统响应时间

基本的io设计

使用操作系统或者硬件来条带化文件存储，如果你的操作系统有类似lvm和硬件striping,的化，那么使用它们来尽可能的分散io。在striping中，要考虑两个要素：stripe width 和stripe depth

■ stripe depth 指的stripe的大小,也被称为stripe unit。

■ stripe width 指的stripe depth 和 stripe设定中驱动器的数目的乘积。

在oracle数据库中，一个合理的stripe depths 应该在256kb到1m。不同类型的应用需要不同stripe depth，最理想的stripe depth 和 stripe width应该考虑以下：

■ i/o请求的大小

■ 同时发生i/o

■ physical stripe boundaries 和 block size boundaries

■ manageability of the proposed system

i/o请求的大小

下面是在配置i/o会用db和os参数：

db_block_size：单块i/o请求的大小，也被用于诊断多块i/o请求。

os block size：操作系统块的大小

maximum os i/o size：os能提供的最大单块i/o的大小

db_file_multiblock_read_count：它和db_block_size的积用于计算全表扫描最大i/o，注意能超过os限制。默认为8。

sort_area_size：排序操作需要的i/o大小

hash_area_size：hash操作需要的i/o大小

出了i/o大小外，并发度也决定了stripe的depth。在选择stripe width和stripe depth的时候请考虑以下因素：

■在低并发的系统中，确保在同一磁盘上不会发生重复单一的i/o。这是什么意思呢？例如，假设stripe width有4个磁盘，stripe depth

是32kb，这时候oracle server process发出一个1mb的i/o请求，那么每个磁盘都会返回8次i/o请求。为了尽量避免这种情况，平均i/o请求的大小应该小于stripe width×stripe depth，在这里是32kb×4，否则就会在一个磁盘发生第二次i/o。

这是完全理想化的设计。

■在高并发的系统中，要确保单一的i/o请求会被分散到多个物理i/o中完成，如果不行，则会严重的影响系统响应时间。

并发的i/o

在oltp系统中，特点是高并发和低i/o需求，这时最好stripe depth大于一个单独i/o的大小，这种被称为粗颗粒stripe。

在高并发的系统中，一般stripe depth设计为n×db_block_size,n>1.

粗颗粒stripe设计使得磁盘可以以队列的方式同时执行多个i/o，这样就可以以最小的成本处理大量的并发i/o。不过，一旦系统不具备并发足够并发，就会导致磁盘热点。

粗颗粒stripe设计也同样有益于dss系统，但它应该设计得小一点，同样它大小也为n×db_block_size，但n应该小于db_file_multiblock_read_count。

而细颗粒设计能够获得最好的响应时间。

alignment of physical stripe boundaries with block size boundaries

如果物理stripe颗粒和块大小一致的化，就可能会导致一个单独i/o分散到两个物理io中。这不是最优化的oltp环境，所以stripe最好是两倍block的大小。下面是关于大小的建议：

random reads and writes 两倍block大小

sequential reads 两倍db_file_multiblock_read_count×db_block_size

manageability of the proposed system

使用lvm可以更加容易配置所有可用磁盘的stripe，在大多数环境下，单卷就可以提供良好的性能。不过单卷只在使用raid技术的时候可用，如raid 1，不过丢失一个卷卷意味着丢失所有卷。

除了了性能以外，还有一个问题要考虑，那就是数据的增加要容易扩展。

手工分布i/o

如果你的系统不能做stripe，那么你就要手工配置你文件来达到尽量均匀分布i/o的目的。

1.检查磁盘和文件的大小，估计数据库的存储需求

2.为每个文件预估i/o，分辨出高i/o和低i/o的文件，将它们分布到磁盘组中。

这里存在一个误解，就是把index和data分开，这是不恰当的。因为在一个事务的过程中，是先访问索引，再访问表，它们是有序的，所以在同一磁盘中是没有竞争的。这个是很多人都曾经误解的，包括我。

什么时候需要分割文件

这个问题很简单，当i/o需求已经不能被满足的时候，将可能需要分割文件。

i/o热点一般发生在table、index或者temp tablespace,造成i/o过高的大多数原因是由于sql，这个时候需要做sql tuning。其它：

redo log file如果发生很高的i/o，考虑把它们单独放置到一个磁盘，或者分布到几个磁盘，这样还可以提高可用性。

stripe它们的存储环境。避免使用raid5。

archived redo log，如果归档慢，则要考虑归档进程和lgwr的竞争。

建议

stripe所有的磁盘

移动归档文件到不同的磁盘

移动在线日志到单独的磁盘

使用oracle管理文件可以获得更多益处。

最后，讲一讲数据块大小的选择。

8k是适合于大多是系统的，但是有时候oltp系统使用更小，dss使用更大的数据块可以提供更优的性能。

reads

如何行比较小，访问比较随机，选择较小的块

如果行比较小，访问是连续的，选择较大的块

如果行比较小，访问情况复杂，尽量选择较大的块

如果行比较大，包含诸如lob类型的字段，那么选择较大块writes

在一个高并发的oltp系统中，使用一个大块，那么要慎重的考虑initrans,

maxtrans, 和freelists设置。这些参数影响到一个块的并发更新率。不过，如果你使用自动段空间管理，则不用考虑freelists。如果你还是不能确定块的大小，那么就使用8k，如果你大量使用lob类型，那么就可以大于8k。

小结：一般来说，小块减少锁竞争，适合随机访问，但是元数据管理需要很大的头空间，不适合大行，容易产生行链。大块，可以存储更多的数据，减少管理开销，适合连续的访问和存储lob类型，但是浪费空间大，不适合存储oltp系统的索引，因为很容易产生索引叶子块的相互竞争。