DB Time 高但 CPU 不高说明数据库等待非 CPU 资源，如 I/O、锁、latch 或网络延迟；RAC 环境下需重点关注 gc/ges 相关等待事件及配置正确性。
为什么 AWR 报告里 DB Time 高但 CPU 不高？
这通常说明数据库在等非 cpu 资源，比如 i/o、锁、闩锁（latch）或网络延迟。rac 环境下尤其要警惕全局资源争用——gc buffer busy acquire、enq: tx - row lock contention 这类等待事件在单实例不明显，但在 rac 中会因跨节点通信放大。
实操建议：
- 优先看
Top 5 Timed Foreground Events，过滤出带gc（Global Cache）、ges（Global Enqueue Service）前缀的等待 - 用
SELECT * FROM GV$SYSTEM_EVENT WHERE EVENT LIKE 'gc%' OR EVENT LIKE 'ges%';查各节点实时争用分布 - 确认是否启用了
CLUSTER_DATABASE = TRUE，且所有实例的INSTANCE_NUMBER唯一——配置错误会导致 GES 队列异常堆积
如何安全调整 _gc_policy_time 和 gc_files_to_locks？
这两个隐含参数直接影响 RAC 的缓存融合（Cache Fusion）行为。_gc_policy_time 控制节点间自动迁移数据块的触发频率，默认 300 秒；gc_files_to_locks 决定每个数据文件分配多少全局锁（global locks），影响并发 DML 效率。
常见误操作是直接调大 gc_files_to_locks 以“缓解争用”，结果引发 GES 队列过载甚至实例 hang。
实操建议：
- 先查当前值：
SHOW PARAMETER gc_files_to_locks；若显示为*，说明使用默认自动计算（推荐保留） - 仅当明确观察到某文件级
enq: HW - contention或enq: SQ - contention且集中在少数文件时，才考虑按文件指定，例如：ALTER SYSTEM SET gc_files_to_locks='1=200,3=500' SCOPE=SPFILE; -
_gc_policy_time一般不建议修改；若业务有强局部性（如固定节点处理固定客户分片），可尝试设为 600–1800，但必须配合ALTER SYSTEM SET CLUSTER_INTERCONNECTS = '...' SCOPE=SPFILE;确保私网稳定
V$GLOBAL_TRANSACTION 显示大量 IN-RECOVERY 状态事务怎么办？
这表示某个实例崩溃后，其他实例正在回滚其未提交事务，但进度缓慢。根本原因常是 undo 表空间不足、undo retention 设置过短，或存在长事务阻塞了回滚段清理。
注意：这不是“卡住”，而是 RAC 的正常恢复机制，但持续数小时就属异常。
实操建议：
- 立刻查
SELECT * FROM GV$TRANSACTION WHERE STATUS = 'ACTIVE' AND START_TIME 找出运行超 1 小时的事务 - 检查各节点 undo 表空间使用率：
SELECT TABLESPACE_NAME, ROUND((BYTES-FREE_BYTES)/BYTES*100,2) USED_PCT FROM GV$TABLESPACE_USAGE; - 临时提升恢复速度：在未崩溃节点执行
ALTER SYSTEM SET "_smu_debug_mode" = 4 SCOPE=MEMORY;（仅限 Oracle 11gR2+，重启失效），加速 SMU 回滚段清理
Instance Tuning 时为何不能只看单个 GV$ 视图？
RAC 是共享一切但又各自调度的架构。比如 GV$SESSION 显示某 SQL 在节点 1 执行慢，但真正瓶颈可能在节点 2 上——因为该 SQL 访问的表分区位于节点 2 的本地 buffer cache，而节点 1 正在反复发起 gc current request 获取块。
忽略跨节点视角，等于只看了半张拓扑图。
实操建议：
- 所有性能分析必须用
GV$视图（而非V$），并加INST_ID分组，例如：SELECT INST_ID, EVENT, COUNT(*) FROM GV$SESSION_WAIT GROUP BY INST_ID, EVENT ORDER BY COUNT(*) DESC; - 用
SELECT * FROM GV$SQL_MONITOR WHERE STATUS = 'EXECUTING' ORDER BY ELAPSED_TIME DESC;定位跨节点执行计划倾斜 - 特别关注
GV$LOCK和GV$ENQUEUE_LOCK中INST_ID不同但ADDR相同的记录——这是典型的跨实例锁等待链
RAC 性能问题的复杂性，往往不在参数本身，而在参数生效范围与实例间状态同步的滞后性。改一个参数前，先确认它是否真的在所有节点上被识别、加载、生效——SELECT NAME, VALUE, ISDEFAULT FROM GV$PARAMETER WHERE NAME = 'xxx'; 比盲目重启更省时间。
