DBA_DATA_FILES.NAME 是别名还是路径取决于存储方式：以“+”开头为ASM别名，否则为文件系统绝对路径；它仅含永久表空间数据文件，不包含临时或UNDO文件。
直接查 dba_data_files 只能拿到数据库里记录的文件路径，它不等于物理磁盘位置——尤其当用了 asm 时，name 字段显示的是别名（如 +data/orcl/datafile/users.256.123456789），根本不是 linux 上可挂载的设备路径。
DBA_DATA_FILES.NAME 是路径还是别名？
取决于 Oracle 存储方式：
- 如果
NAME以+开头（如+DATA/...），说明走 ASM，NAME是 ASM 别名，不是 OS 路径；此时得查V$ASM_DISK.PATH才能找到真实设备（如/dev/oracleasm/disks/DISK1） - 如果
NAME是绝对路径（如/u01/oradata/ORCL/users01.dbf），才是文件系统路径，可用df -h /u01确认它挂在哪块磁盘上 -
DBA_DATA_FILES不区分永久表空间、临时表空间、UNDO 表空间——它只返回永久表空间的数据文件；TEMPFILE和UNDO文件得另外查
怎么查出真正挂载的磁盘设备？
分两步走，不能只靠一条 SQL：
- 先确认存储类型：
SELECT NAME FROM V$DATAFILE WHERE ROWNUM = 1;看开头是不是+ - 如果是 ASM：连 ASM 实例查
SELECT PATH, HEADER_STATUS, MODE_STATUS FROM V$ASM_DISK;，再关联V$ASM_DISKGROUP和V$DATAFILE的GROUP_NUMBER - 如果是文件系统：在 OS 层执行
df -h $(dirname "/u01/oradata/ORCL/users01.dbf")，注意要加$()执行替换 - 别漏掉
v$tempfile和v$datafile中属于 UNDO 表空间的文件——它们可能和 SYSTEM 表空间挤在同一块盘上，高并发下容易突发占满
为什么只查 DBA_DATA_FILES 容易误判磁盘分布？
常见踩坑点：
- 同一表空间多个数据文件（
users01.dbf,users02.dbf）可能分散在不同挂载点，但DBA_DATA_FILES不带磁盘 I/O 或利用率信息，看不出哪块盘快满了 - DBA 角色默认看不到
V$ASM_*视图，需额外授权：GRANT SELECT ON V_$ASM_DISK TO your_user;（注意是V_$ASM_DISK，不是V$ASM_DISK） - 临时表空间和 UNDO 表空间不会出现在
DBA_DATA_FILES里，但它们同样吃磁盘空间；漏查会导致扩容后仍报ORA-01652或ORA-01653 - 某些环境用 OMF（Oracle Managed Files），
NAME是自动生成的，路径藏在DB_CREATE_FILE_DEST参数里，得先查：SHOW PARAMETER DB_CREATE_FILE_DEST
最常被忽略的其实是 UNDO 表空间的物理位置——它默认跟 SYSTEM 表空间绑在一起，而 SYSTEM 往往在根分区或 /u01，一旦事务密集，undo 段快速扩展，可能悄无声息把整块盘撑爆。查完 DBA_DATA_FILES，务必补一句：SELECT 'UNDO' type, name FROM v$datafile WHERE ts# IN (SELECT ts# FROM v$tablespace WHERE contents = 'UNDO');
