为什么说RAC是一个好的数据仓库解决方案，但我不认为它是一个好的OLTP解决方案。因为在OLTP系统中，过多的cache fusion会大大降低系统的性能，所以Oracle也建议尽量在不同的节点部署不同的应用，尽量减少交叉访问。所以OLTP应用的RAC的节点数不会很多(一般为2-3个)，因为节点越多，管理的成本就越高，目前的很多OLTP应用都是用RAC来提供HA方面的特性，OLTP应用还是采用分布式架构比较合适，指望RAC来得到线性扩展的能力不太可能。

   数据仓库应用则不同，因为任务之间比较独立，在加上数据仓库的应用主要是并行计算，这样就可以充分利用RAC节点间并行处理能力，这样RAC的节点数就可以有很多，几乎可以做到线性扩展。这时新的问题出现了，我一直说Oracle RAC的最大问题在于IO吞吐量受限于共享存储，不管是中端还是高端存储，吞吐量往往受限于存储本身的架构，所以单台存储的吞吐量总是有限的。

   我们能否用廉价的PC设备堆叠一个可线性扩展的存储呢？

   利用Oracle ASM和iscsi，我们可以搭建一个廉价的数据仓库解决方案，底层的数据节点可以选用专门的PC服务器，现在很多厂商都有类似产品，一台PC机可以挂24块SAS/SATA磁盘，通过iscsi输出到每台数据库主机，因为RAC要求共享存储，所以我们用网络交换机把所有数据节点和数据库节点全部连起来。用Oracle ASM管理存储，利用ASM做mirror和stripe，把IO分散到所有的数据节点上，并且还可以做到动态迁移。ASM的failgroup可以分别定义在不同的数据节点上，这样就算坏掉一个数据节点，对整个系统依然不会有影响。用iscsi主要是考虑成本，当然可以把数据节点换成存储，把iscsi换成FC。

   Oracle有一篇软文介绍淘宝数据仓库系统，号称全球最大的RAC系统，这套系统有20个节点，但是并没有提到存储，我们可以设想，如果采用单一存储架构，那要多大的一个存储呢？其实……

   这个架构并没有经过测试，如果Oracle有兴趣的话，可以搭一个系统测试一下，如果真的是便宜量又足，能否给我一个ACE混混？

   -EOF-

建议继续学习：

1. ORACEL RAC 字符集    (阅读：4502)
2. Oracle RAC中的RDS内部互联    (阅读：2439)
3. kswapd 进程占用过多资源导致RAC宕机    (阅读：2436)
4. RAC的负载均衡    (阅读：2399)
5. RAC环境下Memory System Deconfigured    (阅读：1996)
6. oracle RAC DRM基本概念    (阅读：1871)