唯一可靠方式是查询 DBA_SYS_PRIVS 视图筛选 PRIVILEGE = 'UNLIMITED TABLESPACE'；DBA_TS_QUOTAS 不记录无限配额，因其仅存储显式设置的配额，而 UNLIMITED TABLESPACE 是系统权限，与表空间配额机制互斥。
不能直接“撤销” UNLIMITED TABLESPACE 权限，必须用 REVOKE 显式收回，且需区分权限类型：是 UNLIMITED TABLESPACE 系统权限，还是针对某个表空间的 QUOTA UNLIMITED 配额。
确认用户到底被授予了哪种“无限”权限
ORA-01950 报错常让人误以为是权限问题，但真正能导致用户往 SYSTEM 表空间写数据的，只有两种可能：
-
GRANT UNLIMITED TABLESPACE TO username—— 这是系统级权限，允许用户在任意表空间（包括 SYSTEM、SYSAUX）创建对象 -
ALTER USER username QUOTA UNLIMITED ON SYSTEM—— 这是配额级授权，只对 SYSTEM 表空间生效，不涉及其他表空间
查清到底是哪一种，才能精准收回：
执行 SELECT privilege FROM dba_sys_privs WHERE grantee = 'MCDBA_BAK' AND privilege = 'UNLIMITED TABLESPACE';，有结果说明是系统权限；
执行 SELECT tablespace_name, max_bytes FROM dba_ts_quotas WHERE username = 'MCDBA_BAK' AND tablespace_name = 'SYSTEM';，若返回 max_bytes = -1，说明是配额级无限。
收回 UNLIMITED TABLESPACE 系统权限
这是最常见也最危险的情况。该权限一旦授予，用户就能在 SYSTEM、SYSAUX 等核心表空间建表、索引甚至物化视图，审计和安全策略通常明令禁止。
必须由 DBA 用户（如 SYS 或 SYSTEM）执行：
REVOKE UNLIMITED TABLESPACE FROM MCDBA_BAK;
注意：
- 收回后，用户在未显式配置
QUOTA的任何表空间都写不了数据（包括默认表空间） - 不会影响已存在的对象，只限制后续 DDL/DML 操作
- 如果用户还需在业务表空间（如
USERS）工作，必须补上对应配额：ALTER USER MCDBA_BAK QUOTA UNLIMITED ON USERS;
收回 SYSTEM 表空间上的 QUOTA UNLIMITED 配额
这种情况较少见，但更隐蔽：用户没被给 UNLIMITED TABLESPACE，却单独在 SYSTEM 上被配了无限配额。
收回方式不是 REVOKE，而是把配额设为 0 或删掉记录：
ALTER USER MCDBA_BAK QUOTA 0 ON SYSTEM;
或更彻底地移除配额（等效于没配过）：
ALTER USER MCDBA_BAK QUOTA 0 ON SYSTEM; —— 注意：Oracle 中 QUOTA 0 会从 dba_ts_quotas 中删除该行，不是“保留零配额”，而是“彻底无配额”
验证是否生效：
SELECT * FROM dba_ts_quotas WHERE username = 'MCDBA_BAK' AND tablespace_name = 'SYSTEM'; 应返回空行
为什么不能只靠 ALTER USER QUOTA 0 来替代 REVOKE？
因为二者作用域完全不同：
-
REVOKE UNLIMITED TABLESPACE解除的是“跨所有表空间的写入自由”，哪怕你在SYSTEM上没配过QUOTA，只要这个权限在，用户仍可建对象 -
ALTER USER ... QUOTA 0 ON SYSTEM只封死SYSTEM这一个表空间，对其他表空间（如SYSAUX）完全无效 - 如果用户同时拥有
UNLIMITED TABLESPACE和QUOTA UNLIMITED ON SYSAUX，只改SYSTEM配额毫无意义
生产环境里，真正该被禁用的是 UNLIMITED TABLESPACE 这个系统权限；对 SYSTEM 表空间单独配额本身就不该存在——它本就不是用来存业务对象的地方。
