全局临时表（gtt）不产生归档日志、不写undo，但on commit delete rows+高频dml易引发latch: cache buffers chains或library cache lock争用；awr中需通过逻辑读、解析等待等间接指标定位，gtt对象名不可见，仅能通过ora$tmp前缀识别。
全局临时表（GTT）本身不产生归档日志、不走undo段写入，但用错会直接拖垮buffer cache和shared pool——尤其是ON COMMIT DELETE ROWS + 高频DML组合，极易触发latch: cache buffers chains或library cache lock争用。AWR里看不到GTT对象名，必须靠间接指标交叉定位。
看Top 5 Timed Events时重点盯这三类等待
GTT问题不会在db file sequential read里暴露，它压根不碰磁盘。真正信号藏在内存和解析层：
-
latch: cache buffers chains占比突增，且SQL ordered by Gets里出现大量高buffer gets但低physical reads的语句 → GTT被反复扫描，没走索引或谓词失效（比如WHERE session_id = SYS_CONTEXT('USERENV','SID')未加函数索引） -
library cache lock或library cache pin升高，同时Parse Calls/Executions比值接近1:1 → GTT DDL（如TRUNCATE或DROP）被频繁执行，每次都在硬解析新对象 -
enq: TX - row lock contention集中在GTT上 → 忘了GTT的ON COMMIT PRESERVE ROWS模式下，事务间仍共享同一块内存结构，多会话并发INSERT到同一GTT可能隐式争用
SQL Statistics里必须查SQL ordered by Gets而非Elapsed Time
GTT相关SQL通常单次执行快（毫秒级），但buffer gets动辄几十万——因为全表扫描GTT是常态，而Oracle对GTT统计信息默认为空（NUM_ROWS = 0），优化器必然选错执行路径。
- 找出
Buffer Gets Per Exec> 50000 的SQL，用dbms_xplan.display_awr查其执行计划，确认是否出现TABLE ACCESS FULLon GTT - 检查该GTT是否建了索引：GTT索引必须显式创建，且仅对当前会话有效；若应用重启后未重建索引，后续所有查询都退化为全扫
- 对比正常时段报告：若
Logical reads/sec飙升但Physical reads/sec几乎为0，90%是GTT逻辑读爆炸
Instance Efficiency Percentages中Buffer Hit Ratio异常要反向验证
别急着加db_cache_size。GTT数据全在buffer cache里，但它是“伪热点”——每个会话一份副本，导致cache被大量重复内容占满。
- 若
Buffer Hit Ratio从99%掉到92%，但db block gets和consistent gets同步翻倍 → 检查Segments by Logical Reads，GTT段名会显示为ORA$TMP...前缀 - 查
DBA_HIST_SEG_STAT视图确认GTT段的LOGICAL_READS_DELTA是否异常高：SELECT owner, object_name, logical_reads_delta FROM dba_hist_seg_stat WHERE snap_id = &snap_id AND object_name LIKE 'ORA$TMP%' ORDER BY logical_reads_delta DESC - 注意：GTT的
OBJECT_NAME在AWR历史视图中不可见具体业务名，只能靠ORA$TMP前缀+高逻辑读锁定范围
最易被忽略的点：GTT的ON COMMIT行为与应用事务边界错配
AWR报告里的Transactions/sec和Executes/sec比值能暴露问题：若事务数远小于执行数，说明应用在单个事务里反复INSERT/SELECT GTT，而GTT的commit清理机制反而成了瓶颈。
- 例如：一个存储过程循环100次INSERT进GTT，再SELECT聚合，最后COMMIT → 实际触发100次GTT内存分配+释放，而非1次
- 解决方案不是改SQL，而是把GTT生命周期拉长：改用
ON COMMIT PRESERVE ROWS，并在会话级复用，避免高频重建 - 验证方式：在问题时段抓
v$session_wait，过滤event含latch且p1text='cache buffers chains'，再关联sql_id回溯到GTT操作
