会失败。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'。你需要立即补上：

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

• 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 角色使用方式。