RAC 必须用 ASM 管理数据文件和归档，禁用单机目录结构；/u01 是唯一跨节点共享本地路径，需 udev 固化磁盘名并正确设置挂载依赖；OCR、DATA、RECO 三磁盘组必须物理隔离且冗余策略合理；控制文件与重做日志须跨磁盘组多路镜像并确保权限一致。
Oracle RAC 与单机环境的目录规划差异必须分清
直接用单机那一套 /u02/oradata、/u03/archivelog 往 RAC 上硬套，后续会卡在 ASM 启动、OCR 识别、节点间路径不一致这些地方。RAC 的本质是共享存储 + 分布式控制，本地文件系统目录只该放软件和日志，数据文件必须交给 ASM 管理。
关键区别在于：
-
/u01是唯一允许跨节点共享挂载的本地路径，必须用 LVM 或独立磁盘永久挂载，属主固定为grid:oinstall（Grid 安装）和oracle:oinstall（DB 安装） - RAC 中不再有
/u02/oradata这类本地数据目录——它被+DATA磁盘组替代；归档也不再走/u03/archivelog，而是由+RECO统一托管 - OCR 和 Voting Disk 必须放在独立的
+OCR磁盘组，不能和业务数据混用，否则集群启动失败概率极高
/u01 永久挂载必须绕过 /etc/fstab 的常见陷阱
很多团队在 vSphere 环境下用 vmfs 共享磁盘挂 /u01，但直接写进 /etc/fstab 会导致节点重启后挂载顺序错乱：ASM 实例先于 udev 规则加载，找不到磁盘设备节点，crsctl start crs 直接报 CRS-4639: Could not contact Oracle High Availability Services。
正确做法是：
- 使用 udev 规则固化 ASM 磁盘名（例如
/dev/asm-disk1），而不是依赖/dev/sdb这类内核分配名 -
/u01挂载项必须加x-systemd.requires=oracleasm.service（OL8）或_netdev（旧版），确保挂载时机晚于 ASM 初始化 - 不要用 UUID 挂载共享磁盘——vSphere 下多个节点看到的 UUID 相同，但挂载时会冲突；改用 WWN 或自定义 udev 名称
ASM 磁盘组划分不是越多越好，三组够用但必须隔离
生产环境见过最典型的错误，是把 OCR、数据文件、归档全塞进一个 +DATA，结果一次磁盘 IO 尖峰就拖垮整个集群。Oracle 官方推荐且经验证可靠的最小划分是：
-
+OCR：仅存放 OCR 和 Voting Disk，容量 5–10 GB 即可，必须用外部冗余（external redundancy），别浪费空间做镜像 -
+DATA：存放数据文件、控制文件、在线重做日志，建议 NORMAL 冗余（2-way mirror），IO 密集型业务可考虑高性能 SSD 单独划一组 -
+RECO：FRA、归档、闪回日志，可用 EXTERNAL 冗余降低开销，但必须保证足够空间——归档堆积是 RAC 故障第一诱因
注意：+DATA 和 +RECO 不能共用同一套物理磁盘，否则归档写入高峰会直接挤占数据文件读写带宽。
控制文件与重做日志必须多路镜像，且位置不能只靠 ASM
哪怕用了 ASM，控制文件和在线重做日志仍需手动指定多路镜像路径，否则单点故障就会导致实例宕机。这不是可选项，是 Oracle 生产环境的硬性要求。
实操要点：
- 控制文件至少 2 份，分别放在
+DATA和+OCR（或另一个独立磁盘组），避免 ASM 单点失效 - 在线重做日志组至少 3 组，每组至少 2 个成员，成员必须跨磁盘组（例如
+DATA和+RECO各放一个），不能都在同一个 ASM 磁盘组里 - 千万别信“ASM 自带冗余就够了”——ASM 冗余保护的是磁盘故障，而控制文件/日志损坏常来自误操作或 bug，多路镜像是逻辑层防护
真正容易被忽略的，是重做日志成员路径的权限一致性：所有节点上，grid 用户必须对每个 ASM 磁盘组有 ASM diskgroup create 权限，否则某节点日志切换时会卡在 ORA-15032 错误上，集群状态却显示正常。
