RAC还有一个好处是，提高了可用性，也就是说一台服务器坏掉了（注意：不是数据存储介质），不影响正常使用。就像负载均衡一样，它提高了数据层以上的可用性，但不是全部，因为数据坏了，它也没有办法。（数据层，那是Oracle Data Guard的事了，或者干脆说那是存储硬件的事）

　　但是，RAC带来好处的同时，也带来了性能的影响。因为它要全局协调数据高速缓存，保证每个实例上连接的用户看到的缓存数据是一致的，所以把以下三方面的矛盾放大：

　　1.高速缓存争用2.过多的I/O 3.锁定

　　也就是说，如果这些方面有问题，用了RAC后问题就会更大，例如：由于SQL没有使用绑定变量导致高速缓存争用，用了RAC会更严重。

　　总之，如果你的服务器的CPU插满了，内存也加到极限了，而并发用户还在不断增长，或者你对故障停机时间要求非常高，RAC无疑是你应该选择的。

　　3.分区

　　Oracle的分区用途在于把大的表或索引分成小的片段，以便更容易管理。我们以前可能错误的认为分区就是fast=true，可以提高速度，也在肿瘤和儿科做过这方面的试验。实际上，在事务处理系统中，分区一般不能加快查询速度（某些情况下可能会减少对共享资源的争用）。Oracle的分区特性，主要是针对数据仓库来设计的，也就是说你的某张表如果有100G的大小，最好使用分区，好处有以下三个方面：

　　1.提高可用性

　　分区的原理就是分而治之，如果一张表划分为多个分区，其中一个分区所在的介质出了问题，不影响整个表的其它分区数据的访问。

　　2.易于管理

　　在数据仓库下，表分成小的片断，更容易批量的删除，碎片整理，以及一些并行处理。

　　3.提高性能

　　这方面，通过分区来达到是最困难的，必须经过周密的计算来安排分区数据。

　　分区的规划是复杂的，拿我们产品应用来说，一般查询涉及到多个表，多个索引，假设我们把病人费用记录，药品收发记录，病人医嘱记录这类大表建立分区。显然，范围分区对我们提升性能用处不大，散列分区才是我们查询需求的，但大多数数据的散列又不够集中。再加上，这些表上的索引这么多，常用的ID，时间类索引就不少，很少有人能做到把它们全部进行全局分区或准确的进行范围分区（实际上可能根本无法按需求进行多个索引的范围分区）。如果查询经常涉及多个索引，如何保证用到的每个索引都在一个分区上，如果不是，必然扫描多个分区，增加逻辑I/O和CPU时间，从而增加查询时间。（数据分布在不同物理存储介质的情况，在下面的并行处理中再讨论）

　　再来看一下，某些情况下可能会减少对共享资源的争用是指什么，是指并行修改和更新会更快。仔细分析，我们分区的原则是什么？一般最常用的可能是按时间段进行范围分区，这样，修改和更新绝大多数还是在同一个分区上进行，所以对减少共享资源的争用这方面，基本没有什么效果。（有按科室ID进行散列分区的对应的唯一应用需求吗？有基于列表分区（典型特征值）的对应的唯一应用需求吗？基本上没有。）分区主要从并行的角度来提高性能，但事务处理系统本身应用特性决定了它不适合这种技术。也就是说，针对我们产品的事务处理应用特点，根本没有必要采用分区技术。

　　4.并行处理

　　根据我们的应用特点，主要分析并行查询。一般要求配合分区特性，多CPU硬件。自Oracle 8.1.6起，增加了一个自动调节并行查询的选项：PARALLEL_AUTOMATIC_TUNING=TRUE在相应的表上设置PARALLEL参数，Oracle就会在适当的时候自动并行化该表上的操作。并行查询对事务处理系统基本上没有用。因为并行查询的设计是针对数据仓库中的单用户完全消耗100的资源而做的。而事务处理中，往往有很多并发用户，他们争用共用资源，所以你想办法让一个用户占用所有的资源是适得其反。