真正禁用oracle用户建表需同步撤销resource/dba角色、回收表空间配额至0，并验证create table及ctas均报权限不足；仅撤create table权限无效，因角色隐含该权限且unlimited tablespace可绕过限制。
直接撤销 create table 权限就能禁止用户建表，但仅靠这一步往往不够——oracle 的权限模型里，resource 角色默认自带 create table，而 dba 角色更会覆盖所有限制。必须连带处理角色、表空间配额和隐式依赖权限。
撤销 CREATE TABLE 权限本身不生效的常见原因
执行 REVOKE CREATE TABLE FROM username; 后用户仍能建表，大概率是因为：
- 该用户被授予了
RESOURCE角色（它包含CREATE TABLE等 20+ 个系统权限） - 该用户拥有
DBA角色（自动覆盖所有显式撤销） - 用户有
UNLIMITED TABLESPACE权限且默认表空间有配额，即使没CREATE TABLE，也可能通过其他方式间接创建对象（如 CTAS） - 使用了公共同义词或
CREATE ANY TABLE这类高危权限（极少见但存在）
真正禁用建表能力的三步操作
只撤一个权限是纸面功夫。要实打实阻断，必须同步清理角色、配额和隐含路径：
- 先查清用户实际拥有的权限来源：
SELECT granted_role FROM dba_role_privs WHERE grantee = 'USERNAME';和SELECT privilege FROM dba_sys_privs WHERE grantee = 'USERNAME'; - 撤销角色（比逐条撤权限更彻底）：
REVOKE RESOURCE FROM username;；若还给了DBA，也必须REVOKE DBA FROM username; - 回收表空间配额（关键！）：
ALTER USER username QUOTA 0 ON users;（替换成其默认表空间名）；否则即使没CREATE TABLE，用户仍可能用CREATE TABLE AS SELECT绕过
为什么 UNLIMITED TABLESPACE 必须一并处理
UNLIMITED TABLESPACE 是独立系统权限，不依赖 RESOURCE 或 DBA。只要它存在，用户在任意有配额的表空间都能建表——哪怕你已经 REVOKE CREATE TABLE。更隐蔽的是，这个权限不会出现在 dba_sys_privs 里，得查 dba_ts_quotas 确认配额状态。常见错误就是只撤权限、忘了清配额，结果用户照常建表报错 ORA-01950: no privileges on tablespace 才发现漏了这步。
验证是否真正生效的检查点
别只信命令返回 “revoke succeeded”，登录目标用户后手动试几条关键语句：
-
CREATE TABLE t1 (id NUMBER);—— 应报ORA-01031: insufficient privileges -
CREATE TABLE t2 AS SELECT * FROM dual;—— 应报ORA-01031或ORA-01950（取决于配额） -
SELECT * FROM session_roles;—— 确认RESOURCE和DBA不在列表中 -
SELECT tablespace_name, max_bytes FROM dba_ts_quotas WHERE username = 'USERNAME';—— 确认所有表空间max_bytes为 0 或 NULL
配额为 0 且角色已撤，才是真正的“不能建表”。任何一环松动，都可能被绕过。
