会失败。Oracle 不允许对未授予 UNLIMITED TABLESPACE 权限的用户执行 REVOKE，否则报 ORA-01952；必须先查询 DBA_SYS_PRIVS 等确认实际拥有者，再逐个回收，并补配额或调整角色。
直接执行 REVOKE UNLIMITED TABLESPACE FROM user 会失败吗？
会。oracle 不允许对不存在该权限的用户执行 revoke，否则报错 ora-01952: system privilege not granted。你不能“批量回收”所有用户——必须先确认谁真有这个权限，再逐个处理。
怎么查出哪些用户实际拥有 UNLIMITED TABLESPACE 权限？
只查 DBA_SYS_PRIVS 不够，因为该权限可能来自 RESOURCE 或 DBA 角色（隐式授予）。真正有效的判断方式是：该用户是否能在任意表空间建对象而没配额限制。最稳妥的查询是：
SELECT DISTINCT grantee FROM dba_sys_privs WHERE privilege = 'UNLIMITED TABLESPACE' AND admin_option = 'NO'
注意：admin_option = 'YES' 表示该用户还能转授此权限，也应一并处理。
回收后用户还能在默认表空间建表吗？
不能，除非你补上具体配额。回收 UNLIMITED TABLESPACE 后，用户在所有表空间的配额都变成 0（包括其 DEFAULT TABLESPACE），此时建表会报 ORA-01536: space quota exceeded for tablespace 'XXX'。你需要立即补上：
-
ALTER USER username QUOTA 10M ON users;（设有限配额） -
ALTER USER username QUOTA UNLIMITED ON users;（仅放开指定表空间） - 或重新
GRANT RESOURCE TO username;（但会再次带出UNLIMITED TABLESPACE）
别漏掉 TEMP 表空间——虽然不存数据，但排序/临时段失败也会中断操作。
用脚本批量回收时最容易忽略什么？
脚本生成 REVOKE 语句本身没问题，但以下三点常被跳过：
- 没过滤掉
SYS、SYSTEM这类内置管理账户（它们需要保留该权限） - 没检查用户是否正在连接（
REVOKE不影响已存在的会话，但新会话立即生效） - 没验证回收后用户是否仍能访问原表空间——比如
RESOURCE角色还在，下次GRANT RESOURCE TO ...又自动带回来
真正的管控闭环不是“ revoke 一次”，而是：查权限 → 收回 UNLIMITED TABLESPACE → 按需设 QUOTA → 禁用或重定义 RESOURCE 角色使用方式。
