ora-01950 根本原因是用户在目标表空间缺乏磁盘配额，而非权限不足；需根据错误中明确指出的表空间名（如'users'），用dba账号查dba_ts_quotas确认配额状态，并执行alter user ... quota ... on 精准授权。
ORA-01950 不是权限问题，是配额缺失 —— 用户在目标表空间没被分配磁盘空间额度，哪怕 GRANT CONNECT, RESOURCE TO user 全给了，照样报错。
查清楚报错时实际用的是哪个表空间
错误信息里写的表空间名（比如 'USERS'、'K3CLOUD_DATA'、'TBS_IDX'）就是关键线索。它不一定是用户的默认表空间，而是对象创建或数据写入时真正落盘的那个空间。
- 建表没指定
TABLESPACE？看用户默认表空间：SELECT default_tablespace FROM dba_users WHERE username = 'MCDBA_BAK'; - 但建索引报错？查索引语句里写的
TABLESPACE，再查该索引属主：SELECT owner, tablespace_name FROM dba_indexes WHERE index_name = 'IDX_NAME'; - 迁移工具或应用可能硬编码了表空间名，得翻日志或配置确认真实值，别只盯
USERS
用 dba_ts_quotas 确认配额状态
必须用 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 user 能绕过 ORA-01950，但它允许用户往 SYSTEM、SYSAUX 等核心表空间无限写入，生产环境审计通不过，也容易引发事故。
- 安全做法是精准控制：
ALTER USER MCDBA_BAK QUOTA UNLIMITED ON USERS; - 若需限制，单位支持
K/M/G：ALTER USER TESTUSER QUOTA 50G ON K3CLOUD_DATA; -
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（即USER2）执行ALTER USER ... QUOTA ... ON ... - 如果索引分散在多个表空间（如主键在
TBS_IDX、函数索引在TBS_FUN），每个都得单独配
最容易被忽略的点是：错误信息里写的表空间名，必须一字不差地用于 ALTER USER ... ON <tablespace_name></tablespace_name> —— 数据库若启用了大小写敏感（如 SEC_CASE_SENSITIVE_LOGON=TRUE 或表空间名带双引号），tbs_idx 和 TBS_IDX 就是两个不同空间。
