必须显式配置quota才能限制用户空间使用，default和temporary表空间需分别设限；回收站对象计入配额，需定期purge；Resource Manager与profile组合可实现速度与总量双重管控。
直接结论：靠默认设置无法防止，必须显式配 quota，且需对 default tablespace 和 temporary tablespace 分别设限。
创建用户时没设 quota 就等于开闸放水
Oracle 默认允许用户在指定表空间中无限制使用空间（unlimited），哪怕只给 1MB 配额，只要没显式声明，就是无限。常见错误是只写 create user u1 identified by p1 default tablespace users;，漏掉 quota 子句——这等同于授予该用户对 users 表空间的完全写权限。
- 必须明确指定配额，例如：
quota 100M on users或quota 0 on users（彻底禁用） - 临时表空间（
temporary tablespace）不走quota控制，而是由sort_area_size、pga_aggregate_limit等内存参数间接约束；若需硬限，得配合 Resource Manager 使用consumer_group - 注意：
unlimited是关键字，不是数值，写成quota unlimited on users就是放行；想禁用必须写quota 0 on users
alter user 动态调整配额但不立即释放已占空间
用户已占用 5GB，你执行 alter user u1 quota 100M on users;，Oracle 不会自动清理超出部分——它只阻止后续 INSERT/CREATE 等写操作报 ORA-01536（超出配额）。已占空间仍计入表空间使用率，DBA 需手动清理（如 truncate 大表、drop 无用对象）。
- 检查当前配额：查
dba_ts_quotas视图，重点关注max_bytes和bytes字段 - 批量重置：可用脚本生成
alter user ... quota 0 on xxx语句，适用于清理测试用户或离职账号 - 风险点：对
sys、system用户设quota 0可能导致系统包编译失败，切勿操作
回收站对象也计入用户配额，容易被忽略
用户执行 drop table t1 后，该对象进入回收站，名字变成 bin$xxx，但它仍归属原用户、仍占用其 users 表空间配额。长期不清理，user_recyclebin 可能吃掉 20%+ 配额，导致新表建不起来却查不到“大表”。
- 定期清空：应用层应要求开发在 drop 后主动执行
purge recyclebin - 自动化：可建 JOB 每日凌晨运行
purge user_recyclebin（仅影响当前用户） - 监控预警：在巡检脚本中加入查询
select sum(bytes) from user_recyclebin，超阈值告警
真正兜底：Resource Manager + profile 组合限流
仅靠 quota 只控空间量，不管空间消耗速度。高并发批量插入或排序操作可在秒级耗尽配额。此时需叠加 Resource Manager 限制并行度与 PGA 使用。
- 创建 consumer group 并绑定 profile，例如限制
active_session_pool和parallel_degree_limit - 关键参数：
pga_aggregate_limit（实例级总 PGA 上限）和private_sga（单会话 SGA 上限）会影响排序临时段生成量 - 注意：Resource Manager 对
sys用户默认无效，需显式启用并排除特权用户
最易被忽视的点是回收站对象持续计入配额，且 purge recyclebin 不在事务控制内——它不写 redo、不占 undo，但执行后空间释放有延迟（依赖 SMON 清理），监控时看到 dba_free_space 没立刻上涨属正常现象。
