临时表空间组是负载分担机制而非性能加速器，仅通过分散多会话I/O压力降低单点瓶颈，需至少两个临时表空间组成且依赖新会话生效，无法解决SQL或PGA配置缺陷导致的频繁落盘。
临时表空间组不是性能加速器，而是负载分担机制
临时表空间组本身不提升单条SQL的排序速度，它只解决多个会话争抢同一临时文件导致的I/O排队问题。当大量并发排序操作（比如报表批处理、ETL任务）集中写入同一个TEMP表空间时，所有会话都往同一个tempfile里追加块，容易出现direct path write/temp等待事件堆积。组的作用是把压力分散到多个物理文件上，降低单点I/O瓶颈。
创建临时表空间组并分配给用户的关键步骤
必须先有至少两个独立的临时表空间，才能组成组；不能直接对已有TEMP表空间“升级”为组。
- 创建新临时表空间（注意
UNIFORM SIZE建议设为1M或4M，避免小extent碎片）：CREATE TEMPORARY TABLESPACE temp2 TEMPFILE '/u01/oradata/orcl/temp2_01.dbf' SIZE 500M AUTOEXTEND ON NEXT 50M MAXSIZE 2G EXTENT MANAGEMENT LOCAL UNIFORM SIZE 4M;
- 将已有和新建的临时表空间加入同一组：
ALTER TABLESPACE temp1 TABLESPACE GROUP temp_grp; ALTER TABLESPACE temp2 TABLESPACE GROUP temp_grp;
- 把用户切换到该组（非系统用户）：
ALTER USER app_user TEMPORARY TABLESPACE temp_grp;
- 验证是否生效：
SELECT username, temporary_tablespace FROM dba_users WHERE username = 'APP_USER';
结果应显示temporary_tablespace列为temp_grp，而非具体表空间名
为什么ALTER TABLESPACE ... TABLESPACE GROUP后没生效？
常见失效原因不是语法错，而是会话级缓存未刷新或权限不足：
- 用户当前会话已建立连接，
ALTER USER只影响后续新会话，老连接仍用旧临时表空间；需重连或执行ALTER SESSION SET CURRENT_SCHEMA = ...触发重评估（但不保证立即切换） - 执行
ALTER USER的账号必须有ALTER USER权限，且目标用户不能是SYS或SYSTEM（Oracle禁止修改其临时表空间为组） - 组名大小写敏感，
temp_grp和TEMP_GRP被视为不同组；查询dba_tablespaces确认CONTENTS为TEMPORARY且TABLESPACE_GROUP列非空 - 如果只把一个表空间加入组，Oracle仍会把它当普通表空间用——组至少需要两个成员才真正启用负载分担逻辑
临时表空间组无法掩盖SQL或PGA配置缺陷
即使配置了多文件组，若SQL本身存在全表扫描+大范围GROUP BY，或PGA_AGGREGATE_TARGET过小，排序仍会频繁落盘。此时看到的现象是：多个tempfile使用率同步上涨，v$sql_workarea中multipasses_executions持续非零，v$pgastat里cache hit percentage低于60%。
这类情况必须同步做三件事：ALTER SYSTEM SET pga_aggregate_target=2G SCOPE=BOTH、检查ORDER BY字段是否有索引、用DBMS_XPLAN.DISPLAY_CURSOR确认执行计划是否含SORT ORDER BY且Bytes列远超内存预估。
