从巡检报告看，发现19:00 1#节点DB_TIME很高，请提供如下信息：

1、alert报警日志，如果有问题时间点的trace文件也请提供；

2、v$active_session_history的18:30-19:30的记录导出(exp/expdp)，18:30-19:30的awr报告；

3、OS级别的监控日志，如：osw,nmon等。

根据今天早上6-8点的AWR看到前台主要的GC相关的等待事件：

latch: cache buffers chains: 12.48%
latch: gc element: 2.83%

gc buffer busy acquire: 29.9%
gc buffer busy release: 9.48%
gc current block 2-way: 2.86%
gc current block congested: 1.65%
gc cr grant congested: 1.6%
gc current grant busy: 1.25%
gc cr grant 2-way: 1.11%

RAC两节点数据交互每秒达到了3M，且在AWR的topSQL中存在update undo$想到SQL：

update /*+ rule */ undo$ set name=:2, file#=:3, block#=:4, status$=:5, user#=:6, undosqn=:7, xactsqn=:8, scnbas=:9, scnwrp=:10, inst#=:11, ts#=:12, spare1=:13 where us#=:1

初步判断为GC相关的BUG，建议根据白求恩的巡检调整如下参数（需重启）：

对于数据库实例，在11版本中，隐含参数 _undo_autotune 负责 undo retention（即 undo 段的保持时间）的自动调整，若由 Oracle 自动负责 undo retention，则 Oracle 会根据事务量来占用 undo 表空间，可能会形成 undo 表空间的争用，建议将其关闭。 

参考命令：alter system set "_undo_autotune"=FALSE scope=spfile sid='*';

对于数据库实例，在11版本RAC中，DRM（Dynamic Resource Mastering）负责将 Cache 资源 Remaster 到频繁访问这部分数据的节点上，从而提高 RAC 的性能。但是 DRM 在实际使用中存在诸多 Bug，频繁的 DRM 会引发实例长时间 Hang 住甚至是宕机，建议关闭 DRM。
参考命令：alter system set "_gc_policy_time"=0 scope=spfile sid='*';

对于数据库实例，在11版本RAC中，建议关闭集群 Undo Affinity，降低集群交互，避免触发相关 BUG。
参考命令：alter system set "_gc_undo_affinity"=FALSE scope=spfile sid='*';

1. AWR采集的数据时间粒度太大，建议采集核心ASH或者OSWatcher、CHM等数据来分析

2. 从top event来看都是热块现象，实例间内存中会话的热块和实例间不同节点请求的GC热块，热块都是top sql中几个相关的sql

3. Top sql的db time第一个第二个问题应该是最大的，特别是第一个，可能逻辑读请求比较大，外加高并发环境下，可能rac下也没有做业务分离，高逻辑读高并发请求必须会导致rac的gc争用和内存中的cbc latch、buffer busy waits等等待

4. cpu可能在某个时间段存在了瓶颈，这个会反过来影响数据库的整体性能，比如出现索引分裂等待、热块现象更加严重等

建议：

1、优化SQL，这个是最重要的做的

2、DRM关闭

3、auto undorention关闭，不清楚update undo$那个SQL是否跟auto_undotune有关系，不过一般都是将其关闭的，避免undo retention变来变去，从而导致undo tablespace容量达到100%，出现undo窃取行为，并且出现enq-us contention、row cache lock等等待