Oracle RAC（Real Application Clusters）允许多个实例同时挂载并访问同一套数据库文件，这种共享架构对文件分布提出了比单实例更苛刻的要求。如果所有文件杂乱地放在同一个存储位置，不仅会引发IO热点，还会在节点间通信中放大全局缓存争用。合理的文件分布方案应当从故障隔离、性能均衡和管理便捷三个维度来设计，让每个类型的文件各归其位。
一、RAC文件类型与存储特性分析
在规划之前，必须先厘清RAC环境中究竟有哪些文件需要存放。除了普通单实例就有的数据文件、控制文件、在线重做日志和归档日志之外，RAC还引入了OCR（Oracle Cluster Registry）和Voting Disk这类集群仲裁文件。OCR记录集群配置信息，Voting Disk负责节点心跳仲裁，一旦它们所在的存储出现抖动，整个集群都可能被踢出节点。因此这两类文件对可用性和延迟极其敏感，绝不能和大量顺序写的数据文件混用。
数据文件是体量最大、随机读写最频繁的部分。在RAC中，所有实例通过Cache Fusion机制共享这些数据块，如果数据文件所在的磁盘组本身存在IO瓶颈，全局缓存的授予和块重建就会变慢，表现为gc buffer busy之类的等待事件升高。在线重做日志则是另一类关键文件，它虽然是顺序写，但提交延迟直接决定事务响应时间，并且每个实例都有自己的线程（thread），需要独立的 redo 组。归档日志只在切换后才产生，可以放在相对便宜的大容量存储上。
从管理角度看，使用ASM（Automatic Storage Management）是官方推荐也是最常用的方式。ASM以磁盘组为单位组织磁盘，并在文件级别做条带化和镜像，屏蔽了底层操作系统的设备差异。我们可以创建不同的磁盘组，比如GRID用于OCR和Voting Disk，DATA用于数据文件，FRA用于快速恢复区（含归档和备份），REDO用于在线日志。这种分类既符合故障域隔离原则，也方便后续扩容时只增加对应磁盘组。
二、基于ASM的磁盘组划分实践
下面给出一个典型的双节点RAC磁盘组规划示例。假设我们拥有四组物理盘：一组SSD做集群仲裁，一组高性能NVMe做redo，两组SAS做数据和恢复区。在ASM中创建磁盘组的语句如下，注意每个磁盘组根据冗余需求选择NORMAL或HIGH冗余，OCR通常建议HIGH冗余以保障仲裁安全。
-- 创建集群专用磁盘组，存放OCR和Voting Disk
CREATE DISKGROUP GRID NORMAL REDUNDANCY
DISK '/dev/asm-grid01' NAME grid01,
'/dev/asm-grid02' NAME grid02,
'/dev/asm-grid03' NAME grid03;
-- 创建数据文件磁盘组
CREATE DISKGROUP DATA NORMAL REDUNDANCY
DISK '/dev/asm-data01' NAME data01,
'/dev/asm-data02' NAME data02;
-- 创建在线重做日志专用磁盘组
CREATE DISKGROUP REDO EXTERNAL REDUNDANCY
DISK '/dev/asm-redo01' NAME redo01,
'/dev/asm-redo02' NAME redo02;
-- 创建快速恢复区磁盘组（归档、备份）
CREATE DISKGROUP FRA NORMAL REDUNDANCY
DISK '/dev/asm-fra01' NAME fra01,
'/dev/asm-fra02' NAME fra02;
创建完成后，需要将集群资源指向对应磁盘组。例如使用asmca或crsctl将OCR迁移到GRID磁盘组，Voting Disk用crsctl add css votedisk添加。数据文件则通过建表空间时指定+DATA前缀来实现，如CREATE TABLESPACE users DATAFILE '+DATA' SIZE 10G。 redo 日志在创建数据库时就要为每个实例分配独立组，并且放在+REDO中，避免和数据文件争夺带宽。
这种划分带来的好处是显而易见的。当备份任务大量写FRA时，DATA和REDO的IO曲线几乎不受干扰；某个SAS盘组故障，集群仲裁依然由GRID中的SSD保障。同时，由于ASM在磁盘组内自动平衡，新增磁盘后只需ALTER DISKGROUP ... ADD DISK即可，不需要停机移动文件，极大降低了运维复杂度。
三、参数配置与常见误区规避
很多人在部署时容易忽略DB_CREATE_FILE_DEST和DB_RECOVERY_FILE_DEST等参数的正确设置，导致文件被悄悄创建到了错误的磁盘组。应该明确指定：DB_CREATE_FILE_DEST='+DATA'让数据文件默认落盘到DATA，DB_RECOVERY_FILE_DEST='+FRA'将恢复区定向到FRA，LOG_ARCHIVE_DEST_1='LOCATION=+FRA'控制归档位置。如果依赖默认路径，很可能把归档写进DATA，挤占业务表空间空间。
-- 在实例参数文件中显式声明文件分布目标 ALTER SYSTEM SET DB_CREATE_FILE_DEST='+DATA' SCOPE=BOTH; ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+FRA' SCOPE=BOTH; ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=200G SCOPE=BOTH; ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=+FRA' SCOPE=BOTH;
另一个常见误区是把OCR和Voting Disk放在和数据库文件相同的磁盘组，并采用EXTERNAL冗余。这样做虽然省盘，但一旦底层存储控制器故障，集群仲裁和业务数据会同时失效，恢复极其困难。还有人习惯把多个实例的redo放在同一个文件系统中不同目录，这在RAC里没有必要且增加管理成本，直接用独立的REDO磁盘组配合ASM模板即可。
最后需要关注文件大小的初始分配。RAC中数据文件可以启用量化扩展（autoextend），但redo日志大小应基于峰值事务量估算，通常每个实例每组不少于500MB，并且组数至少2组以实现循环切换。控制文件建议在DATA和FRA各镜像一份，通过CONTROL_FILES参数同时指向+DATA和+FRA，这样即使一个磁盘组损坏，控制文件仍可从另一处恢复，保障RAC整体的可恢复性。
Oracle_RAC数据库文件分布ASM修改时间：2026-08-15 04:15:31