临时表空间组是逻辑分发容器而非负载均衡器，其通过哈希算法（基于SID和INST_ID）固定分配会话到特定tempfile，不感知使用率；组内成员须物理隔离且均在线才有效分摊I/O压力。
临时表空间组不是负载均衡器，而是逻辑分发容器
oracle 的 tablespace group 本身不轮询、不感知空闲度、不按使用率调度——它只是把多个独立的临时表空间“打包”成一个逻辑名供用户或实例引用。真正决定 session 用哪个 tempfile 的，是登录时内部哈希算法算出的一个固定值，后续整个会话生命周期都不会切换。
这意味着：建了组 ≠ 自动摊平压力。如果组里只有 temp01 一个成员，那所有排序还是全打到它身上；如果组里有 temp01 和 temp02，但两个 tempfile 物理文件都在同一块磁盘上，I/O 瓶颈照旧。
- 哈希结果只跟 session 的
SID和INST_ID有关，和当前 tempfile 使用率无关 - RAC 环境下，每个实例只能看到自己节点上的
DBA_TEMP_FILES，跨节点无法协调分配 -
ALTER DATABASE DEFAULT TEMPORARY TABLESPACE grp_temp是合法的，但只是让新连接“有资格从组里挑”，不保证挑得均匀
创建和添加成员必须用 TABLESPACE GROUP 子句，不能事后“归组”
组不是独立对象，没有 CREATE TABLESPACE GROUP 命令。组的存在完全依赖于成员表空间是否显式指定了 TABLESPACE GROUP 子句。
第一次执行带 TABLESPACE GROUP 'grp_temp' 的 CREATE TEMPORARY TABLESPACE，组就诞生了；后续用 ALTER TABLESPACE ... TABLESPACE GROUP 'grp_temp' 把其他临时表空间加进来，才是扩容。
- 已存在的临时表空间（比如
temp02）如果没归属任何组，ALTER TABLESPACE temp02 TABLESPACE GROUP grp_temp会把它移入该组 - 如果它原本就在另一个组里，这条语句会先把它踢出原组，再塞进新组
-
ALTER TABLESPACE temp01 TABLESPACE GROUP ''只是解除绑定，不会删组——组只要还有至少一个成员，就一直存在 - 想彻底删组？必须逐个移出所有成员，等最后一个被踢出，组自动消失
RAC 下必须为每个实例配本地 tempfile，共用组名≠共享物理资源
在 RAC 中，TEMP_GROUP 这个名字可以一样，但每个实例的 tempfile 必须物理隔离：路径不能冲突、ASM diskgroup 必须在本节点可写、文件名最好带实例标识（如 +DATA/racdb_inst1/temp01.dbf）。
如果图省事，所有实例都设 DEFAULT TEMPORARY TABLESPACE TEMP_GROUP，而组里只有一个表空间且它的 tempfile 只在一个节点挂载，其他节点启动就会报 ORA-01157；即使能启动，排序也只会用本节点上那个 tempfile，根本不会跨节点调度。
- 检查各实例默认设置，必须在每个实例上单独跑：
SELECT property_value FROM database_properties WHERE property_name = 'DEFAULT_TEMP_TABLESPACE' - 不要依赖 OMF 自动生成路径——它默认不区分实例，容易导致多个实例争写同一个 tempfile
- 确认 tempfile 状态：
SELECT tablespace_name, status, enabled FROM dba_temp_files，确保是ONLINE且ENABLED = READ WRITE
监控组是否生效，关键看 V$SORT_SEGMENT 是否跨文件分布
建完组、设好默认、重启应用之后，别只查 DBA_TABLESPACE_GROUPS 就以为万事大吉。真正要看的是实际排序有没有落到不同 tempfile 上。
最直接的方式是关联 V$SORT_SEGMENT 和 DBA_TEMP_FILES：
SELECT s.tablespace_name, f.file_name, s.blocks * 8 / 1024 AS mb_used FROM v$sort_segment s, dba_temp_files f WHERE s.tablespace_name = f.tablespace_name;
如果结果里只出现 temp01 的文件，说明哈希全打偏了；如果 temp01 和 temp02 都有记录，才说明组在起作用。
-
V$SORT_USAGE显示的是当前活跃会话的临时段，适合抓大排序；V$SORT_SEGMENT显示的是 segment header 分配状态，更反映底层分配倾向 - RAC 要用
GV$SORT_SEGMENT并按INST_ID分组查，否则看不到其他节点情况 - 如果发现某 tempfile 持续高用，而其他成员几乎不用，大概率是 extent 管理方式不一致（比如混用了
UNIFORM SIZE和AUTOALLOCATE）
组本身不解决 I/O 瓶颈，它只是把“往哪写”的选择权从单点扩展到了多个物理位置——但最终写到哪，取决于哈希算法和底层 tempfile 的分布质量。最容易被忽略的，是以为设了组就一劳永逸，却忘了检查每个 tempfile 是否真在线、是否真隔离、是否真被用上。
