需select_catalog_role或dba角色权限；查指定用户配额需where username='scott' and tablespace_name='users'，注意字段名和大小写；查不到记录可能因配额为0、未分配、有unlimited tablespace权限或查临时表空间。
查 dba_ts_quotas 需要什么权限
直接执行 select * from dba_ts_quotas 报错 ora-00942: table or view does not exist，大概率是当前用户没被授予 select_catalog_role 或 dba 角色。普通用户默认看不到这个视图，哪怕自己查自己的配额也不行。
确认权限的最快方式是让 DBA 执行：
GRANT SELECT_CATALOG_ROLE TO your_user;
或者更精确地只授查询权：
GRANT SELECT ON DBA_TS_QUOTAS TO your_user;
注意：DBA_TS_QUOTAS 是数据字典视图，不建议用 SELECT ANY DICTIONARY 这种宽泛权限替代。
查指定用户的表空间配额怎么写 SQL
核心就是过滤 USERNAME 和 TABLESPACE_NAME 字段。常见错误是拼错字段名（比如写成 USER_NAME 或 TS_NAME），或忽略大小写——Oracle 默认用户名和表空间名都是大写的。
-
USERNAME：必须大写，如'SCOTT' -
MAX_BYTES：配额字节数，-1表示 unlimited -
BYTES：已用字节数（注意不是实时值，依赖最近一次空间统计） - 查不到记录 ≠ 没配额，可能是配额为 0 或者该用户在该表空间下还没被显式分配过配额
示例（查用户 SCOTT 在 USERS 表空间的配额）：
SELECT TABLESPACE_NAME, BYTES, MAX_BYTES, BLOCKS, MAX_BLOCKS FROM DBA_TS_QUOTAS WHERE USERNAME = 'SCOTT' AND TABLESPACE_NAME = 'USERS';
为什么查不到配额？几种典型原因
即使有权限、SQL 写对了，也可能返回空结果。这不是 bug，而是 Oracle 的配额机制决定的：
- 用户创建时没指定默认表空间，且未手动用
ALTER USER ... QUOTA ... ON ...分配过配额 - 配额设为
0（即禁止使用），此时记录不会出现在DBA_TS_QUOTAS中 - 用户被赋予了
UNLIMITED TABLESPACE系统权限——这时配额视图里也不会显示记录，因为已绕过配额检查 - 查询的是临时表空间（
TEMP）：临时表空间不走配额机制，DBA_TS_QUOTAS里不会有对应行
验证是否拥有无限权限：
SELECT * FROM DBA_SYS_PRIVS WHERE GRANTEE = 'SCOTT' AND PRIVILEGE = 'UNLIMITED TABLESPACE';
配额单位和实际占用的关系
BYTES 和 MAX_BYTES 是以字节为单位，但 Oracle 实际分配空间时按 extent（区）进行，而 extent 大小取决于表空间的 INITIAL 和 NEXT 参数。这意味着：
- 即使
MAX_BYTES是 1MB，只要一个 segment 需要的初始 extent 超过 1MB，插入就会失败 -
BYTES值滞后于真实磁盘占用，它反映的是数据字典中最后一次更新的段大小，不是实时 OS 层文件大小 - 如果用户对象被
TRUNCATE或DROP，BYTES不会立即清零，需等 SMON 进程清理或手动执行DBMS_SPACE_ADMIN.TABLESPACE_REBUILD_QUOTAS
想看更准的已用空间，可结合 DBA_SEGMENTS：
SELECT SUM(BYTES) FROM DBA_SEGMENTS WHERE OWNER = 'SCOTT' AND TABLESPACE_NAME = 'USERS';
配额逻辑本身不复杂，但容易混淆“没记录”“配额为 0”“无限权限”这三种状态；真正出问题时，往往卡在权限和隐式行为上，而不是 SQL 写法。
