AWR中识别远程SQL执行开销需重点关注db file sequential read、SQL*Net message from dblink和gc cr block 2-way三类等待事件，结合Instance列判断是否远端执行，并通过含@符号的SQL、parse time elapsed、physical reads direct等指标综合分析网络延迟、解析开销及全表扫描风险。
AWR里怎么看远程SQL执行开销
远程查询性能问题在awr中不会直接标为“分布式慢”，而是分散在多个指标里。关键要盯住 db file sequential read、sql*net message from dblink 和 gc cr block 2-way 这三类等待事件——它们分别对应远程表的单块读、网络往返延迟、以及rac环境下的全局缓存争用。
常见错误是只看 Top SQL 列表，却忽略这些SQL的 Instance 列：如果显示的是远程实例名（比如 DB2），说明该SQL实际在远端执行，但AWR默认只采集本库数据，远端执行细节不会进本库报告。这时你看到的只是“本库发起调用”的等待时间，不是远端真实耗时。
- 查远程访问频率：在
SQL ordered by Gets部分找含@符号的SQL（如SELECT * FROM sales@remote_db），确认是否高频调用 - 查网络延迟影响：看
SQL*Net message from dblink的time_waited占比，若超过总DB Time的15%，说明网络或远端响应拖累明显 - 查本地解析开销：远程SQL每次执行都会触发本地硬解析（即使远端已缓存），检查
parse time elapsed是否异常高
为什么远程全表扫描在AWR里特别危险
Oracle对远程表默认不收集统计信息，优化器只能按固定基数（比如 10000 行）估算，极易选错执行计划。AWR中表现为：同一SQL在 Top SQL 里反复出现，Executions 低但 Buffer Gets 极高，且 Physical Reads 接近 Logical Reads——这说明没走缓存，每次都在拉整张表。
更隐蔽的问题是：远程表被当作“大表”触发直接路径读（direct path read），绕过buffer cache，导致本地SGA压力不显，但磁盘I/O和网络带宽被持续占满。AWR的 Instance Activity Stats 里 physical reads direct 值飙升，就是这个信号。
- 验证方式：在SQL文本里搜
TABLE ACCESS FULL+@，再查该SQL的Rows Processed和Elapsed Time per Exec比值，若远超100ms/row，基本确认是远程全扫 - 临时缓解：加
/*+ DRIVING_SITE(t) */提示强制在远端过滤，但需确保远端有对应索引 - 根本解法：在本地建物化视图（
CREATE MATERIALIZED VIEW），并设REFRESH FAST ON COMMIT（需远端开启主键日志）
AWR中识别dblink连接池瓶颈
dblink本身不支持连接复用，每次SQL执行都新建会话。AWR的 Instance Efficiency Percentages 里如果 Logons per Sec 突增，同时 Shared Pool Hit % 下跌，说明大量dblink会话在抢shared pool里的游标空间。
另一个线索藏在 Wait Events 的 latch: shared pool 或 library cache lock 上——这些等待不是远程慢，而是本地解析阶段卡在内存争用。此时看 SQL ordered by Parse Calls，会发现同一远程SQL反复解析（Parse Calls ≈ Executions），说明没命中软解析。
- 检查dblink使用模式：运行
SELECT owner, db_link FROM dba_db_links，确认是否所有应用都直连远端，而非统一走中间库 - 限制并发：用
DBMS_SCHEDULER控制远程任务调度节奏，避免瞬间大量dblink爆发 - 替代方案：改用 Oracle GoldenGate 或 Data Pump 做增量同步，把远程访问转为本地查询
DB TIME高但CPU不高？重点查远程等待链
当AWR显示 DB Time 远高于 Elapsed Time × CPU Count，但 %Total CPU 又很低，说明大量时间花在非CPU资源上。这时候必须展开 Top 5 Timed Foreground Events，逐层下钻：
第一层常是 SQL*Net message from dblink → 第二层点开该事件详情，看 Avg Wait(ms)；如果超过200ms，再切到 SQL ordered by Elapsed Time，找到对应SQL的 Remote Instance 列；最后去远端库查它的AWR，重点看 db file scattered read 或 enq: TX - row lock contention ——本地AWR永远看不到远端锁等待。
- 容易忽略的点：dblink事务默认是
READ COMMITTED，但远端若发生长事务，本地会一直等远端提交，AWR里只记作SQL*Net等待，不体现阻塞源头 - 验证方法：在本地执行
SELECT * FROM v$dblink，检查heterogeneous列是否为YES，是则说明跨平台（如连SQL Server），协议开销更大，需额外关注SQL*Net more data from dblink事件
