生产环境严禁将所有数据文件统一置于 /u01/app/oracle/oradata，因其导致io争用、故障扩散和扩容僵化；应按i/o特征分路径存储，如system/undo走asm raid10，redo物理隔离，归档路径须独立且确保写权限与配额。
数据文件路径不能只写 /u01/app/oracle/oradata
生产环境里直接把所有数据文件塞进 /u01/app/oracle/oradata 是最常见也最危险的懒政做法。它看似省事，实则埋下三个硬伤：IO争用（system、undo、temp、业务表空间全挤在一块盘上）、故障扩散（单块磁盘损坏可能连带毁掉控制文件+数据文件+归档目录）、扩容僵化（想单独扩某个表空间？得先挪文件，再改字典，还得停业务）。Oracle本身不强制路径隔离，但存储层的物理隔离是RAC、Data Guard、备份恢复稳定性的底层前提。
按功能角色拆分路径，不是按表空间名字分目录
别被“users01.dbf”“idx01.dbf”这种命名误导。路径规划的核心依据是I/O行为特征，而不是对象类型标签。你得问自己：这个文件读多写少还是写多读少？是否要求低延迟？是否允许缓存丢失？
-
SYSTEM、SYSAUX、UNDO：必须放在高可靠、低延迟的存储上（如ASM磁盘组或RAID 10），路径建议独立，例如+DATA/CDB1/SYSTEM01.DBF；不要和业务数据混放 -
TEMP：可容忍短暂不可用，但对随机写性能敏感，适合放在本地SSD或高速SAN LUN，路径如/oradata/temp_cdb1/temp01.dbf，且建议配多个临时文件分散压力 - 业务表空间（如
APP_DATA、APP_INDEX）：按访问热度和生命周期拆——高频交易表空间走高性能存储，历史归档表空间可落机械盘，路径分别对应+HIGH_PERF/APP_DATA01.DBF和+ARCHIVE/APP_HIST01.DBF -
REDO LOG：必须与数据文件物理分离，避免日志刷盘阻塞数据写入；路径严禁放在NAS或慢速LUN，典型路径为/redo/cdb1/redo01.log，且每个group至少2个member跨不同物理路径
绝对禁止的路径写法
这些写法在巡检脚本里一搜一个准，但上线即埋雷：
- 路径含空格或中文：
/u01/app/oracle/oradata/业务库01/→ Oracle部分后台进程会解析失败，DBCA静默模式直接报错退出 - 使用相对路径或软链：
../datafiles/users01.dbf或/u01/oradata → /dev/mapper/vg_data-lv_oradata→ RMAN恢复时可能找不到源路径，ALTER DATABASE MOVE DATAFILE会因软链目标变更失效 - 归档路径和数据文件共用同一挂载点：
archive_dest = '/u01/app/oracle/oradata'→ 归档暴增填满文件系统，数据库直接挂起（ORA-00257） - 裸设备路径未加权限检查：
/dev/raw/raw1→ Linux 8+ 默认禁用raw设备，且udev规则未固化会导致重启后设备名漂移，startup mount失败
ASM不是万能解药，但路径规划逻辑必须适配它
如果你用ASM（尤其是RAC环境），路径就不是传统文件系统路径，而是磁盘组+别名组合。这时候“规划路径”的本质变成规划磁盘组策略和别名命名规范。
- 别名必须带语义：
+DATA/CDB1/APP_DATA_01.DBF比+DATA/CDB1/DATAFILE/01可读性强十倍，运维排查时一眼定位归属 - 磁盘组按性能分层：
+DATA（RAID 10，主业务）、+FRA（RAID 6，归档/备份）、+RECO（RAID 1，快速恢复区）——别把FRA和DATA混在一个磁盘组里 - 禁止用
ASMCMD cp手动拷贝数据文件到ASM：这会绕过数据字典，DBA_DATA_FILES查不到记录，后续无法管理 - 迁移前务必确认
COMPATIBLE.ASM和COMPATIBLE.RDBMS参数匹配，否则19c往ASM 12.2磁盘组写文件会报ORA-15032+ORA-15260
真实生产中，最常被忽略的是归档路径的写权限和磁盘配额联动。哪怕路径写对了，如果Oracle OS用户对归档目录只有r-x权限，或者文件系统启用了userquota但没给oracle用户配额，归档一满就会卡住LGWR进程——这时候看archive log list还是“Archive Mode”，但日志切换已停滞，SELECT * FROM V$ARCHIVED_LOG 最新记录停在几小时前。
