ORA-01950报错本质是用户在目标表空间缺乏配额，而非权限不足；需通过ALTER USER ... QUOTA ON tablespace授权，查dba_ts_quotas验证max_bytes是否为-1（UNLIMITED）或正值。
ORA-01950报错本质是配额缺失，不是权限不足
ora-01950看起来像权限问题，但实际和grant语句无关——它只反映用户在目标表空间（如users）没有可用配额。即使用户有create table、insert等权限，只要dba_ts_quotas里查不到该用户的配额记录，或max_bytes = 0，插入/建表就会失败。
常见触发场景包括：
- 新建迁移用户后未显式分配配额，依赖默认表空间但无额度
- 全量迁移时数据量远超预设配额（比如只给了
1G，实际需50G） - 索引由另一用户创建，而该用户在索引所在表空间（如
TBS1）没配额
用DBA账号执行ALTER USER QUOTA分配配额
必须用SYS、SYSTEM等具备DBA角色的用户登录执行，普通用户无法修改自身或其他用户的配额。
推荐直接授予无限制配额，避免反复排查容量瓶颈：
ALTER USER MCDBA_BAK QUOTA UNLIMITED ON USERS;
若需限制资源，可指定具体大小（单位支持K、M、G）：
ALTER USER TESTUSER QUOTA 10G ON USERS;
注意：QUOTA 0 ON USERS会彻底移除该用户的配额记录，等同于禁用该表空间；QUOTA UNLIMITED对应dba_ts_quotas.max_bytes = -1。
验证配额是否生效：查dba_ts_quotas视图
授权后别急着重跑任务，先确认配额已写入数据字典：
SELECT tablespace_name, max_bytes FROM dba_ts_quotas WHERE username = 'MCDBA_BAK';
返回结果中max_bytes为-1即表示UNLIMITED已生效；若为空行，说明授权语句未执行成功或用户名拼写错误；若为0，说明被显式设为零配额。
补充检查点：
- 确认报错时实际使用的表空间名（可能不是
USERS，而是K3CLOUD_DATA等自定义表空间） - 若涉及跨用户对象（如
USER1.T1上USER2建的索引），要分别查两个用户的配额 -
user_ts_quotas仅显示当前登录用户的配额，排查他人问题必须用dba_ts_quotas
别误用UNLIMITED TABLESPACE系统权限
虽然GRANT UNLIMITED TABLESPACE TO username也能绕过ORA-01950，但它允许用户在所有表空间（含SYSTEM、SYS）无限制使用，生产环境极不安全，且部分审计策略会禁止该权限。
更稳妥的做法始终是：
- 明确指定目标表空间（如
USERS或迁移工具配置的实际表空间） - 用
ALTER USER ... QUOTA精准控制范围 - 迁移完成后，可根据需要回收配额（
ALTER USER ... QUOTA 0 ON ...）
配额是按表空间粒度管理的，一个用户可在多个表空间拥有不同配额，这点常被忽略。
