top 10 foreground events by total wait time是awr中首要查看的表格，它揭示时间消耗主体而非具体慢因；需按总等待时间排序、结合等待次数与sql耗时综合判断，db cpu高反映活跃工作量大，未必是cpu瓶颈，关键看是否由单条低效sql或硬解析过多导致。
top 10 foreground events by total wait time 是awr里唯一值得优先扫一眼的表格，它不告诉你“哪里慢”，但能告诉你“时间被谁吃掉了最多”——看错顺序、孤立读数字、跳过等待次数，三者任一都会误判瓶颈。
别把“DB CPU”当警报，先翻到SQL ordered by CPU Time
DB CPU 排第一不等于CPU真不够。它只是数据库所有前台会话消耗CPU时间的总和，本质是“活跃工作量”的代理指标。真正的问题藏在细节里：
- 如果
DB CPU占比高但SQL ordered by CPU Time里某条SQL贡献了70%以上，那问题大概率是这条SQL没走索引、写了全表扫描，或用了低效函数（比如在WHERE里用TO_CHAR(date_col)） - 如果
DB CPU高，但Hard Parses也异常高（比如每秒 >50），说明应用没绑定变量，大量重复解析在空耗CPU - Oracle 19c默认启用PGA自动管理，但如果
sorts (memory)/sorts (disk)比值跌破 20:1，说明PGA_AGGREGATE_TARGET可能偏小，排序被迫落盘，CPU时间被无效IO拖长
log file sync 等待时间短≠没问题，重点看Waits/Sec
log file sync 平均等待 665 µs 看似健康，但若一小时内发生 6600 万次，意味着平均每秒提交超 1800 次。这不是IO慢，是事务粒度太细：
- 检查应用层是否在循环里逐行
COMMIT，应改为批量提交（如每100–500行一次） - 确认归档模式下
ARCHIVE_LAG_TARGET是否设得过小，导致频繁触发归档，间接拖慢LGWR - 存储层I/O延迟不是唯一因素：RAC环境下，
log file sync高常伴随gc cr block lost或gc buffer busy acquire，说明互连延迟已影响日志同步路径
db file sequential read 和 db file scattered read 必须分开看场景
两者都叫“物理读”，但背后逻辑完全不同：
-
db file sequential read多见于索引查找、ROWID访问，平均等待 >10ms 才需怀疑磁盘；若Tablespace IO Stats里对应表空间Avg Rd(ms)optimizer_index_cost_adj设为100误判索引代价 -
db file scattered read几乎全是全表扫描或快速全索引扫描（FAST FULL SCAN），占比突增时，先查SQL ordered by Gets和SQL ordered by Reads，定位是否某张小表被频繁全扫（例如开发写了SELECT * FROM config_table却没加WHERE） - 注意
direct path read：它不经过Buffer Cache，常见于大排序、Hash Join、并行查询。若它突然进入Top 10，优先调大PGA_AGGREGATE_TARGET，而不是去调DB_CACHE_SIZE
RAC环境下的GC类等待不能单看数值
gc cr block lost、gc buffer busy acquire 这些事件数字再大，脱离集群状态就是废数据：
- 先确认
GV$CLUSTER_INTERCONNECTS是否显示所有节点互连正常；再查GV$SYSSTAT里gc cr blocks received和gc current blocks served的比值，若远高于 1.5，说明CR请求响应慢，不是网络丢包就是远程实例负载过高 -
gc buffer busy acquire平均等待 15ms 且集中在少数块（查GV$BH中HLADDR热点），大概率是序列号表、计数器表这类热点块争用，需改用IDENTITY列或应用层分段生成 - 不要单独优化单个GC事件：比如降低
gc cr block lost可能靠增大_gc_read_mostly_locking，但这会加重本地实例内存压力，得同步看cache buffers lru chainlatch争用是否上升
真正卡住系统的，往往不是那个“占比最高”的事件，而是某个中等占比事件背后隐藏的并发基数失衡或配置错位——比如10个用户打满 gc buffer busy acquire，比1000个用户分散产生同样次数严重得多；又比如 log file sync 看似只占2%，但它拖慢的是所有提交型事务的端到端响应，实际影响面远超数值体现。
