ora-01652频发但v$sort_usage为空，源于临时表空间组分配失衡：轮询策略在高并发下导致某tempfile被过度分配而其余闲置，失败请求未生成临时段；需联合查询dba_temp_files、v$temp_extent_pool和dba_tablespace_groups定位真实瓶颈，重建组结构（新建独立临时表空间→切换用户→清空旧组→删除旧tempfile）为根本解法。
ORA-01652报错但v$sort_usage为空，说明问题出在表空间组分配上
临时表空间组（Temporary Tablespace Group）本身不存储数据，只是一组逻辑容器。当多个临时表空间被加入同一组，而用户默认临时表空间指向该组时，Oracle会按“轮询+空闲优先”策略分发排序请求——但这个策略在高并发下极易失衡：某个tempfile可能被反复选中，其余却长期闲置。现象就是ORA-01652频发，但查v$sort_usage发现活跃会话极少甚至为空，因为失败的分配根本没生成临时段。
检查当前组成员与实际使用分布必须联合两视图
单看dba_temp_files或单看v$temp_extent_pool都会误判。真实瓶颈在“谁被分配了、谁真用了”的断层上：
- 用
SELECT tablespace_name, file_name, bytes/1024/1024 AS mb FROM dba_temp_files确认各tempfile物理大小和autoextensible状态 - 用
SELECT tablespace_name, SUM(bytes_cached)/1024/1024 AS mb_used FROM v$temp_extent_pool GROUP BY tablespace_name查各表空间当前缓存占用（注意：这是已分配但未必正在用的逻辑块） - 运行
SELECT * FROM dba_tablespace_groups确认哪些表空间属于哪个组；再查SELECT username, temporary_tablespace FROM dba_users WHERE temporary_tablespace LIKE '%GROUP%'定位使用组的用户
如果发现某tempfile的bytes_cached远高于其他成员，且其maxbytes已接近磁盘剩余空间，基本可断定轮询失效，分配卡死在该文件。
重建组结构比调参更可靠，关键在顺序和切换时机
临时表空间组不支持在线重排成员顺序，也不能动态调整权重。唯一稳解是重建：
- 新建独立临时表空间（不加入任何组）：
CREATE TEMPORARY TABLESPACE temp_new TEMPFILE '/u02/oradata/temp_new01.dbf' SIZE 4G AUTOEXTEND ON NEXT 512M MAXSIZE 16G - 将用户默认临时表空间切到新表空间：
ALTER USER scott TEMPORARY TABLESPACE temp_new（逐个执行，避免批量ALTER影响连接池） - 确认旧组中无活跃用户后，逐个从组中移除表空间：
ALTER TABLESPACE temp_old TABLESPACE GROUP ''（清空组名即解除归属） - 最后删除旧tempfile：
ALTER DATABASE TEMPFILE '/u01/oradata/temp_old01.dbf' DROP INCLUDING DATAFILES
注意：DROP TEMPFILE不能带INCLUDING CONTENTS，否则报错；必须先确保v$sort_usage和v$temp_extent_pool对该文件无任何引用。
后续监控必须盯住group_member_count和分配延迟
表空间组不是“越多越好”。Oracle对组内成员数有隐式限制：超过4个时，轮询开销上升，分配延迟明显增加。生产环境建议组内不超过2–3个tempfile，且必须满足：
- 所有成员tempfile路径分散在不同物理磁盘（避免I/O争用）
- 每个tempfile的
MAXSIZE设为相同值（如MAXSIZE 8G），防止Oracle因“剩余空间最大”倾向某一个 - 监控脚本里加一条：
SELECT group_name, COUNT(*) FROM dba_tablespace_group_members GROUP BY group_name，超3立即告警
真正难处理的不是空间不够，而是分配逻辑在底层绕过了你的预期——组配置一旦写进数据字典，就不再响应SQL级干预，只能靠结构级重置。
