oracle无法直接限制单个session的临时表空间用量，因temp表空间不支持quota机制，alter user ... quota on temp语法无效；只能通过resource manager控制并发、执行时长等间接手段，或从sql层面识别高temp消耗操作进行优化。
oracle 没有直接限制单个 session 临时表空间用量的参数或语法——alter session 或 create user 都不支持类似 temp_quota 这样的配置项。所谓“限制”，只能靠间接手段实现，且效果取决于实际执行场景。
为什么无法直接设置 per-session TEMP quota
Oracle 的临时表空间（TEMP）设计上不支持配额（QUOTA），这和永久表空间完全不同。你给用户分配 UNLIMITED TABLESPACE 或只给 CREATE TABLE 权限，都跟临时段使用无关；临时段由 PGA 内存溢出触发，由实例级资源管理器（DBMS_RESOURCE_MANAGER）或 SQL 执行计划本身控制，不是按用户/会话做存储配额的。
常见误解是以为 ALTER USER ... QUOTA ON TEMP 能生效——它根本不存在，语法报错：ORA-02223: invalid ALTER TABLESPACE option。
可用的间接控制方式：Resource Manager plan
唯一接近“限制单 session 临时空间”的官方机制是数据库资源管理器（DBMS_RESOURCE_MANAGER），通过为会话指定 consumer group 并设置 active_session_pool_p1 和 max_est_exec_time 等参数，间接压制高消耗 SQL 的执行。
-
active_session_pool_p1：限制该组最多并发活跃会话数，防堆积 -
max_est_exec_time：对预估执行时间超长的 SQL 直接中止（依赖 CBO 统计信息准确） -
parallel_degree_limit_p1：限制并行度，而并行操作是 TEMP 消耗大户 - 必须配合
SWITCH_GROUP或SWITCH_TIME才能在运行时生效，不是静态限制
注意：DBMS_RESOURCE_MANAGER 不监控或限制 tempseg_size 字节数，它只管 CPU、并行度、执行时长等维度。一个排序 SQL 即使只用 1MB 临时空间但跑了 2 小时，也会被 max_est_exec_time 拦截；反过来，一个 5 秒内刷了 20GB 到 TEMP 的 SQL，若预估时间短，就完全逃逸管控。
真正有效的拦截点：从 SQL 层面掐住源头
与其试图限制 session，不如在 SQL 执行前识别并阻断高 TEMP 消耗行为。关键看 V$SQL_WORKAREA 中的指标：
-
number_passes > 1：表示工作区多次往返磁盘，性能已严重劣化，必须优化 -
tempseg_size值巨大（如 > 100MB）：说明该 SQL 累计写入 TEMP 很多，不是瞬时占用，而是真实 IO 压力源 -
actual_mem_used远小于estimated_optimal_size：说明 PGA 设置过小或统计信息不准，导致本可内存完成的操作被迫落盘
示例查询（找 top 5 最耗 TEMP 的 SQL）：
SELECT w.sql_id, w.operation_type, w.tempseg_size, w.number_passes,
s.sql_text
FROM v$sql_workarea w
JOIN v$sql s ON w.sql_id = s.sql_id
WHERE w.tempseg_size > 104857600
ORDER BY w.tempseg_size DESC
FETCH FIRST 5 ROWS ONLY;
查到后，用 DBMS_SQLTUNE 分析执行计划，重点检查是否缺失索引、是否用了 ORDER BY / GROUP BY 大字段、是否 UNION ALL 被误写成 UNION 导致去重排序。
容易被忽略的细节：TEMP 文件 autoextend + 无监控 = 隐形失控
很多 DBA 以为设置了 AUTOEXTEND ON MAXSIZE 10G 就安全了，但没意识到：MAXSIZE 是单个 tempfile 的上限，而一个表空间可以有多个 tempfile；更关键的是，v$sort_usage 只反映当前占用，v$sql_workarea 又只记录已执行完的工作区——中间态的、正在写的临时段既不显示在 v$sort_usage，也不进 v$sql_workarea，直到 SQL 结束才累计。这意味着：一次大 SQL 执行中，TEMP 使用率可能瞬间冲到 95%，但监控脚本却查不到任何“异常会话”。
