我们是否需要RAC？

       RAC是Oracle数据库的高可用性集群架构，具有高可用性、负载均衡以及自动异常转换等诸多优点。它即高贵又娇情，使用这套架构，通常意味着更高的投入。但如果希望它能包治百病似乎也是不太可能的，那么，当我们决定使用单实例，或者RAC架构时，我们需要考虑什么呢？如果，你是土豪，你可以跳过本文了。

RAC解决了什么问题？

RAC系统具有的HA、Load Balance、FailOver特性，这些优点自然不必多言。从系统性能的角度考虑，RAC主要是对数据库系统的CPU以及内存资源进行了扩充。

目前主流的集群架构主要有两种，SMP：多处理器结构(Symmetric Multi-Processor)、MPP：海量并行处理结构(Massive Parallel Processing)。常见的传统数据库，DB2集群是MPP架构，Oracle集群是SMP架构。对于DB2集群来说，每个集群节点都是一个独立的作业单元。对于Oracle集群来说，每个集群节点只有CPU和内存是独立的，但IO存储资源却是共享的。这也就是前面说的，RAC虽然号称高可用性。但从本质上来说，RAC集群只是扩展了数据库系统的CPU及内存资源，IO方面依然存在单点故障的可能。

RAC架构虽然在IO方面没有太大的优化，但在增加了内存的情况下，它本身就会减少数据库系统的IO访问量，这也是一种能力的提升。但这种提升是对系统整体而言的，对于单条SQL而言，在单实例或者RAC中执行，性能上并没有大的差别。甚至，在RAC访问中变得慢一些也是正常的。

 

我们是否需要RAC？

       通过上面的分析，RAC对数据库性能而言，在CPU以及内存方面进行了扩充，在IO方面的提升并不是特别明显。当我们在讨论是否需要RAC时，我们需要回答一个问题：我们的系统瓶颈是什么？这里举两个例子以示说明。

       一个系统是某零售商ERP系统，由于一些原因，在该ERP生产系统中，一直存在大量拉报表数据的情况，占用了系统很大的IO资源。更加离谱的是，为了让报表拉得更快，还在生产系统加添加了大量的并行。一旦开启报表功能，整个系统瞬间变慢。后来，投入巨大人力物力，将系统改造成了RAC架构，但系统性能依然没有大的提升。很显然，如果系统本身的瓶颈就是IO资源，即使改用RAC架构，对于解决问题也没有帮助，或者说帮助并不明显。在这个案例中，最直接的办法就是把报表功能剥离出去，重新建议一套报表系统，在生产与报表系统之间建立数据同步，从而解决问题。

       另一套系统是电商系统，由于业务需要实时计算一些数据，因此在后台开启了10多个实时进程。每个实时进程其实就是一个死循环，以实现对数据的实时处理。在这种情况下，可以简单的理解为仅仅这个实时功能就需要消耗10多个逻辑CPU资源为其提供服务，那么在这种情况下是否可以考虑RAC呢？答案应该是肯定的，可以通过RAC让系统增加更多的资源以满足计算需要。但同时，也存在另一个网络问题。当实时计算存在于某一个节点的时，这也意味着它需要同另一个节点进行巨大的数据交换操作。如果私网的性能不够强大，那必然会出现节点经常重启的故障。甚至在更严重的情况下，拖累整个系统的性能。

       理论总是很美好，现实总是很残酷。在上马RAC之前，一定要分析系统的瓶颈所在，对症下药方能从根本上解决问题。