表空间配额（quota）与schema级权限正交独立：quota控制用户在指定永久表空间创建对象的空间上限（如quota 5m on users），未显式设置即默认为0（禁止写入）；而schema权限（如select any table on schema hr）仅管控数据访问，不影响存储资源分配，且配额不继承、不传递，必须为用户单独显式授予。
Schema-level privileges 本身不影响表空间配额——这是两个正交的权限/资源控制机制，混淆它们是 Oracle 权限配置中最常见的认知偏差之一。
表空间配额（Quota）和 Schema 权限（如 SELECT ANY TABLE ON SCHEMA）完全独立
-
QUOTA控制的是「用户能在哪个表空间里创建对象、最多占多少空间」，属于存储资源分配范畴 -
SELECT ANY TABLE ON SCHEMA HR控制的是「用户能否读取 HR 模式下所有当前及未来表的数据」，属于数据访问控制范畴 - 授予前者不自动赋予后者，反之亦然；两者不会互相触发、叠加或覆盖
常见误操作场景：以为授了 Schema 权限就能建表或查新表，结果报错
典型错误现象：ORA-01950: no privileges on tablespace 'USERS' 或 ORA-00942: table or view does not exist，但你明明刚执行了 GRANT SELECT ANY TABLE ON SCHEMA HR TO BOB
- 查不到表？先确认该表真在
HR下：SELECT owner, object_name FROM all_objects WHERE object_type = 'TABLE' AND object_name = 'EMPLOYEES' - 能连上但不能建同义词/视图？不是权限不够，而是
BOB在USERS表空间没配额：ALTER USER BOB QUOTA 10M ON USERS - 想让
BOB查询HR表，但又希望他自己的临时对象（比如全局临时表、物化视图日志）也存得下？必须单独配额：ALTER USER BOB QUOTA UNLIMITED ON TEMP和QUOTA 50M ON INDEX_TS
配额必须显式授予，且只对「用户自身模式」生效
注意：GRANT SELECT ANY TABLE ON SCHEMA HR TO BOB 不会让 BOB 获得 HR 用户在 USERS 表空间的配额——HR 的配额只影响 HR 自己建对象，和 BOB 无关。同样，BOB 的配额也只管 BOB 自己建的对象（比如他建的同义词、临时表），不管他查谁的表。
配额不传递、不继承、不隐含，哪怕你是 DBA 角色，只要没在目标表空间上被授过 QUOTA，就无法在那个表空间建任何持久对象。
Java 应用中容易忽略的配额陷阱
Spring Boot 启动时若执行 schema.sql 或 JPA ddl-auto=create，会尝试在 spring.datasource.username 对应用户的默认表空间建表——这时如果该用户没配额，就会卡在初始化阶段，报错却未必提示“quota”，而是模糊的 ORA-01950 或连接超时。
- 检查当前用户配额：
SELECT username, tablespace_name, bytes/1024/1024 AS mb FROM dba_ts_quotas WHERE username = 'BOB' - 开发环境建议给测试用户配额：
ALTER USER BOB QUOTA UNLIMITED ON USERS（生产环境请按需限制） - HikariCP 连接池初始化失败？别只盯
password或url，先查配额是否到位
表空间配额是硬性资源边界，Schema 级权限是软性访问策略。两者必须分别确认、分别管理——漏掉任何一个，应用都可能在看似“权限已全”的情况下突然中断。
