对于超大表的扫描，一般倾向于使用Parallel，让多个slave进程扫描，返回完整的结果集，ORACLE里面并行是可以手工模拟的，通过表的盘区分布，我们可以获得表的rowid的分布范围，然后启动多个会话，每个会话处理一个范围，如果表的盘区分布在多个磁盘上，CPU个数也允许的情况下，效果是非常好的，但是这种基于rowid范围搜索的机制，是不太适合用stripe的
       
        比如一个表空间有4个datafile,存储正好是4个DISK组成的stripe,stripe size 为128K，那么这4个datafile 创建的时候就注定了以128K的分片散落在4个disk上，然后在表空间上创建表，假设是uniform的让盘区均衡在4个datafile，实际上他的单个extent也是跟随这他的datafile落在了4块DISK上，此时如果使用Parallel，多个slave进行rowid范围扫描来返回数据，逻辑上看到的从表的block1扫描到blockn是连续的，但硬件磁盘却是4个磁头在疯狂的交叉使用，每个slave都要4个磁头为他工作，为了真正的让多磁盘为Parallel服务，就要尽量的保证数据文件上的block在物理磁盘上是尽量连续的，每个磁盘上分一个大的范围，这样多进程扫描起来，每个关注自己的那个磁头，避免交叉调用，才是最优的
        马上就要接手数据仓库了，管理的数据库从G变T，心里到真是有些惶惶的，以后关于大数据量的迁移，处理肯定不少，又是一个新的挑战

• 

  存储设备里面又有 stripe ，所以你在这里谈 disk 问题 还是不太确切的。 对于大io ，看整体输出就好了。
  有机会你可以就 stripe size为128k 或者1m 做个测试。

  太过于拘泥细节，反而放不开手脚了

  fcp @ February 29, 2008 |

• 

  磁盘有那么大的吞吐量，不用白不用！

  zhaolinjnu @ February 29, 2008 |

• 

  我这里谈的DISK就是没有做strip的单独磁盘,并不是从存储上分出来的lun,只是想说明下,不同的应用,对于磁盘的选型会不同,同样是多磁盘,同样是IO均衡,在数据仓库这种基于吞吐量的系统里面,我觉得数据在磁盘上不要太散,一个大面包切成若干份分了就OK,OLTP这种,只有将面包磨成粉了散到N个磁盘来均衡离散的小IO

  八神苍月 @ February 29, 2008 |