查v$sort_usage时多个会话共用同一session_addr是因并行查询中该字段指向QC而非PX进程，需关联v$px_session区分真实资源消耗者，避免误杀QC导致PX进程持续写TEMP。
查 v$sort_usage 时发现多个会话共用同一 session_addr
这其实是假象——v$sort_usage 的 session_addr 字段在并行查询中指向的是 QC（Query Coordinator）会话地址，而非真实干活的 PX 进程（如 P000、P001）。所以你看到“10 个会话挤在同一个 session_addr 下”，实际是 10 个 PX 进程在为同一条 SQL 协同分配临时段，但视图没暴露这个层级。
真正的问题不是“共享”，而是“无法区分”。你无法从该视图判断：是单个大排序占满 TEMP，还是 10 个并行进程各自吃掉 10% 空间却因聚合显示为“一个高用量”。
- 必须关联
v$px_session：它明确记录了qcsid（QC 的 sid）、server_name（PX 进程名），可用来反向定位每个 PX 进程的资源归属 -
v$tempseg_usage在 12c 中仍不带server_name或degree字段，不能直接用于并行粒度分析 - 若只靠
v$sort_usage杀会话，可能只干掉 QC，而 PX 进程仍在后台持续写 TEMP，导致空间继续上涨
用 v$active_session_history 抓 direct path write temp 采样时，sql_id 高频但 plan_hash_value 不一致
说明同一条 SQL 文本在不同执行中走了完全不同的执行路径，其中某些计划触发了磁盘排序/哈希溢出，另一些则没有。这不是资源争用，而是执行计划漂移引发的间歇性 TEMP 暴涨。
典型诱因包括绑定变量窥探失效、统计信息过期、或并行度动态调整（如 parallel_degree_policy = AUTO）。
- 不要只按
sql_id聚合，必须加plan_hash_value：否则会把“走内存 HASH JOIN”的采样和“走磁盘 HASH JOIN”的采样混在一起，掩盖真实问题计划 - 检查
v$sql中该sql_id对应的is_bind_sensitive、is_shareable和executions，确认是否存在子游标分裂 - 用
DBMS_XPLAN.DISPLAY_CURSOR(sql_id, child_number)对每个高频plan_hash_value单独看执行计划，重点找TempSpc列非空、且操作类型为HASH JOIN或SORT ORDER BY的步骤
多个 PDB 共享 CDB 级临时表空间，但 dba_temp_files 显示文件路径相同
CDB 架构下，PDB 本身不拥有物理临时文件，所有 PDB 默认复用 CDB$ROOT 的临时表空间（除非显式创建本地 TEMP）。路径相同不等于无隔离——Oracle 通过事务级上下文隔离各 PDB 的临时段分配，但资源总量是共享的。
隐患在于：一个 PDB 的批处理 SQL 疯狂消耗 TEMP，会导致其他 PDB 的日常查询也遭遇 ORA-01652，而你从 PDB 内部查 v$tempseg_usage 可能看不到完整视图（需切到 CDB ROOT 查 gv$tempseg_usage）。
- 在 CDB$ROOT 中执行查询，而非任一 PDB：只有
gv$tempseg_usage能跨容器汇总，v$tempseg_usage在 PDB 内仅返回本 PDB 上下文的数据（可能为空或严重低估） - 检查
v$pdbs中各 PDB 的open_mode和status，确认是否所有 PDB 都处于活跃状态；已关闭的 PDB 不参与 TEMP 分配，但其残留临时段可能未释放（极少见，需查v$temp_extent_pool） - 若需强隔离，应在 CDB$ROOT 创建多个临时表空间，并在各 PDB 中
ALTER PLUGGABLE DATABASE ... DEFAULT TEMPORARY TABLESPACE指定不同实例
查到高消耗 SQL 后，DBMS_XPLAN.DISPLAY_CURSOR 返回 TempSpc 为 NULL，但 direct path write temp 采样持续存在
说明优化器预估失败：CBO 认为该操作可在内存完成（TempSpc = 0），但运行时 PGA 不足或数据倾斜导致强制落盘。这不是 SQL 写法问题，而是内存配置与实际负载不匹配。
常见于并行查询中单个 PX 进程分配到的数据远超平均值（如分区倾斜），或 pga_aggregate_target 设置过低且未启用自动内存管理。
- 别急着改 SQL，先确认
v$pgastat中cache hit percentage是否低于 90%，以及total PGA allocated是否频繁接近pga_aggregate_target - 检查该 SQL 执行时的
v$sql_workarea：对比actual_mem_used和max_mem_used，若后者远大于前者，说明工作区被反复重用并 spill 到磁盘 - 临时缓解可设
ALTER SESSION SET "_serial_direct_read"=never（防小表全扫触发排序），长期方案是调高pga_aggregate_target或启用memory_max_target自动均衡
临时表空间争用排查最难的点，往往不在“谁在用”，而在“谁在伪装成别人用”——并行进程、多租户上下文、执行计划漂移，都会让真实资源持有者藏在视图字段背后。盯住 server_name、plan_hash_value、gv$ 前缀和 actual_mem_used 这四个信号，比单纯杀会话或扩容更接近根因。
