ORA-01950错误源于用户缺乏目标表空间的存储配额,而非权限不足;需用ALTER USER ... QUOTA显式授予配额,如UNLIMITED或指定大小,且DEFAULT TABLESPACE不自动赋予配额。
ORA-01950:没配额就建不了表
用户拿到 create table 权限(比如通过 resource 角色)后,仍可能在建表时报 ora-01950: no privileges on tablespace 'users'。这不是权限没给够,而是缺了「表空间配额」——oracle 不允许用户往一个它没被授权写入的表空间里存数据。
用 ALTER USER … QUOTA 给配额
必须显式给用户在目标表空间上的存储配额,才能真正建表。常见做法是给无限配额,但注意:这不是授予权限,而是资源使用许可。
-
ALTER USER test_user QUOTA UNLIMITED ON users;—— 最常用,适用于开发/测试环境 -
ALTER USER test_user QUOTA 100M ON hbi_data;—— 限制用量,适合多租户或生产隔离场景 -
ALTER USER test_user QUOTA 0 ON users;—— 显式禁止在该表空间建对象,常用于清理或迁移前锁定
配额只对「默认表空间」或「显式指定的表空间」生效;如果建表时用 CREATE TABLE t1 (...) TABLESPACE other_ts,那还得单独给 other_ts 配额。
UNLIMITED TABLESPACE 系统权限 ≠ 表空间配额
很多人误以为 GRANT UNLIMITED TABLESPACE TO test_user; 就能绕过配额检查,其实它只跳过「配额校验」,不等于自动赋予配额。效果等价于给所有现有及未来表空间都设了 QUOTA UNLIMITED,但有两点关键限制:
- 该权限只对当前已存在的表空间生效;新建的表空间仍需手动配额或重新授此权限
- 在 Oracle 12c+ 多租户(PDB)环境下,
UNLIMITED TABLESPACE默认不向下继承到 PDB,必须在 PDB 内单独授予 - 审计和资源管理策略可能禁用该权限,生产环境慎用
创建用户时直接带配额更稳妥
与其事后补 ALTER USER,不如在建用户阶段就明确配额,减少遗漏。注意语法顺序:
CREATE USER app_user IDENTIFIED BY pwd123 DEFAULT TABLESPACE app_data TEMPORARY TABLESPACE temp; ALTER USER app_user QUOTA UNLIMITED ON app_data;
不能把 QUOTA 写进 CREATE USER 语句里(Oracle 不支持),必须拆成两步。另外,DEFAULT TABLESPACE 只影响未指定表空间时的默认位置,不自动附带配额——这点最容易被忽略。











