ORA-01536错误本质是用户表空间配额耗尽而非磁盘满，需通过ALTER USER调整QUOTA（如QUOTA UNLIMITED ON tablespace），并确保配额施加于实际写入的表空间。
ORA-01536错误本质是配额耗尽，不是磁盘满
ORA-01536报错时，数据库实例本身可能还有大量空闲空间，甚至dba_free_space显示表空间剩余充足。真正卡住的是「用户对该表空间的配额」——即 Oracle 强制限制该用户最多能用多少空间，跟物理容量无关。常见于 Navicat 导入、批量插入、建表或索引时突然失败。
-
max_bytes = 0表示该用户在该表空间上完全没配额（禁止写入） -
max_bytes = -1表示配额无限（QUOTA UNLIMITED） -
max_bytes > 0是具体字节数，比如10485760就是 10MB - 查当前用户配额：执行
SELECT * FROM user_ts_quotas; - 查所有用户配额（需 DBA 权限）：执行
SELECT * FROM dba_ts_quotas WHERE username = 'YOUR_USER';
用ALTER USER快速解除配额限制
最直接有效的解法是提升或取消用户在目标表空间上的配额。注意必须用有ALTER USER权限的账号（如SYS、SYSTEM）执行，不能用报错的业务用户自己操作。
- 设为无限制（推荐）：
ALTER USER your_user QUOTA UNLIMITED ON your_tablespace; - 设为固定大小（适合管控场景）：
ALTER USER your_user QUOTA 5G ON your_tablespace; - 表空间名区分大小写？如果创建时用了双引号（如
"HOME-A"），这里也必须加双引号 - 执行后立即生效，无需重启实例或刷新连接
- 若提示权限不足，确认执行账号是否被授予
ALTER ANY USER或属于DBA角色
别混淆QUOTA和UNLIMITED TABLESPACE权限
GRANT UNLIMITED TABLESPACE TO user; 看似等价，但它是全局授权，绕过所有表空间配额检查——风险更高，且在 Oracle 12c 及以后版本中，该权限默认不授予普通用户，也不建议轻易开放。
-
QUOTA UNLIMITED ON xxx：只放开指定表空间，最小权限原则 -
UNLIMITED TABLESPACE：允许用户在任意表空间（包括SYSTEM、SYSAUX）无限制使用，易引发系统表空间膨胀 - 回收配额用：
ALTER USER your_user QUOTA 0 ON your_tablespace; - 回收全局权限用：
REVOKE UNLIMITED TABLESPACE FROM your_user;
Navicat导入失败时要核对三件事
即使配额已调高，Navicat 仍可能因配置错位继续报 ORA-01536。关键不是“有没有空间”，而是“以谁的身份、往哪个表空间、走哪条路径写入”。
- 确认 Navicat 连接使用的用户名，和你修改配额的用户名一致（大小写、连接串中的
as sysdba会切换上下文） - 查该用户的默认表空间：
SELECT default_tablespace FROM dba_users WHERE username = 'YOUR_USER';，确保配额已加在默认表空间上 - 查建表/导入时显式指定了哪个表空间（如
CREATE TABLE t (...) TABLESPACE "TBSLOG";），配额必须加在那个表空间上，不是默认表空间 - Navicat 导入设置里勾选了「在目标表空间中创建对象」？如果目标表空间不是用户默认表空间，就得单独给那个表空间授配额
配额设置是 per-user + per-tablespace 的二维控制，容易漏掉某个组合；dba_ts_quotas 查出来的每行都代表一个独立约束，少一行就可能卡死一次写入。
