ORA-01950根本不是权限问题，而是用户在目标表空间缺乏配额；需通过ALTER USER QUOTA ON tablespace授权，并查dba_ts_quotas验证max_bytes是否为-1或正值，空记录或max_bytes=0均导致失败。
ORA-01950根本不是权限问题，是配额没配
报这个错时，create table、insert 或 create index 失败，不代表用户缺 create any table 这类系统权限。哪怕你 grant connect, resource to user 全给了，只要目标表空间没配额，照样报错。
核心判断依据只有一条：DBA_TS_QUOTAS 里查不到该用户的记录，或者 MAX_BYTES = 0。这不是“权限不足”，而是 Oracle 拒绝在该表空间分配 extent——它连磁盘空间都不让你用。
常见误操作包括：
- 看到报错里有
'USERS'就去GRANT RESOURCE，白忙一场 - 以为用户有默认表空间就自动有配额，其实默认表空间只是“没指定时往哪写”，不等于“能写”
- 用普通用户登录执行
ALTER USER，语句静默失败（必须用SYS或SYSTEM）
怎么确认报错实际用的是哪个表空间？
错误信息里写的表空间名（比如 'K3CLOUD_DATA'、'TBS1'）就是真实目标，别默认只盯 USERS。它可能来自：
- 对象创建时显式指定：
CREATE TABLE t1 (...) TABLESPACE K3CLOUD_DATA - 索引属主不同：用户
USER1的表T1上，USER2创建了索引并指定TABLESPACE TBS1→ 报错是USER2在TBS1没配额 - 迁移工具硬编码：Data Pump 或第三方工具配置里写了
remap_tablespace或默认表空间，得翻日志或配置文件
查法：
SELECT tablespace_name FROM dba_indexes WHERE table_owner = 'USER1' AND table_name = 'T1';
再对查到的 OWNER（不是 TABLE_OWNER）查 DBA_TS_QUOTAS。
ALTER USER QUOTA 怎么写才安全有效？
必须用 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;→ 不是设为零，而是从DBA_TS_QUOTAS中彻底删掉该记录，等同于禁用
切忌用 GRANT UNLIMITED TABLESPACE TO user 替代：它绕过所有表空间级控制，允许往 SYSTEM、SYSAUX 写数据，审计通不过，也容易引发事故。
配额生效后怎么验证？
执行完 ALTER USER 别急着重跑任务，先查：
SELECT tablespace_name, max_bytes FROM dba_ts_quotas WHERE username = 'MCDBA_BAK' AND tablespace_name = 'USERS';
返回结果含义：
-
MAX_BYTES = -1→ 已生效 - 空行 → 语句没执行、用户名拼错、或连错了实例
-
MAX_BYTES = 0→ 配额被显式清空，仍会报错 - 正数（如
10737418240）→ 是 10G，但可能已被耗尽，需结合BYTES字段看已用空间
最容易被忽略的一点：配额是按 username + tablespace_name 组合绑定的，每个组合都要单独确认，不能假设“给了 A 就等于给了 B”。跨用户建索引、迁移导入这类场景，必须分别检查两个用户的配额记录。
