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

　　手工分布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系统的索引，因为很容易产生索引叶子块的相互竞争。