ORA-01950 根源是用户在目标表空间无配额，需用 ALTER USER ... QUOTA 授权；查 dba_ts_quotas 确认配额状态，避免误用 GRANT UNLIMITED TABLESPACE。
ORA-01950 不是权限缺失，而是配额没配 —— 用 ALTER USER ... QUOTA 解决，别去 GRANT UNLIMITED TABLESPACE。
查清楚报错时实际用的是哪个表空间
错误信息里写的表空间名（比如 'USERS'）就是关键线索。它不一定是用户的默认表空间，而是建表或插入时显式/隐式指定的那个。
- 执行
SELECT username, default_tablespace FROM dba_users WHERE username = 'MCDBA_BAK';看默认值，但别默认它就是报错表空间 - 如果建的是索引，得查该索引属主和所在表空间：
SELECT owner, tablespace_name FROM dba_indexes WHERE table_name = 'T1' AND table_owner = 'USER1'; - 迁移脚本或 ORM 可能硬编码了
TABLESPACE USERS，得翻日志或配置确认真实目标
用 dba_ts_quotas 验证用户在该表空间有没有配额
必须用 DBA 账号（如 SYS 或 SYSTEM）查，user_ts_quotas 只显示当前登录用户的记录，排查他人问题会漏掉。
- 执行
SELECT tablespace_name, max_bytes FROM dba_ts_quotas WHERE username = 'MCDBA_BAK' AND tablespace_name = 'USERS'; - 返回空行 → 完全没配额
- 返回
max_bytes = 0→ 配额被设为零（等同于禁用） - 返回
max_bytes = -1→UNLIMITED已生效 - 返回正数（如
10737418240）→ 是 10G 配额，但可能已被耗尽
用 ALTER USER ... QUOTA 授权，别碰 UNLIMITED TABLESPACE
GRANT UNLIMITED TABLESPACE TO username 能绕过 ORA-01950，但它允许用户往 SYSTEM、SYS 等核心表空间写数据，生产环境审计通不过，也容易引发事故。
- 安全做法是精准控制：
ALTER USER MCDBA_BAK QUOTA UNLIMITED ON USERS; - 若需限制，用带单位的写法：
ALTER USER TESTUSER QUOTA 50G ON K3CLOUD_DATA;（单位支持K、M、G） -
QUOTA 0 ON USERS会从dba_ts_quotas中删掉该记录，不是“设为零”，而是“彻底移除配额” - 语句必须由 DBA 用户执行，普通用户无法修改自己或其他人的配额
新建用户默认在所有表空间的 max_bytes = 0，不手动赋 QUOTA 就无法写入任何表空间——这点最容易被忽略，尤其在自动化建库流程中漏掉配额步骤，后续所有 DML 都会卡在 ORA-01950。
