ora-01950 是因用户在目标表空间无配额，而非缺少权限；需用 alter user ... quota 授权，查 dba_ts_quotas 确认配额状态，并对索引等对象属主精准配置。
ora-01950 不是权限缺失，而是配额没配 —— 用 alter user ... quota 解决，别去 grant 系统权限。
查清楚报错时实际用的是哪个表空间
错误信息里写的表空间名（比如 'USERS'、'K3CLOUD_DATA'、'TBS1'）就是关键线索。它不一定是用户的默认表空间，而是对象创建或数据写入时显式/隐式指定的那个。
- 执行
SELECT username, default_tablespace FROM dba_users WHERE username = 'MCDBA_BAK';看默认值，但别默认它就是报错表空间 - 如果报错涉及索引（如
INSERT INTO USER1.T1失败），要查该表上索引的tablespace_name：SELECT index_name, tablespace_name FROM dba_indexes WHERE table_owner = 'USER1' AND table_name = 'T1'; - 迁移工具或应用可能硬编码了目标表空间，得翻配置或日志确认真实值
用 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 用户执行，普通用户无法修改自己或其他人的配额
跨用户场景下，配额要分人配
ORA-01950 常在跨用户操作中误判：比如 USER1 的表 T1 上，USER2 创建了索引，而该索引落在 TBS1 表空间 —— 此时报错是 USER2 在 TBS1 没配额，和 USER1 无关。
- 查索引属主：
SELECT owner, tablespace_name FROM dba_indexes WHERE table_name = 'T1' AND table_owner = 'USER1'; - 然后对索引属主（
owner）执行配额授权：ALTER USER USER2 QUOTA UNLIMITED ON TBS1; - 别只盯着报错 SQL 的执行用户，要看所有相关对象（表、索引、LOB段、分区）各自落在哪个表空间、由谁拥有
最易忽略的一点：配额修改后不验证就重跑任务。务必再查一次 dba_ts_quotas，确认 max_bytes 是 -1 或预期值 —— 很多时候是语句拼错用户名或表空间名，导致授权根本没生效。
