最安全可控的方式是用ALTER USER ... QUOTA UNLIMITED ON指定表空间，而非GRANT UNLIMITED TABLESPACE；因后者绕过所有表空间级控制，允许用户向SYSTEM、SYSAUX等关键表空间无限写入，易引发事故且审计不通过。
直接给新用户分配无限表空间配额，最安全、最可控的方式是用 ALTER USER ... QUOTA UNLIMITED ON ，而不是授予 UNLIMITED TABLESPACE 系统权限。
为什么不用 GRANT UNLIMITED TABLESPACE？
这个系统权限会绕过所有表空间级配额检查，影响范围是全局的——用户能往 SYSTEM、SYSAUX、USERS 等所有永久表空间里写数据，包括你不希望普通用户碰的系统表空间。一旦误操作或被利用，可能直接撑爆关键表空间，甚至引发数据库不可用。
常见错误现象：
- DBA 在
DBA_TS_QUOTAS里查不到该用户的记录（因为配额机制被跳过了） - 撤权限时必须用
REVOKE UNLIMITED TABLESPACE FROM user;，不能靠ALTER USER ... QUOTA 0清除效果 - RESOURCE 角色默认附带
UNLIMITED TABLESPACE，新建用户若被授了 RESOURCE，实际已获得该权限，但你可能没意识到
正确做法：ALTER USER QUOTA UNLIMITED ON 指定表空间
这是表空间粒度的“无限”，只对目标表空间生效，不越界，也留有后续调整余地。
典型使用场景：
- 应用账号需要在
DATA表空间无限制建表/分区，但严禁碰SYSTEM - ETL 用户需大量加载数据到专用表空间
STAGE，但其他表空间保持严格配额 - 测试环境快速验证大容量场景，又不想改权限模型
执行示例：
ALTER USER app_user QUOTA UNLIMITED ON DATA;
注意点：
- 必须确保
DATA表空间存在且状态为ONLINE - 表空间名大小写敏感：如果创建时用了双引号如
"Data"，这里也得写成"Data" - 该语句不会报错，但若执行者没有
ALTER USER权限，会返回ORA-01950
CREATE USER 时能否直接设 unlimited quota？
不能。标准 CREATE USER 语法不支持 QUOTA UNLIMITED 子句；它只接受具体数值（如 QUOTA 500M）或省略（即默认 0）。所以必须分两步：
- 先
CREATE USER（可指定DEFAULT TABLESPACE） - 再
ALTER USER ... QUOTA UNLIMITED ON
例如：
CREATE USER report_user IDENTIFIED BY pwd123 DEFAULT TABLESPACE REPORTS TEMPORARY TABLESPACE TEMP;<br>ALTER USER report_user QUOTA UNLIMITED ON REPORTS;
别漏掉第二步——否则用户连建空表都会报 ORA-01950。
查配额和验证是否生效
配额不是“设完就完”，得立刻确认是否落到视图里：
SELECT tablespace_name, max_bytes FROM dba_ts_quotas WHERE username = 'REPORT_USER';
如果 max_bytes 是 -1，说明已生效；如果是 0 或空行，说明没设成功，或者被 UNLIMITED TABLESPACE 权限覆盖了（此时 DBA_TS_QUOTAS 里压根不显示记录）。
容易忽略的一点：配额检查发生在段扩展瞬间（比如第一次 INSERT 触发数据段分配），不是登录时校验。所以即使配额设错了，用户也能正常连接、查询，直到真正写数据才失败。
