UNLIMITED TABLESPACE权限仅跳过配额检查，不解决表空间OFFLINE/READ ONLY状态、PDB内未显式授权、大小写敏感导致的表空间名不匹配、Oracle Vault或审计策略拦截等问题。
unlimited tablespace 权限本身没失效，但它的作用被其他条件覆盖或绕过——它不解决表空间状态、配额元数据缺失、pdb隔离、大小写敏感匹配失败等实际拦路问题。
UNLIMITED TABLESPACE 在 PDB 中不自动生效
如果你在 CDB 级别执行了 GRANT UNLIMITED TABLESPACE TO user_name，但用户连的是某个 PDB，那这条权限在该 PDB 内完全不可见。Oracle 不向下继承这个系统权限。
- 必须在目标 PDB 内重新执行授权：
ALTER SESSION SET CONTAINER = pdb_name;后再GRANT UNLIMITED TABLESPACE TO user_name - 查不到
DBA_SYS_PRIVS记录 ≠ 授权失败，可能只是你当前连接的容器不对 -
SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM DUAL确认当前所在容器名
表空间处于 OFFLINE 或 READ ONLY 状态
UNLIMITED TABLESPACE 只跳过配额检查，不绕过表空间本身的可用性校验。如果建索引语句指定了 TABLESPACE TBS_IDX，而该表空间是 OFFLINE 或 READ ONLY，照样报 ORA-01950 或 ORA-01691。
- 查状态：
SELECT tablespace_name, status, contents FROM dba_tablespaces WHERE tablespace_name = 'TBS_IDX' -
OFFLINE需 DBA 执行ALTER TABLESPACE TBS_IDX ONLINE -
READ ONLY需先改为READ WRITE（注意业务影响） - 临时表空间（
TEMP）即使设了 unlimited，若状态异常也会导致排序失败
大小写敏感导致表空间名匹配失败
当数据库启用了 SEC_CASE_SENSITIVE_LOGON=TRUE（或兼容模式设为 12c+），表空间名区分大小写。TBS_IDX 和 tbs_idx 被视为两个不同对象，配额、权限、甚至 UNLIMITED TABLESPACE 的作用范围都互不覆盖。
- 建索引时写的
TABLESPACE tbs_idx，但 DBA 配的是TBS_IDX→ 查DBA_TS_QUOTAS没记录，报错 - 查用户默认表空间：
SELECT default_tablespace FROM dba_users WHERE username = 'YOUR_USER'，注意返回值大小写 - 统一用大写确认：所有 DDL 中显式指定的表空间名，应与
DBA_TABLESPACES.TABLESPACE_NAME完全一致
安全策略或 Vault 主动拦截该权限
Oracle Vault、统一审计策略（Unified Audit）、或自定义细粒度访问控制（FGAC）规则，可能直接禁用 UNLIMITED TABLESPACE 的实际效果——即使 DBA_SYS_PRIVS 里有记录，执行建表/建索引时仍被拒绝。
- 查是否启用 Vault：
SELECT * FROM V$OPTION WHERE PARAMETER = 'Oracle Database Vault' - 查审计策略是否覆盖：
SELECT policy_name, enabled FROM dba_audit_policy_columns WHERE object_name = 'UNLIMITED TABLESPACE' - 这类拦截通常不返回标准 ORA 错误，而是
ORA-47401（Vault）或ORA-01031（权限不足），需结合DBA_AUDIT_TRAIL分析
最常被忽略的是：UNLIMITED TABLESPACE 不等于“能往任意表空间写”，它只是一把跳过配额检查的钥匙——门锁（表空间状态）、门牌号（大小写匹配）、门禁系统（Vault/审计）都得单独通关。漏掉任一环，就卡在 ORA-01950 上，和权限本身是否授予无关。
