1）、为简化系统的复杂度和与第三方软件之间的交互，Oracle 建议避免使用第三方集群管理软件，除非实在需要。
2）、推荐将 Automatic Storage Management (ASM) 用于数据库存储。
3）、在使用RAC之前，先检查产品支持矩阵，以确保产品、版本和平台组合的可支持性，或了解在某些组合中需要额外完成的所有特定步骤。
4）、与磁盘供应商联系，确认节点数、OS 版本、RAC 版本、CRS 版本、网络结构和补丁是否经过认证，因为有些存储/San 供应商可能要求针对特定的节点数进行专门认证。
5）、计划并记录容量要求。与服务器供应商合作，制定详细的容量计划和系统配置，但请注意：使用正常的容量计划流程估计运行工作负载所需的 CPU 数。随着 CPU 数量的增加，SMP 和 RAC 集群的成本会同步增加。如果 CPU 数量较少，通常是 SMP 的伸缩性较好；如果 CPU 数量较多，RAC 集群的伸缩性通常要比 SMP 好。
6）、需要消除架构中的所有单一故障点。示例包括（但不限于）：集群私网冗余（NIC 绑定等）、存储的多路存取路径、使用 2 个或多个 HBA 或发起程序和多路径软件、磁盘镜像/RAID。
7）、强烈建议用于生产的RAC 实例不与 DEV、TEST、QA 或 TRAINING 实例共享一个节点。这些额外的实例通常会给生产环境带来意外的性能改变。同时，强烈建议测试环境尽可能地接近生产环境的镜像。
8）、制定系统测试计划，并跟测试方案制定意外停机的计划并将其付诸实践。
9）、实施RAC前，最好列好一个详细实施计划。
1）、对于私有心跳网络，强烈推荐使用万兆以太网，至少需要使用千兆以太网。
2）、根据 RFC952 - DoD 主机列表说明，在主机名或域名中不使用下划线。这条规则也适用于 Net（网络）、Host（主机）、Gateway（网关）或 Domain（域）名。
3）、VIP 和 SCAN VIP 应与公网在同一个子网上。
4）、默认网关必须与 VIP（包括 SCAN VIP）在同一个子网上，以防止出现 VIP 启动/停止/故障转移问题。在 11gR2 中，OUI 会检测出并报告此问题，如果忽略检查，此问题将导致无法启动 VIP，从而导致安装自身也出现故障。
5）、建议通过 DNS，按round-robin方式将 SCAN 名称（11gR2 和更高版本）至少解析为 3 个 IP 地址。
6）、为避免名称解析出现问题，请确保 HOSTS 文件和 DNS 中提供了 VIP 与公共主机名。
7）、网络接口必须在所有节点上使用相同的名称（如 eth1 -> eth1 支持 VIP，eth2 -> eth2 支持专用私网网络）。
8）、网络接口卡 (NIC) 名称中不得包含 '.' 。
9）、私有心跳网络使用 Jumbo Frames 是提高 Cache Fusion 操作性能的最佳实践。
10）、对私有心跳网络建议使用non-routable的网络地址；A 类：10.0.0.0 到 10.255.255.255，B 类：172.16.0.0 到 172.31.255.255，C 类：192.168.0.0 到 192.168.255.255。
11）、请确保根据速度、双工等正确配置网络接口。可用于监视和测试网络的各种工具有：ethtool、iperf、netperf、spray 和 tcp。
12）、为避免公网或私网出现单一故障点，Oracle 强烈建议在每个集群节点上配置公共网络接口卡 (Network Interface Card, NIC) 和私网 NIC 的冗余集。从 11.2.0.2 开始，Oracle Grid Infrastructure 可为私网（不是公网）提供冗余和负载均衡，对于 11.2.0.2（必须使用 11.2.0.2 Database），这是 NIC 冗余的首选方法。
注意： 如果使用 11.2.0.2 Redundant Interconnect/HAIP 功能，目前要求所有私网要在不同的子网上。如果全部接口在同一个子网上，且从路由表的第一个 NIC 中拔出电缆，则将发生GI stacks重启或节点重启的情况。
13）、如果希望对发现硬件的可预测性更强，请将 HBA 和 NIC 卡插入 Grid 中每台服务器上的同一对应插槽中。
14）、私网连接需要使用交换机，或冗余交换机（不支持交叉线直连）。
15）、由于在交换机上部署私有网络（甚至在使用 VLAN 时）可能会使私网链路在大型 IP 网络拓扑中遭遇拥堵并变得不稳定，因此强烈建议为私网使用专用冗余交换机。如果在 VLAN 上部署私网，则在 VLAN 和non-routable的子网之间应该有一个 1:1 映射，并且 VLAN 不应该跨越多个 VLAN（已标记）或多个交换机。此环境中的部署问题包括在大型 IP 网络拓扑更改时的“Spanning Tree ”环、可能导致数据包洪流的不对称路由以及缺乏对 VLAN/端口的细粒度监视。
16）、从版本12.1.0.1 开始，集群公网支持IPv6，而集群私网必须使用IPv4。
1）、对使用两个或多个 HBA 或 Initiator 的存储阵列，多路径软件通过这些HBA 实现对这些阵列的多路径存取。如果可能，请使用伪设备（多路径 I/O）作为 ASM 的 diskstring。比如：EMC PowerPath、Veritas DMP、Sun Traffic Manager、Hitachi HDLM、IBM SDDPC、Linux 2.6 Device Mapper。这对 I/O 的负载均衡和故障转移非常有用。
2）、强烈建议在 RAC 环境中使用 ASM（而不是使用其它的集群文件系统）。使用 Oracle RAC 标准版时，数据文件存储需要使用 ASM。
3）、请确认定制化ASM Diskstring 以便优化ASM 磁盘发现时间。
4）、建议保持 ASM 磁盘组不超过两个，一个用于存储数据文件，一个用于闪回区（flash recovery area），而且每个磁盘组位于不同的物理磁盘。RAID 存储阵列 LUN 可作为 ASM 磁盘，以最小化 OS 中显示的 LUN 个数。
5）、每个 ASM 磁盘组上最少要有四个大小和性能相同的 LUN（每个 LUN在不同的RAID 组），以确保性能最优。
6）、使用高端存储阵列时使用外部冗余磁盘组。高端存储阵列一般提供硬件 RAID 保护。不使用硬件 RAID 或需要使用基于主机的卷管理功能（如跨存储系统镜像）时，则使用 Oracle ASM 镜像冗余。在地理位置上分离的两站点间镜像（扩展的集群）时，可以在配置中使用 Oracle ASM 镜像。
7）、在 11g 环境中，如果多个数据库共享同一个 ASM 实例，可能需要修改 ASM processes 参数。根据经验法则，ASM 的最佳进程数为 150 个，可用于确定合适值的公式为：
ASM processes = 50 x (<max # instances on db node> + <1 for first 10>) + 10 x (<subsequent instances after 10>)
8）、对于 10g，增大 ASM 实例 SGA 参数大小分配的默认值：
SHARED_POOL_SIZE=128M - 另外，当系统中的磁盘组数量大于5个时，每新增一个磁盘组，增加 SHARED_POOL_SIZE 500KB。
LARGE_POOL=12M
DB_CACHE_SIZE=64M
PROCESSES=150。
9）、磁盘做RAID条带化的尺寸 需要选择大小为 2 的幂且小于或等于 Oracle ASM Allocation Unit 的值。
10）、如果 ASM 磁盘组中的 LUN 大于 2TB，则可能会发生 ORA-15196（ASM 块损坏）。修复这个问题后，如果指定的磁盘大于 2TB，将发生 ORA-15099。无论是否存在 asmlib 这个问题都会发生。绕过问题的方法：不要向磁盘组中添加大于 2 TB 的磁盘。
1）、对于 11gR2 之前的版本，建议将 Voting Disks 存储在 裸设备或块设备（取决于 OS 和 Oracle 版本）上，并使用 Oracle 提供的冗余，而不用考虑底层存储配置。建议使用两个 OCR。Voting Disks 的数量应保持为奇数，且最小数量为 3。之所以建议 Voting Disks 为奇数，是因为如果所有 Voting Disks 丢失 1/2 或更多，将导致节点从集群中被驱逐，或导致节点将自己驱逐出集群。
2）、在 Grid Infrastructure 11gR2 中，已弃用 裸设备和块设备，建议使用 ASM 存储 OCR 和Voting Disks。在 11gR2 和更高版本中，将 OCR 和 Voting Disks 存储在 ASM 中时，建议保持 ASM 磁盘组不超过 2 个。这意味着 OCR 和 Voting Disks 将与数据库相关文件一起存储。如果要对磁盘组使用外部冗余，这意味着您将使用 1 个 Voting Disk 和 1 个 OCR。
3）、在 11.2.0.2 中，Oracle Grid Infrastructure 可为私有网络（不是公共网络）提供冗余和负载均衡，对于 11.2.0.2 版本的GI（必须使用 11.2.0.2 Database），这是 NIC 冗余的首选方法。
4）、对于版本 10gR2 和 11gR1，所有平台上的最佳实践都是将 CSS diagwait 参数设置为 13，以便在出现节点驱逐时提供转储诊断信息的时间。如果 Oracle Support 没有明确说明，建议 diagwait 的值不要超过 13。在 Oracle Clusterware 11g Release 2 中，将不再要求进行此设置。
5）、不要设置 ORA_CRS_HOME 环境变量（在所有平台上）。设置此变量将使各个 Oracle 组件出现问题，而且 CRS 程序完全不需要此变量，因为它们都有包装脚本。
1）、安装前，请仔细阅读官方安装说明文档
2）、请使用“真正”的root 用户运行root.sh/rootupgrade.sh脚本，不要使用sudo。当切换到root用户时，请使用'su -' 或 'su - root'，以便提供完整的环境设定，而sudo，pbrun，'su root' 或 'su'或类似的工具则不会。推荐在'完整'的root环境下运行root.sh/rootupgrade.sh脚本。
3）、建议安装 Oracle RAC 软件在本地文件系统，以允许使用滚动补丁升级，并避免出现单一故障点和其他故障。
4）、使用 cluvfy（集群验证实用程序）检查集群先决条件。在安装 Oracle 软件前，以及安装期间的所有阶段使用 cluvfy。
5）、在执行 11gR2 之前的安装时，建议在执行任何 RDBMS 或 ASM 主目录安装前应用补丁程序将 Clusterware 主目录升级到所需的级别。例如，在安装 10.2.0.1 RDBMS 前，先安装 Clusterware 10.2.0.1 并使用补丁程序升级到 10.2.0.4。
6）、在 11gR2 之前的环境中，出于维护和可用性的考虑（如独立补丁程序和升级），将 ASM安装到单独的ORACLE_HOME 。为轻松升级到 11gR2，ASM 软件所有者应与 Clusterware 软件所有者相同。
7）、从 11gR2 开始，所有补丁程序集都是可完全安装的版本。例如，要安装 11.2.0.2（11gR2 Patchset 1），可直接安装 11.2.0.2，无需先安装 11.2.0.1 再应用补丁程序升级到 11.2.0.2。
8）、如果安装 Oracle Clusterware的用户属于多个操作系统用户组，安装程序将在集群的所有节点上安装Oracle Clusterware，并将软件的组所有权设置为安装用户的当前活动组或主要组所有。因此，确保文件 /etc/group 中列出的第一个组是当前活动组，或使用以下命令行选项调用 Oracle Clusterware 安装，以强制安装程序在对所有文件设置组所有权时使用正确的组：runInstaller s_usergroup=current_active_group
1）、设置 PRE_PAGE_SGA=false。如果设置为 true，将大大增加建立数据库连接所需的时间。如果客户端投诉与数据库的连接太慢，则考虑将此参数设置为 false，因为这样做可以避免在进程启动时映射整个 SGA，从而节省连接时间。
2）、确保监控活动并行服务器进程的数量并计算要应用于 PARALLEL_MIN_SERVERS 的平均值。可通过以下操作完成：
Select * from v$pq_syssstat;
Then: Get/save the value for row 'Servers Highwater'
3）、根据硬件情况优化 PARALLEL_MAX_SERVERS的值。最开始可以使用 (2 * ( 2 个线程 ) *(CPU_COUNT)) = 4 x CPU 计算，然后使用测试数据对更高的值重复测试。
4）、考虑设置 FAST_START_PARALLEL_ROLLBACK。此参数可确定将有多少个进程用于事务恢复（在 redo 应用后执行）。为了确保在出现计划外故障后仍能获得高效的工作负载，优化事务恢复显得非常重要。只要系统不大量占用 CPU，最佳实践是将此参数设置为值“HIGH”。这会导致 Oracle 使用四倍于 CPU 个数 (4 X cpu_count) 的并行进程进行事务恢复。此参数的默认值是“LOW”，或两倍的 CPU 计数 (2 X cpu_count)。
5）、将 FAST_START_MTTR_TARGET 设置为非零值（以秒为单位）。崩溃恢复将在此要求的时间范围内完成。
6）、在 10g 和 11g 数据库中，不应再设置初始化参数 ACTIVE_INSTANCE_COUNT。这是因为 RACG 层不会考虑此参数。作为替代，您应该创建具有一个首选实例的服务。
7）、对于 11gR2 之前的版本，将 PARALLEL_EXECUTION_MESSAGE_SIZE 从默认值（通常为 2048）增加到 8192。对于基于数据仓库的系统（通过 PQ 传输大量数据），可以将其设置的更高。在版本 11gR2 中，PARALLEL_EXECUTION_MESSAGE_SIZE 的默认值是 16K，经证明，该值在大多数情况下都能够满足要求。
8）、设置 OPTIMIZER_DYNAMIC_SAMPLING = 1 或确保您的数据库对象都收集了统计信息，因为 10g 动态采样在执行 SQL 语句期间可以生成额外的 CR 缓冲区。
9）、对于所有版本在Oracle 10.2.0.3 到 11.0.6.0之间的数据库，LMON 进程可能会挂起，并且 Instance Membership Recovery (IMR) 无法驱逐挂起的实例。11.1.0.7 中已修正此问题。在 10gR2 中，可通过 bug 5259835 修复此问题。此增强已包含在 10.2.0.4.1 和更高版本的 PSU 中，在某些平台上作为 10.2.0.3 和 10.2.0.5 都有的one-off补丁程序。对于 11.1.0.6.0，需要进行以下设置：
_lm_rcvr_hang_check_frequency = 20
_lm_rcvr_hang_allow_time = 70
_lm_rcvr_hang_kill = true
1）、正确配置 Oracle Net Services 负载均衡以分发连接。负载均衡应该与 Workload Management 结合使用以提供最高可用性。工作负载服务的 CLB_GOAL 属性应根据应用要求进行相应的配置。不同工作负载可能会有不同的负载均衡目标。请为每个服务使用 CLB_GOAL 单独配置每个工作负载。
2）、对于 11.2 之前的 listener，请确保 IPC 项存在，且此项列在所有 RAC listener 的 listener.ora 地址列表的第一个。否则，可能会对 VIP 在公网接口出现故障时进行故障转移所用的时长产生不利影响。
3）、对于 11.2 之前的实施，建议从 ASM 主目录（假设ASM在单独的ORACLE_HOME下运行）运行 listener。这样即可在带有 listener的一个节点上注册多个数据库，且无需绑定到特定数据库主目录。
4）、对于 11gR2，默认情况下将从 Grid Infrastructure 主目录运行 listener。
5）、对于 11gR2 环境，不应为 Grid Infrastructure 环境设置 TNS_ADMIN 环境变量，因为它会导致 oraagent 无法维护 listener配置文件。TNS_ADMIN 也可能会影响 Clusterware 启动、停止和监控 listener 的能力。
6）、强烈建议为 11.2 数据库使用 SCAN（用于 11.2 客户端连接），因为这样可以简化客户端连接，且在集群添加和（或）删除节点时无需修改数据库连接字符串。
7）、应该为listener配置 remote listener进行交叉注册以支持工作负载重定向和负载均衡，从而允许在 RAC 集群中分发服务连接请求。通过此配置，每个 listener都会知道是哪个实例在处理特定服务以及当前给定的数据库实例上有多少负载。这让客户端可以在 listener之间对要在服务级别进行管理的工作负载进行连接请求的负载均衡。
8）、在 11gR2 之前，LOCAL_LISTENER 参数应该指向正在运行特定数据库实例的本地系统 listener的 VIP地址。对于 11gR2，LOCAL_LISTENER 参数应设置为其默认值，以允许 oraagent 根据 OCR 中存储的 listener配置正确设置参数。
9）、一般而言，每个 RAC 节点（不包括 SCAN）仅需要一个 listener为给定集群上运行的所有数据库处理连接。如果需要或要求在每个集群节点上使用多个 listener，则务必在 OCR 上注册这些额外的 listener，以确保这些额外 listener的 HA 和正确管理。
10）、建议创建额外数据库服务以处理应用程序连接，而使用默认数据库服务用于管理用途。这样，管理员除了能够轻松控制哪些应用程序连接到哪些实例，同时还可以灵活地实现诸如服务器端 TAF、FAN、FCF 和运行时连接负载均衡等功能。
11）、利用面向连接的可用性功能，例如透明应用故障转移 (Transparent Application Failover, TAF)、快速应用通知 (Fast Application Notification, FAN)、快速连接故障转移 (Fast Connection Failover, FCF)、运行时连接负载均衡 (Runtime Connection Load Balancing, RCLB)。
12）、使用安全传输类 (Class of Secure Transport, OST) 限制实例注册，从而防止数据库向 listener进行未授权注册。这样可以避免 Oracle 安全警告 CVE-2012-1675 中发布的问题。
联系客服
