ORA-01950报错根本原因是用户默认表空间为SYSTEM且无配额，而非权限缺失；Oracle禁止非SYS用户在SYSTEM表空间写入，即使授予UNLIMITED TABLESPACE也无效，必须修改默认表空间并显式分配配额。
ORA-01950 报错根本不是权限缺失，而是配额被硬性禁止
报 ora-01950: no privileges on tablespace 'system' 时，别急着查 create table 权限——用户很可能已有该权限，但 oracle 对 system 表空间做了特殊限制：非 sys 用户无法被授予任何配额，alter user ... quota 在 system 上静默失败或直接报 ora-02181。这不是疏漏，是设计使然。
常见误判点：
- 以为
GRANT UNLIMITED TABLESPACE TO user能绕过——它对SYSTEM和SYSAUX无效 - 看到
SYSTEM用户名就默认它能操作SYSTEM表空间——其实SYSTEM用户默认也无SYSTEM表空间配额 - 用
SELECT * FROM DBA_SYS_PRIVS查系统权限，却忽略表空间级配额才是关键拦路虎
怎么快速确认是不是掉进了 SYSTEM 表空间陷阱
执行这两条 SQL，5 秒内定位问题根源：
SELECT default_tablespace FROM dba_users WHERE username = 'YOUR_USER';
SELECT tablespace_name, bytes/1024/1024 AS MB FROM dba_ts_quotas WHERE username = 'YOUR_USER';
如果第一句返回 SYSTEM，第二句结果里没有 SYSTEM 行、或对应 MB 是 0，那就坐实了：用户正试图往禁止写入的区域写数据。
注意：CREATE TABLE t(x INT) TABLESPACE SYSTEM 或 INSERT /*+ APPEND */ 显式指定 SYSTEM，也会立刻触发该错误，不依赖默认表空间设置。
必须改默认表空间，而不是“临时指定 TABLESPACE”
临时方案（如 CREATE TABLE t(x INT) TABLESPACE users）只治标——只要用户默认表空间仍是 SYSTEM，下一次建索引、物化视图、甚至某些 DDL 触发的内部对象，仍可能失败。
正确做法只有这一条路径：
- 用
SYS或SYSTEM（需有ALTER USER权限）执行：ALTER USER your_user DEFAULT TABLESPACE users; - 紧接着分配配额：
ALTER USER your_user QUOTA UNLIMITED ON users;（或指定具体大小，如QUOTA 100M ON users） - 验证生效：
CREATE TABLE test_check (id NUMBER);不带TABLESPACE子句，应成功
别用 USERS 以外的自定义表空间？确保该表空间已存在、状态为 ONLINE，且数据文件路径有足够磁盘空间和 OS 写权限。
为什么不能跳过配额直接用 GRANT
CREATE TABLESPACE 本身需要 CREATE TABLESPACE 系统权限，但这和往 SYSTEM 写对象完全无关——后者连 DBA 角色都无法解除限制。Oracle 的 SYSTEM 表空间本质是只读保护区，存放 DBA_TABLES、STANDARD 包等核心字典对象，任何用户（包括 SYSTEM）向其中写业务表，都属于严重违反运维规范的行为。
真正容易被忽略的点是：错误日志里不会明说“禁止写入”，只会笼统报 no privileges；而 DBA 往往先查角色、再查系统权限，最后才想到查 dba_ts_quotas——但这时已经浪费半小时了。
