ORA-01950或ORA-01536报错源于用户在目标表空间无配额，需用ALTER USER...QUOTA显式分配；刚创建用户建表即报错因Oracle 12c默认不设配额，即使已授CREATE TABLE权限。
ora-01950 或 ora-01536 报错，不是权限没给够，而是用户在目标表空间压根没配额——必须用 alter user ... quota 显式分配，grant 任何对象权限都无效。
为什么刚创建的用户建表就报 ORA-01950？
Oracle 12c 默认不给新用户任何表空间配额，哪怕你已执行 GRANT CREATE TABLE TO user;。建表时 Oracle 会检查该用户在目标表空间（如 USERS）是否有可用配额，查 DBA_TS_QUOTAS 会发现该用户记录为空或 MAX_BYTES = 0。
常见触发点：
- 在 PDB 中用
CREATE USER创建普通用户后，未同步执行ALTER USER ... QUOTA - 用户默认表空间是
USERS，但 DDL 中显式写了TABLESPACE K3CLOUD_DATA，而你只给USERS加了配额 - 从 CDB 级创建用户（带
C##前缀）后切到 PDB 操作，配额需在对应 PDB 内单独设置
QUOTA UNLIMITED 是最直接的解法，但必须指定表空间
别用 GRANT UNLIMITED TABLESPACE TO user; —— 它允许用户往 SYSTEM、SYSAUX 等关键系统表空间写数据，审计和安全策略通常禁止此操作。
正确做法是精准授权：
-
ALTER USER scott QUOTA UNLIMITED ON USERS;—— 只放开USERS表空间，不影响其他表空间配额 -
ALTER USER app_user QUOTA 5G ON K3CLOUD_DATA;—— 单位必须带G（不能只写5），大小写不敏感但表空间名要和DBA_TABLESPACES.TABLESPACE_NAME完全一致 -
ALTER USER testuser QUOTA 0 ON USERS;—— 彻底禁用该用户在此表空间建段，适合临时隔离
注意：QUOTA UNLIMITED 在 DBA_TS_QUOTAS 中对应 MAX_BYTES = -1，不是空值或 NULL。
执行后仍报错？先查这三件事
配额语句执行成功 ≠ 配额立即生效于当前会话，尤其在跨 PDB 或连接串未指定服务名时容易误判：
- 确认当前连接的是哪个容器：
SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL;—— 必须在目标 PDB 内执行ALTER USER - 验证配额是否写入：
SELECT tablespace_name, max_bytes FROM DBA_TS_QUOTAS WHERE USERNAME = 'SCOTT';—— 若无返回，说明语句执行错库或用户名拼写错误 - 检查建表语句是否隐式指定了表空间：
CREATE TABLE t1 (...) TABLESPACE EXAMPLE;，此时需给EXAMPLE而非默认表空间加配额
生产环境别依赖 UNLIMITED，配额监控要进例行脚本
真正需要长期运行的应用账号，应设合理上限而非无限制。把下面这个查询加入每日巡检：
SELECT username, tablespace_name,
ROUND(bytes/1024/1024) AS used_mb,
CASE WHEN max_bytes = -1 THEN 'UNLIMITED'
ELSE ROUND(max_bytes/1024/1024) END AS quota_mb
FROM DBA_TS_QUOTAS
WHERE max_bytes != -1 AND bytes >= max_bytes * 0.85;它能提前发现配额使用超 85% 的账号。另外，USER_TS_QUOTAS 只显示当前登录用户的配额，排查他人问题必须用 DBA_TS_QUOTAS —— 这个视图权限常被忽略，导致反复连错账号查不到数据。
