ORA-01950是表空间配额缺失而非权限不足，需检查dba_ts_quotas中对应用户在目标表空间的max_bytes是否为0或无记录，正确做法是用ALTER USER QUOTA ON指定表空间配额。
ORA-01950根本不是权限问题，是配额缺失
报这个错时，create table、insert 或 create index 失败，不代表用户缺 create any table 这类系统权限——哪怕你 grant connect, resource to user 全给了，只要没配额，照样报错。核心判断依据只有一个：dba_ts_quotas 视图里查不到该用户的记录，或 max_bytes = 0。
用ALTER USER QUOTA ON指定表空间，别碰UNLIMITED TABLESPACE
必须由 SYS 或 SYSTEM 登录执行，普通用户无法自授配额。常见写法：
-
ALTER USER MCDBA_BAK QUOTA UNLIMITED ON USERS;——最常用，max_bytes写入-1 -
ALTER USER TESTUSER QUOTA 50G ON K3CLOUD_DATA;——按实际数据量预估，单位支持K/M/G -
ALTER USER APPUSER QUOTA 0 ON USERS;——显式清空配额，等同于禁用该表空间
切忌用 GRANT UNLIMITED TABLESPACE TO user 替代：它绕过所有表空间级控制，允许在 SYSTEM、SYSAUX 等关键表空间无限写入，审计和安全策略通常禁止此操作。
查dba_ts_quotas确认配额是否真正生效
执行完 ALTER USER 后别急着重跑任务，先验证：
SELECT tablespace_name, max_bytes FROM dba_ts_quotas WHERE username = 'MCDBA_BAK';
返回结果含义：
-
max_bytes = -1→UNLIMITED已生效 - 空行 → 授权语句未执行、用户名拼写错误、或连接的不是目标数据库实例
-
max_bytes = 0→ 配额被设为零，对象创建仍会失败
注意：user_ts_quotas 只显示当前登录用户的配额，排查他人问题必须用 dba_ts_quotas；如果报错提示的是 'K3CLOUD_DATA' 而非 'USERS'，就查对应表空间名，别默认只盯 USERS。
跨用户建索引或插入时，要分别检查两个用户的配额
比如 USER1 的表 T1 上，USER2 创建了索引并指定 TABLESPACE TBS1，那么 USER2 必须在 TBS1 有配额——USER1 的配额只管自己建表，不管别人建索引。
典型场景还有迁移工具（如Data Pump）以某个用户身份导入数据，但目标表空间属于另一用户默认表空间，此时需同时检查导入用户和目标 Schema 用户在该表空间的配额记录。
最容易被忽略的一点：配额是按「表空间」而非「用户」或「角色」绑定的，每个 username + tablespace_name 组合都要单独确认，不能假设“给了 A 就等于给了 B”。
