CREATE TABLESPACE 通过 DATAFILE '+DATA/...' 指定 ASM 磁盘组，路径以+开头且大小写敏感；需确认磁盘组已挂载、USABLE_FILE_MB充足，并注意AU大小对实际分配空间的影响。
CREATE TABLESPACE 语句里怎么指定 +DATA 磁盘组
oracle asm 中，create tablespace 本身不直接写 +data，而是通过指定 datafile 路径来隐式指向磁盘组。关键不是“写 +data”，而是路径格式必须符合 asm 命名规则。
-
DATAFILE后跟的路径以+开头（如+'DATA'），Oracle 自动解析为磁盘组；不能写成+/data/...或/u01/app/oracle/oradata/... - 磁盘组名大小写敏感，
+DATA和+data是两个不同磁盘组；执行前用SELECT NAME FROM V$ASM_DISKGROUP;确认真实名称 - 不显式指定文件名时（如
DATAFILE '+DATA'），Oracle 自动在磁盘组内生成 OMF（Oracle Managed Files）风格的文件名，形如+DATA/ORCL/DATAFILE/users.256.123456789
ORA-15041：磁盘组空间不足但实际还有余量
执行 CREATE TABLESPACE 报 ORA-15041: diskgroup space exhausted，常见于磁盘组启用了 USABLE_FILE_MB 限制或存在大量未清理的废弃别名（alias）。
- 检查可用空间用
SELECT TOTAL_MB, FREE_MB, USABLE_FILE_MB FROM V$ASM_DISKGROUP WHERE NAME = 'DATA';—— 注意是USABLE_FILE_MB，不是FREE_MB，它受冗余策略和分配单元影响 - 如果磁盘组是 NORMAL 冗余，
USABLE_FILE_MB≈FREE_MB / 2；EXTENDED REDUNDANCY 下会更低 - 运行
ALTER DISKGROUP DATA CHECK ALL;可发现并修复因异常关闭遗留的无效文件引用，有时能释放隐藏占用
为什么加了 SIZE 却创建出远大于预期的数据文件
在 ASM 中指定 SIZE 100M，最终文件物理大小可能远超该值，这不是 bug，而是 ASM 分配机制导致的。
- ASM 按 Allocation Unit（AU）分配空间，默认 1MB；即使你只写
SIZE 100K，也会占满 1 个 AU（即 1MB） - 若磁盘组 AU 大小被设为 4MB（常见于大文件表空间场景），
SIZE 500K的数据文件实际仍占用 4MB 物理空间 - 查 AU 大小：
SELECT ALLOCATION_UNIT_SIZE FROM V$ASM_DISKGROUP WHERE NAME = 'DATA'; - 想控制粒度？只能调小 AU（建盘时决定），运行中不可改；日常建议按 AU 整数倍指定
SIZE，避免“浪费感”
使用 OMF 时忘记关掉 DB_CREATE_FILE_DEST 会怎样
如果数据库参数 DB_CREATE_FILE_DEST 已设为某个 ASM 磁盘组（如 '+RECO'），而你又在 CREATE TABLESPACE 中显式写了 DATAFILE '+DATA'，Oracle 会优先用显式路径——但容易误判。
- 真正危险的是漏写
DATAFILE子句：比如只写CREATE TABLESPACE tbs1;，此时 Oracle 完全依赖DB_CREATE_FILE_DEST，文件会落到+RECO而非你期望的+DATA - 检查当前默认位置：
SHOW PARAMETER DB_CREATE_FILE_DEST - 稳妥做法：显式写出完整
DATAFILE路径，并确认磁盘组在线、挂载且有足够USABLE_FILE_MB—— 别依赖默认值做关键配置
最常被忽略的其实是磁盘组的挂载状态和权限：V$ASM_DISKGROUP 显示 MOUNTED 不代表所有实例都能访问，RAC 环境下得确认该磁盘组在所有节点都已 ALTER DISKGROUP DATA MOUNT;
