Oracle RAC 的多实例共享磁盘架构决定了存储层一旦出现热点，所有节点的事务处理都会受到拖累。设计存储分层策略，本质是按照文件访问模式和对延迟的敏感程度，把不同类型的数据库文件分布到不同性能、不同成本的存储介质上，而不是简单把所有文件塞进一个卷组。评估存储分层是否合理，需要同时考虑集群仲裁、事务提交、查询吞吐和备份恢复四类场景，缺少任何一类都可能造成生产环境波动。
Oracle 数据库运行在 RAC 上时，数据文件、控制文件、联机重做日志、归档日志、OCR 和投票盘都必须放在共享存储中。不同文件对 I/O 的敏感度差异很大，这是分层存储能够产生收益的根本原因。
一、RAC共享存储下的分层目标与文件特征
在 RAC 架构中，所有实例通过共享存储访问同一个数据库，存储层不存在单节点本地 I/O 的概念。正因为如此，存储延迟会通过缓存融合、GCS/GES 消息交互放大到整个集群。比如某个节点上的一个全表扫描把存储控制器队列打满，另一节点上的日志写入就会出现明显等待。因此，分层策略的第一个目标就是把随机小 I/O 与顺序大 I/O、延迟敏感 I/O 与吞吐敏感 I/O 分离开。
从文件类型看，OCR 和 voting disk 是集群级别的关键文件。OCR 保存集群配置信息，更新频率不高，但每次节点重启或配置变更都必须可靠读取；voting disk 用于节点之间仲裁，对写入延迟和崩溃一致性要求极高。控制文件和在线日志同样属于高频写入路径。控制文件记录数据库结构变更，数据块保护需要不断更新；联机重做日志则承担事务提交落盘的任务，lgwr 后台进程以顺序写方式追加日志，如果与随机读混合，很容易出现机械硬盘寻道或 SSD 队列冲突。
数据文件是容量和访问量最大的一类。OLTP 业务以小块随机读为主，少数热点表会贡献大部分物理 I/O；而报表、归档表等冷数据很少被访问，却占用大量空间。把数据文件按冷热再分为两个层次，可以显著降低全闪存储的采购压力。归档日志和备份集则完全不同，它们通常只用于恢复，顺序写入和顺序读取为主，对延迟并不敏感，非常适合放在容量型 HDD 上。
二、使用ASM磁盘组构建层次化存储
ASM 磁盘组是 Oracle 在 RAC 中推荐使用的存储管理方式。一个磁盘组可以由多块物理磁盘或存储 LUN 组成，ASM 会在内部进行条带化和镜像。利用不同磁盘组承载不同性能的介质，是最直接的分层手段。典型规划可以分成四个磁盘组：+OCR_VOTE、+DATA_SSD、+DATA_HDD、+FRA_HDD。如果预算允许，还可以为 redo 单独创建 +REDO_SSD。
创建磁盘组时，外部冗余适用于底层存储已经做了 RAID 保护的场景，ASM 自身镜像则用于需要跨存储柜故障域的场景。下面是创建 OCR 投票盘磁盘组的简单示例：
CREATE DISKGROUP +OCR_VOTE EXTERNAL REDUNDANCY DISK '/dev/mapper/ocr_vote01' NAME ocr_vote01 SIZE 10240M;
对于数据磁盘组，如果存储本身已经是 RAID10，通常使用 EXTERNAL REDUNDANCY；如果底层只是裸盘或需要 ASM 级镜像，可以使用 NORMAL REDUNDANCY 并配置故障组。故障组应尽量对应不同的存储控制器或机柜，避免一个控制器故障导致整个镜像失效：
CREATE DISKGROUP +DATA_SSD NORMAL REDUNDANCY FAILGROUP controller_a DISK '/dev/mapper/ssd_data01' NAME ssd_data01 FAILGROUP controller_b DISK '/dev/mapper/ssd_data02' NAME ssd_data02 SIZE 51200M;
创建完磁盘组后，可以开启 OMF 自动文件创建。设置 DB_CREATE_FILE_DEST 后，新建表空间如果不指定数据文件路径，Oracle 会自动把文件放到对应磁盘组；设置 DB_RECOVERY_FILE_DEST 后，归档日志、备份集和闪回日志也会自动进入快速恢复区。这样能够减少手工指定路径带来的偏差。
ALTER SYSTEM SET DB_CREATE_FILE_DEST='+DATA_SSD' SCOPE=BOTH; ALTER SYSTEM SET DB_RECOVERY_FILE_DEST='+FRA_HDD' SCOPE=BOTH; ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE=2048G SCOPE=BOTH;
需要注意的是，OMF 只是让文件创建变简单，并不会自动根据冷热移动数据文件。真正的存储分层仍然需要 DBA 在建表空间、移动分区时主动指定磁盘组。
三、关键文件类型的放置策略与参数调整
OCR 和 voting disk 的放置非常关键。在安装 RAC 时，OCR 可以放在 ASM 磁盘组中，voting disk 也可以由 ASM 管理。官方建议 voting disk 至少三份，分别放在不同的磁盘组或不同存储设备上。实际部署时，很多环境会单独创建一个 +OCR_VOTE 磁盘组，容量不需要大，但必须使用低延迟 SSD，并保证多路径配置正确。不要把投票盘塞进繁忙的数据磁盘组，否则可能因为 I/O 超时被驱逐节点。
联机重做日志是事务提交的必经路径。为了降低 log file sync 等待，redo 日志建议放在独立的高性能 SSD 磁盘组，最好配置两个磁盘组以实现成员镜像。可以通过初始化参数指定 OMF 创建日志成员的位置，也可以直接添加日志组。例如：
ALTER DATABASE ADD LOGFILE GROUP 5
('+REDO_SSD_1', '+REDO_SSD_2') SIZE 2G;
数据文件冷热分离比较灵活。SYSTEM、SYSAUX、UNDO 以及频繁写入的业务表空间应当放在全闪磁盘组。历史表、归档表、只读表空间可以迁移到 HDD 磁盘组。移动数据文件可以使用 ALTER TABLESPACE ... MOVE DATAFILE 语法，也可以使用 RMAN 恢复或 Data Pump 重新组织。例如把 orders 表空间从 SSD 层移动到 HDD 层：
ALTER TABLESPACE orders MOVE DATAFILE '+DATA_SSD/orcl/datafile/orders01.dbf' TO '+DATA_HDD/orcl/datafile/orders01.dbf';
归档日志和备份集通常写入快速恢复区。归档日志是顺序写，HDD 的顺序带宽足够承载，但需要避免与 redo 日志共用一个物理磁盘。设置归档路径时，可以直接使用 USE_DB_RECOVERY_FILE_DEST，让归档进入前面配置的 +FRA_HDD：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST' SCOPE=BOTH;
AU 大小和条带宽度也会影响分层效果。ASM 默认 AU 为 1MB，细粒度条带宽度为 128KB。OLTP 场景下默认值通常足够，而数据仓库或归档库可以考虑设置 4MB AU 来提升顺序大 I/O 的吞吐。创建磁盘组时可以通过 ATTRIBUTE 指定，例如 AU_SIZE 设置为 4M。需要注意的是，AU 一旦设置，后续在线调整比较复杂，建组前应结合业务 I/O 特征做好评估。
四、常见误区与性能验证方法
实际项目中有一个常见误区：把高性能 SSD 和原有 HDD 放进同一个 ASM 磁盘组，认为 ASM 会自动把热数据放到 SSD 上。事实上，ASM 的条带化会对磁盘组内所有磁盘均匀分布数据，它并不知道哪些数据块更热。要实现真正的冷热分层，必须由 DBA 把表空间或分区明确放到不同的磁盘组。
另一个误区是过度依赖冗余级别来保证性能。例如底层存储已经做了 RAID10，ASM 磁盘组仍使用 NORMAL REDUNDANCY，会额外占用一倍空间并增加写入放大。同样，把归档日志和 redo 日志放在同一个物理 RAID 组的不同逻辑卷上，虽然从 ASM 层面看是不同磁盘组，但底层仍会争抢同一组磁盘的磁头或控制器队列，无法获得分层收益。
验证分层策略是否有效，可以通过 ASM 动态性能视图观察磁盘 I/O。以下查询可以快速查看磁盘组容量和错误情况：
SELECT name, state, total_mb, free_mb, required_mirror_free_mb FROM v$asm_diskgroup; SELECT name, path, read_errs, write_errs, read_time, write_time FROM v$asm_disk;
数据库层面则需要关注 AWR 中的 log file sync、log file parallel write、db file sequential read 等事件的等待时间。如果 redo 日志已迁移到 SSD 后 log file sync 仍然很高，就要检查存储多路径、HBA 队列深度和链路抖动。Oracle 还提供 I/O 校准工具，例如 DBMS_RESOURCE_MANAGER.CALIBRATE_IO，可以测量存储的真实吞吐和 IOPS 上限，为后续磁盘组扩容提供依据。
分层存储不是一次配置后就固定不变。随着业务增长和热点表变化，可以定期根据 AWR 中的表空间 I/O 统计，把访问频率下降的表移动到 HDD 层，把新出现的热点表迁移到 SSD 层。只有把磁盘组规划、文件策略和持续验证结合起来，RAC 集群才能在性能、容量和成本之间保持平衡。
Oracle RAC存储分层ASM磁盘组修改时间：2026-09-21 04:55:24