system、当前undo表空间、当前temp表空间根本不能执行alter tablespace...offline；normal适合计划维护，temporary跳过异常文件，immediate需后续介质恢复。
哪些表空间根本不能执行 alter tablespace ... offline
system、当前 undo 表空间、当前 temp 表空间，这三个一执行 alter tablespace ... offline 就直接报错，连试都不让试。错误通常是 ora-01145（脱机需要数据库归档模式）或更直接的 ora-01031: insufficient privileges —— 但其实不是权限问题，是 oracle 硬性禁止。你查 v$tablespace 或 v$database 就能确认当前 undo 和 temp 名称，别在它们身上浪费时间。
OFFLINE 的三种模式：NORMAL / TEMPORARY / IMMEDIATE 怎么选
不指定模式时默认是 NORMAL，但它要求所有数据文件都在线且可写，还要做检查点，耗时较长；TEMPORARY 会跳过 offline 状态异常的数据文件（比如已损坏或不可读），只对在线文件做检查点；IMMEDIATE 最快，但代价是后续 ONLINE 时必须做介质恢复（RECOVER DATAFILE），且数据库必须处于归档模式，否则直接报 ORA-01126。
-
NORMAL：适合计划内维护，无异常文件，想省去恢复步骤 -
TEMPORARY：怀疑某个数据文件出问题，但还想快速脱机整个表空间 -
IMMEDIATE：紧急隔离故障表空间，接受后续必须 recover 的事实
脱机前必须确认的三件事
别急着敲命令，先跑这几条查询：
- 查有没有活跃会话正在用这个表空间：
SELECT sid, serial#, username, sql_id FROM v$session WHERE username IS NOT NULL AND status = 'ACTIVE'，再结合v$transaction和对象所属表空间确认是否真有依赖 - 查数据文件状态：
SELECT file#, name, status FROM v$datafile WHERE ts# = (SELECT ts# FROM dba_tablespaces WHERE tablespace_name = 'YOUR_TS_NAME')，确保没有RECOVER或OFFLINE状态混在里边 - 确认不是只读表空间：
SELECT status FROM dba_tablespaces WHERE tablespace_name = 'YOUR_TS_NAME'，只读表空间不能脱机（会报ORA-01143）
ONLINE 失败时最常卡在哪
执行 ALTER TABLESPACE ... ONLINE 报 ORA-01113: file X needs media recovery 是最典型的现象——说明你用了 IMMEDIATE 脱机，或者脱机期间数据库崩溃过。这时候不能硬上 ONLINE，得先：RECOVER DATAFILE '/path/to/file.dbf'。如果归档日志缺失，recover 会卡住或失败；如果整个表空间多个文件都报这个错，要逐个 recover，顺序无关，但每个都得走一遍。recover 完才能 online，少一步都会回退到 RECOVER 状态。
容易被忽略的是：即使你用 NORMAL 脱机，如果脱机后有人动了控制文件或备份了部分文件，online 时也可能触发隐式 recover —— 所以脱机操作最好在低峰期做，且全程保留 alert.log 截图。
