ETL数据同步工具慢问题分析1

今日ETL任务同步一张不是很大的表，字段也不多，但很慢，由于该工具之前问题频发，我初步判断是etl工具问题，根据etl信息，然后定位到数据库，下面我记录一下问题分析的思路。

 由日志记录发现，查询到插入比较快，插入完成再次查询比较慢，初步判断是源端查询慢。

获取awr报告，该sql cpu占比31.84 IO只占有0.29，说明cpu占用高，而不是io高

按逻辑读取高达16亿次

 

在 AWR 里看到这个指标，意味着什么？

在这个章节的表格里，有这几列最关键：

 

列名	含义	你的 SQL 数据
Buffer Gets	该 SQL 总共产生的逻辑读次数	3,211,670,840（32.1亿次）
Executions	该 SQL 执行了几次	2 次
Gets per Exec	平均执行一次要扫多少次内存	16亿次/次
%Total	占整个数据库所有逻辑读的比例	24.6%（排全库第一）

Oracle 的潜规则：如果一条 SQL 的 Gets per Exec 超过 10 万 ~ 100 万 次，通常就存在性能问题。16 亿次属于“毁灭级”的逻辑读，说明执行计划完全错误。

 

SQL ordered by Cluster Wait Time

在 AWR 报告中，SQL ordered by Cluster Wait Time 这部分是专门为 RAC（真实应用集群） 环境设计的

 

看 SQL ordered by Gets 是看 “本地 CPU 累不累”（你视图的痛点）。
看 SQL ordered by Cluster Wait Time 是看 “私网压力大不大”。
视图 Cluster Wait 几乎为 0，说明“私网不背锅”