为什么临时表空间使用大小查询结果不合实际

Inkcup

=====问题语句：
select f.con_id,d.tablespace_name,
space "sum_space(g)",
blocks sum_blocks,
used_space "used_space(g)",
round(nvl(used_space, 0) / space * 100, 2) "used_rate(%)",
nvl(free_space, 0) "free_space(g)"
from (select tablespace_name,
round(sum(bytes) / (1024 * 1024 * 1024), 2) space,
sum(blocks) blocks
from dba_temp_files
group by tablespace_name) d,
(select con_id,tablespace_name,
round(sum(bytes_used) / (1024 * 1024 * 1024), 2) used_space,
round(sum(bytes_free) / (1024 * 1024 * 1024), 2) free_space
from v$temp_space_header
group by con_id,tablespace_name) f
where d.tablespace_name = f.tablespace_name(+);

查询出现的结果中，使用空间已经远远超过了临时文件实际总大小。


=========================问题解析

这是Oracle中一个经典陷阱:临时表空间(TEMP)的v$sort_segment 和 v$temp_space_header 的统计信息
可能被误读或污染，尤其是在以下场景下：
1.临时段（排序段）未及时清理
当执行大排序、哈希连接等操作时，Cracle会在TEMP表空间中创建临时段。
如果这些操作失败、中断、或者会话异常退出，临时段可能没有被正确释放。
而v$temp_space_header统计的是所有临时段使用的字节节数，不是物理文件的实际占用。

所以显示为1638GB，其实只是”曾经使用过的临时段总和"，并不是当前真实占用.used_space

2.v$temp_space_header的bytes_used是累计值
·这个视图中的bytes_used并不表示”当前正在使用的空间"，而是：
·该临时文件上所有临时段曾经使用的最大空间总量（历史峰值）
·它不会自动清零，即使临时段已经释放
·因此它可能远远大于物理文件大小
例如：一个30GB的临时文件，如果某个查询曾用了280GB的临时空间（自动扩展），那么字节使用量（
bytes_used)就会记录为~280GB，即使现在空了。