会。oracle不允许对未显式授予unlimited tablespace权限的用户执行revoke，否则报ora-01952；该权限可能来自resource或dba角色隐式继承，需先查dba_sys_privs和dba_role_privs确认来源，再逐个回收并补配额，否则建表将报ora-01536。
直接执行 REVOKE UNLIMITED TABLESPACE FROM user 会失败吗？
会。Oracle 不允许对未显式授予该权限的用户执行 REVOKE，否则报 ORA-01952: system privilege not granted。
这不是语法错误，而是权限模型的强制校验：你只能收回“真正存在”的授权记录。
-
DBA_SYS_PRIVS中查不到该用户记录 → 说明没被直接授予过，不能REVOKE - 但用户仍可能有无限空间能力 → 权限来自
RESOURCE或DBA角色（隐式继承） - Oracle 12c 及以后版本中，
RESOURCE角色默认不再带UNLIMITED TABLESPACE，但老库或手动授过角色的用户仍需检查
怎么确认用户是否真有 UNLIMITED TABLESPACE 权限？
只查 DBA_SYS_PRIVS 不够。必须结合角色继承路径判断：
- 先查显式授予：
SELECT grantee FROM dba_sys_privs WHERE privilege = 'UNLIMITED TABLESPACE' AND grantee = 'USERNAME' - 再查角色来源：
SELECT granted_role FROM dba_role_privs WHERE grantee = 'USERNAME' AND granted_role IN ('RESOURCE', 'DBA') - 最终验证方式是看用户能否在非默认表空间建表而无需配额 —— 这才是真实效果
注意：admin_option = 'YES' 表示该用户还能转授此权限，也应一并处理，否则回收后别人可能又被授出去。
回收后用户建表报 ORA-01536 怎么办？
回收 UNLIMITED TABLESPACE 后，用户在所有永久表空间的配额变为 0（包括其 DEFAULT TABLESPACE），此时任何建表、建索引操作都会触发：
ORA-01536: space quota exceeded for tablespace 'USERS'
必须立刻补配额，否则业务中断：
-
ALTER USER username QUOTA 10M ON users—— 设有限上限 -
ALTER USER username QUOTA UNLIMITED ON users—— 仅放开指定表空间（推荐） -
ALTER USER username QUOTA 0 ON users—— 彻底禁止写入（慎用，DML 扩展也可能失败）
别漏掉 TEMPORARY TABLESPACE：虽然它不走配额机制，但若用户临时段爆满，排序、GROUP BY 等操作也会失败 —— 应确保其 TEMPORARY TABLESPACE 指向一个健康、有足够空间的临时表空间。
批量脚本最容易忽略的三个点
写 PL/SQL 脚本生成 REVOKE 语句很常见，但以下三点常导致后续故障：
- 没排除
SYS、SYSTEM等内置账户 —— 它们需要保留UNLIMITED TABLESPACE，硬回收会导致数据库异常 - 没检查用户当前连接状态 ——
REVOKE对已存在的会话不生效，但新会话立即受限；若应用池未重建连接，现象会延迟暴露 - 没清理角色链路 —— 即使收回了权限，只要
RESOURCE角色还在，下次GRANT RESOURCE TO username又自动带回（尤其在自动化部署流程里）
真正的闭环不是“ revoke 一次”，而是：查清来源 → 收回显式权限 → 按需设配额 → 审计角色使用策略。
