裸设备在Linux上已基本不可用，Oracle 12c起弃用、19c完全移除支持，Linux内核5.0+默认不加载raw模块，/dev/raw/通常为空，强行配置会导致实例无法启动并报ORA-1507等错误。
裸设备在Linux上还能用吗？别试了
oracle 12c 起已正式弃用裸设备（raw device）支持，19c 完全移除；create database 或 alter tablespace 指定裸设备路径会直接报 ora-01501 + ora-00202。linux 内核 5.0+ 也默认不加载 raw 模块，ls -l /dev/raw/ 基本为空。强行配置不仅无法启动实例，还会在 alert_orcl.log 里刷满 ora-1507: cannot mount database – raw device not supported。
条带化（Striping）该由谁来做？数据库还是存储？
Oracle 自身不提供软件条带化能力（ASM 不是条带化工具，而是卷管理器）；所谓“在 Oracle 层做条带”，实际只有两种可行路径：
- 用
ASM配置EXTERNAL、NORMAL或HIGH冗余磁盘组——其中NORMAL和HIGH会自动跨 failure group 条带化写入，但前提是底层物理磁盘或 LUN 已分离（比如不同 SSD 或不同 RAID 卡通道） - 依赖存储层（如 Dell PowerStore、NetApp AFF）开启硬件条带化，并将多个 LUN 映射给主机后，由
ASM统一管理——此时 I/O 请求会被存储控制器自动分散到多块物理盘
在文件系统层（如 XFS）用 mkfs.xfs -d su=256k,sw=4 手动指定 stripe unit/swidth，仅对顺序大 I/O 有效；对 Oracle 随机小块（8KB/16KB）写入基本无收益，反而可能因 misalignment 导致额外 I/O。
真正影响表空间写入性能的三个硬指标
排查时别被“条带化”概念带偏，先盯死这三项：
-
df -h和df -i：表空间数据文件所在挂载点是否空间或 inode 耗尽？ORA-0111490% 是这个原因，不是性能问题而是写不进去 -
iostat -x 1 5看%util和await：若某块盘%util > 95%且await > 20ms，说明 I/O 饱和，需确认是重做日志、归档、临时表空间还是数据文件共用了同一物理路径 -
v$session_wait中等待事件：大量db file parallel write表示 DBWn 写脏块慢；大量log file sync表示 LGWR 提交慢——这两者都指向底层存储响应延迟，而非条带策略缺陷
替代裸设备的现代方案：ASM + 多路径 + NVMe
想获得裸设备当年追求的低开销、高吞吐，现在标准做法是：
- 用
ASM管理磁盘，冗余模式设为NORMAL，确保每个 failure group 对应独立物理路径（例如：/dev/nvme0n1p1 和 /dev/nvme1n1p1 分属不同 NVMe 控制器） - 启用多路径（multipath）并设置
queue_if_no_path，避免单路径故障引发 I/O hang - 重做日志、临时表空间、归档目标必须分盘——哪怕都是 NVMe，也要挂载到不同目录（如 /u01/redo、/u02/temp、/u03/arch），否则
log file sync和db file sequential read会互相卡住
最后提醒一句：ASM 的 stripe 是逻辑层面的，它不控制单次 I/O 的物理落盘位置；真正的条带效果，取决于你有没有把磁盘物理分散，而不是在 SQL*Plus 里敲了几行 CREATE DISKGROUP。
