Oracle RAC数据库如何性能调优？结合Instance Tuning技巧-Oracle-PHP中文网

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'; 比盲目重启更省时间。