最直接的方式是查询dba_tablespaces视图中status='offline'的记录，sql为：select tablespace_name,status,contents,extent_management from dba_tablespaces where status='offline';该查询反映表空间逻辑状态，system、undo及临时表空间不可离线，若出现属异常。
查 dba_tablespaces 里状态为 offline 的表空间
最直接的方式是查数据字典视图 dba_tablespaces，它反映的是表空间本身的逻辑状态（status 字段），而非底层数据文件状态。只要表空间被显式执行过 alter tablespace ... offline，这里就会显示 offline。
执行以下 SQL 即可定位所有离线表空间：
SELECT TABLESPACE_NAME, STATUS, CONTENTS, EXTENT_MANAGEMENT FROM DBA_TABLESPACES WHERE STATUS = 'OFFLINE';
注意：SYSTEM、UNDO 和临时表空间（TEMPORARY 类型）无法被置为 OFFLINE，所以查询结果里不会出现它们——如果出现了，说明元数据异常或环境已被破坏。
常见误判点：
-
DBA_TABLESPACES.STATUS为READ ONLY≠OFFLINE，只读表空间仍可查询，不能混为一谈 - 连接到 PDB 时，
DBA_TABLESPACES默认只返回当前 PDB 的表空间；若想查 CDB 级别全部表空间，需用CDB_TABLESPACES并确保以SYS登录 CDB$ROOT - 执行完
DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES后残留记录，说明清理未完成，此时STATUS可能仍是OFFLINE或INVALID，需人工核对控制文件与磁盘文件一致性
查 V$DATAFILE 和 DBA_DATA_FILES 找“实际脱机”的数据文件
表空间状态是逻辑层的，而数据文件状态（STATUS 或 ONLINE_STATUS）才是物理层的真实可用性。一个表空间可能显示 ONLINE，但其下某个 DATAFILE 实际是 OFFLINE 或 RECOVER，这会导致部分对象不可访问。
推荐组合查询：
SELECT d.TABLESPACE_NAME, d.FILE_NAME, d.STATUS, v.ONLINE_STATUS
FROM DBA_DATA_FILES d
JOIN V$DATAFILE v ON d.FILE_ID = v.FILE#
WHERE v.ONLINE_STATUS IN ('OFFLINE', 'RECOVER');
关键区别：
-
DBA_DATA_FILES.STATUS是静态定义（如AVAILABLE），不反映实时状态；真正起作用的是V$DATAFILE.ONLINE_STATUS -
ONLINE_STATUS = 'OFFLINE'表示该文件已明确脱机，可能是人为执行ALTER DATABASE DATAFILE ... OFFLINE，也可能是 I/O 故障后 Oracle 自动置为离线 -
ONLINE_STATUS = 'RECOVER'意味着该文件需要介质恢复才能重新上线，此时即使表空间是ONLINE，也无法使用
为什么 ALTER TABLESPACE ... OFFLINE 不等于所有数据文件都“不可见”？
执行 ALTER TABLESPACE users OFFLINE 会把该表空间下所有数据文件的 ONLINE_STATUS 统一设为 OFFLINE，但这个动作不修改 DBA_DATA_FILES.STATUS 字段，也不删除控制文件中的记录。
容易踩的坑：
- 在 NOARCHIVELOG 模式下对数据文件执行
OFFLINE DROP，V$DATAFILE.ONLINE_STATUS变为OFFLINE，但控制文件仍保留该文件条目——后续RECOVER会失败，必须用CREATE CONTROLFILE重建 - 误用
ALTER DATABASE DATAFILE ... OFFLINE而非ALTER TABLESPACE ... OFFLINE：前者只影响单个文件，表空间状态不变；后者才真正切断整个表空间的访问路径 - 执行
OFFLINE IMMEDIATE后未做恢复就尝试ONLINE，会报ORA-01113或ORA-01110，必须先RECOVER TABLESPACE
查不到 Offline 表空间？先确认你有没有权限和上下文
很多情况下“查不到”，其实不是没数据，而是权限或连接上下文不对：
- 普通用户默认无权查
DBA_*视图，应使用ALL_TABLESPACES（只显示自己有权限访问的表空间）或联系 DBA 授权SELECT_CATALOG_ROLE - 在 PDB 中执行查询却期望看到 CDB 全局表空间，结果为空——必须切换到 CDB$ROOT 并用
CDB_TABLESPACES - 数据库刚启动且未完全 OPEN（比如卡在 MOUNT 阶段），
V$DATAFILE可能不可用，DBA_TABLESPACES返回空集或部分数据 - 某些云托管 Oracle 实例（如 Oracle Cloud ATP）限制了对
V$视图的访问，只能依赖DBA_TABLESPACES和告警日志交叉验证
真正麻烦的不是查不到，而是查出来多个 OFFLINE 条目却不知道哪个是“活的”、哪个是残留垃圾——这时候得比对 V$DATAFILE 的 CREATION_TIME 和控制文件中实际存在的物理路径。
