如何优化Oracle临时表空间组_TEMPORARY TABLESPACE GROUP负载均衡

oracle临时表空间组不自动负载均衡，因session登录时通过哈希算法绑定固定表空间且不切换；RAC中各实例无法感知其他节点空闲度，需为每实例单独指定默认临时表空间。

临时表空间组里多个表空间为什么还是不均衡？

oracle 的 temporary tablespace group 本身不自动做负载均衡——它只是把多个临时表空间“打包”供用户或实例使用，实际分配由 session 初始化时的内部哈希算法决定，不是轮询也不是最小使用率优先。

常见错误现象：select * FROM V$sort_SEGMENT 显示某个表空间的 USED_EXTENTS 持续远高于其他成员；V$TEMPSEG_USAGE 中大量 session 都挤在同一个 TABLESPACE_NAME 下。

• 使用场景：RAC 环境下多实例共用同一组、或单实例高并发排序/哈希连接/全局临时表写入密集时最明显
• 根本原因：每个 session 在登录时就绑定到组内某个临时表空间（基于 user + instance + hash），后续整个生命周期都固定用它，不会动态切换
• 参数差异：ALTER database default TEMPORARY TABLESPACE 设的是默认表空间，不是组；组只是扩展能力，不改变分配逻辑

怎么让新 session 更均匀落到不同临时表空间？

靠调整组内成员的“权重”没用（Oracle 不支持），真正有效的是控制组内各表空间的 INITIAL_EXTENT 和 NEXT_EXTENT —— Oracle 内部哈希会倾向选择“更空闲”的 segment header，而空闲程度受 extent 分配路径影响。

实操建议：

• 确保组内所有临时表空间都启用了 UNIFORM SIZE，且 size 一致（例如都设为 1M）：CREATE TEMPORARY TABLESPACE temp1 TEMPFILE '/u01/oradata/db/temp1.dbf' SIZE 1G EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M
• 避免混用 UNIFORM 和 AUTOALLOCATE，后者会导致 segment header 分布不均，加剧哈希倾斜
• 重建临时表空间前，先清空所有依赖它的 session：SELECT SID, SERIAL#, USERNAME FROM V$SESSION WHERE TEMPSEG_USAGE > 0，否则 DROP TABLESPACE 会报 ORA-12906

RAC 环境下临时表空间组要特别注意什么？

RAC 中每个 instance 默认只管自己的 TEMP 表空间，即使加进 group，其他节点也看不到它的 segment header 状态——所以跨节点的“感知式均衡”根本不存在。

典型问题：ORA-01652: unable to extend temp segment 只在某一个节点频繁出现，其他节点的同组表空间却很空闲。

• 必须为每个 instance 单独指定本地临时表空间：ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp1 INSTANCE 'inst1'
• 组的作用仅限于 sql 解析阶段的权限检查（比如用户被授予 temp_group_name），运行时仍走本实例绑定的表空间
• 监控不能只看 V$SORT_SEGMENT，得按 INST_ID 分组查：SELECT INST_ID, TABLESPACE_NAME, USED_EXTENTS FROM GV$SORT_SEGMENT

什么时候该放弃组、改用单表空间+大文件？

当你的 workload 主要是短时、高并发、小排序（比如 OLTP 中大量 ORDER BY 或 GROUP BY），临时段创建销毁极快，此时组带来的管理开销反而掩盖了收益。

性能影响比你想象中更直接：

• 每个临时表空间对应独立的 sort_segment latch，组内成员越多，latch 争用越可能从 cache buffers chains 波及到 sort extent pool
• ALTER TABLESPACE ... ADD TEMPFILE 动态扩容在组内各成员上不同步，容易导致某一个先满
• 备份恢复时，RMAN 对组内每个 tempfile 单独处理，脚本复杂度上升，出错概率增加

如果 dba 能保证单个临时表空间有足够容量（比如 32G+）、且启用了 autoextend on next 1G maxsize unlimited，那多数场景下，一个干净的 TEMP 表空间比三四个勉强凑数的组更稳。

真正难搞的是那种既有大报表（GB 级排序）又有千级并发小查询的混合负载——这时候才需要组，但得配合应用层把大任务路由到专用临时表空间，而不是全扔给 default group。