数据库规划要从业务特性和需求为导向，不要为了RAC的可用性而上RAC，实际上RAC也不是万能的，需要如下知识点需要掌握。
1.使用RAC的好处
1.1 提升应用系统性能，提高数据库事务处理能力
在单台主机资源或者单实例数据库的事务处理能力受到瓶颈时，使用RAC能极大提高并发能力。
主机的资源使用率不是简单的求和。比如在2个节点的RAC环境中，每个节点的CPU使用率为50%，如果所有资源转移到单个节点，其使用率不会等于100%，可能70%。所以资源的使用很大程度上在于交互成本。
当交互成本过大时，其处理效率会极大的降低。
1.2提高数据库高可用性，尤其是双活的架构下。其好处如下：
同城本地服务器和同城异地服务器之间的无需任何切换，实现极为稳定可预期的秒级失败业务切换。
业务连接的后台数据中心，是同城双活中心，任一站点的故障，业务不受到影响，这大大提高了业务的响应能力，也大大增加了检修等日常运维管理时间。
3.RAC的选型考虑
全表扫描情况是不是很多？
索引争用厉不厉害？
高水位争用厉不厉害？
sequence争用厉不厉害？
正版授权、安装、运维费用是否在预算范围内？
4.RAC的副作用
资源争用成本会成倍放大，负载均衡下尤其严重
代码访问深度变深，带来的bug,数据库的整体稳定性甚至不如单节点
节点之间SQL执行计划不一致
心跳网络的故障率很高
各个版本之间的差异化
对维护人员的技能经验要求较高
如果在单实例中数据块争用比较厉害，那么迁移到RAC之后就会是一场灾难，性能可能会更加恶化。在这种情形下，多买了一台小机，只实现了HA的功能，但付出的是性能下降。得不偿失！
其中一个实例hang住时，RAC的可用性得不到保障
5.安装时
全面检查操作系统补丁情况，建议安装最新的数据库补丁
心跳网络使用双网卡绑定
主机的操作系统版本要求一致，配置最好一致
部署主机资源监控脚本，如部署OSW
做好各项暴力测试，如CRS/主机启动测试，插拔网线测试
?
6.运维时
应用端做针对RAC特性调整，建议业务分节点运行
死锁可能在多个节点发生
不要将数据文件增加到本地硬盘上
先关数据库，再关CRS软件，最后关主机
单机转成RAC之后，适当加大buffer cache和shared pool的大小
开启并行要慎重，程序不要跨节点并行运行
容易忽略的数据库参数
7.学习RAC的几点建议
具备操作系统的相关知识，熟悉vmware或Oracle vbox基本操作
安装、升级，且反复安装、升级
阅读官方文档，知道“有什么”，“怎么做”，再查其他文档
在实验环境中操作，尤其需要操作以下内容：
CRS的资源管理
ASM磁盘、磁盘组的添加删除操作
OCR/VOTING DISK的备份、恢复、镜像、删除操作
VIP/PUBLIC IP/HAIP/PRIVATE IP更改操作
学会查看CRS日志文件
要学会查看gv$视图
了解业务特性，尤其需要知道哪张表在哪个节点访问频率最高
熟悉CRS日志存放位置