为期4天的10g RAC培训结束了，必须承认这4天的收获非常大，解答了很多我以前一直迷惑的地方，并且获得了大量诊断和调优RAC系统的经验。Su和Roy的技术实在让人佩服。
对于AWR报告中RAC部分的表述，对于RAC每个重要等待事件的含义，对于Cache Fusion的每一步动作，对于CRS相关的log和trace，对于Load Balance的处理，对于Dynamic Resource Management的机制，这些都是我以前感到疑惑的地方，在这次培训中都得到了几乎完美的解答。
举一个简单的例子，如果有人问我，“RAC环境中如果一个实例在自己的Cache中找不到需求的block，那么它就会请求从另外一个实例中获得这个block，那么如果有更多的节点，这样的请求过程会很消耗资源吗？8个节点下的这种情况会比2个节点更消耗资源吗？”在这次培训之前，我无法回答，甚至我会说，恩，也许是的吧。但是，现在我可以很清楚地回答，NO！因为在一次gc block request中最多只会有3个block参与到其中，而不管环境中有多少个节点，这就是master block的作用，每次request的过程是requester -> master -> holder。
其实并不局限在RAC部分，纯RDBMS的知识也得到了完善，再举一个例子。对于性能报告中CPU Time这个等待事件我一直感到疑惑，这到底表示了什么？CPU Time位于Top 5 wait event中表示了什么？我还在网上跟Fenng聊过这个问题，也仍然抱有疑惑。然而，现在我知道，我们忽略Top 5中的CPU Time并不是因为它是Idle wait也不是因为我们要从其它的等待中判断CPU Time等待，我们忽略它是因为CPU Time就是说明系统在利用CPU干活，实际上这不是一个等待事件，CPU Time高表示系统在干活，而这是个好的现象，因为系统并没有把时间耗费在Wait上。Elapsed Time = CPU Time + Wait Time，所以甚至我们可以说CPU Time越高越好。
有太多的资料和学习笔记需要整理，今后应该会陆续把Topic写成文章的，不过不会很快，因为之后几天我得休息一下，然后把报销搞定，还有琢磨一下新入手的Nokia N95。
BTW: RAC Pack的宗旨是高举Oracle的三个代表 － CRS, ASM, RAC。
Update@2011-1-9
今天再回顾3年前的这段话，发现当时自己对于CPU Time在数据库整体等待事件中的含义还是不太清晰的，应该说piner当时的话更符合我现在的理解。在一个正常的系统中，虽然仍然不需要特别去关注CPU Time，但是如果在AWR报告中看到CPU Time占据了80%甚至90%的DB Time，那么如果不是这个系统确实很闲那就是这个系统有某些问题。因为数据库在正常承载应用的时候，如果绝大多数时间都是CPU在运算，那么就意味着I/O时间很小，这在大多数环境中是不正常的。
一些概念在DB time VS. DB CPU中进一步清晰。
BTW：3年前还是Nokia鼎盛的时期，那时候正入手Nokia N95，然而到了2010年，Nokia在Apple iPhone和Google Android的强大攻势下，已经面临再不转身就会被抛下的局面，真是一朝天子一朝臣。
那么趁着你正热乎着, 帮忙给分析看看下面这个等待时间的起因和解决方法:
Wait: gc current request, Class: Cluster
Oracle 10.1.0.4 RAC on Linux
在数据库的I/O中有current read 和 consistent read，在RAC中也是一样，请求从Global Cache中获取current block到最后获取到这个block之间的等待就是gc current request，如果是尝试获取consistent block，那么就是gc cr request等待。这是概念。
那么如果gc current request位于Top 5中，首先要看ave wait time是多少，通常这个值应该在5-8个msec，如果是2位数的话，那么表示gc block的获取速度是比较慢的。
至于为什么比较慢，就需要详细判断原因了。
可以查一下AWR Report中是不是还有其它的gc等待，比如gc current block busy或者gc current buffer busy，这可能是热点块的问题。
还可以查一下有没有gc block lost，这个lost应该趋近为0，因为每次lost都是在6个timeout之后才会发生，而每个timeout需要1s，这样如果有一次block lost就会消耗6s的时间，这会严重降低gc current request的平均等待时间。
另外因为gc通讯都是通过lms进程完成的，那么可以通过10046 trace本地客户端进程，再同时通过10708 trace另外节点的lms进程，互相比较，就可以明确的知道到底gc block request是慢在哪里了。
RAC我见过的一般都是2、3个节点，遇到的工程师都胜传4~6个节点时db慢的不行，想了一下，如果对于一个点如A节点(相对于剩下的节点既是master也是requester)，是不是RAC中的点越多，对A点的请求或A对其它点的请求会越多，导致了资源紧张，尤其是在load balance做了session分摊的情况下
真羡慕楼主有这样的机会啊，期待楼主能够把培训资料整理发表出来。
10708 trace另外节点的lms进程,楼主能否贴出一个TRACE 分析一下
Thanks 10k. 你的提示非常具有技术的先进性! 哈哈.
看来我03/04年在Oracle R&D积累的RAC知识已经过时了.
“gc current request”主要出现在 长事务 实时监控报告里面,
总体到数据库级别, 倒不明显.
反而gc cr grant 3-way出现在了top 5 wait events (Top 5 Timed Events) 中.
4 个节点的AWR都给你email过去了.
@木匠
暂时还没有时间看你的awr，不过我会看的。gc cr grant 3-way是这样产生的，一个节点需求一个cr block，此时需要询问master，但是此block的master不在自己实例上，这样是一次网络hop，master发现这个block在另外的实例上，于是告诉另外那个实例把block传给这个请求的实例，这又是一次网络hop，另外的实例给这个实例一个lock（这是grant）让这个实例自己去从disk上读取block，这是第三次网络hop，整个这个过程就是3-way的gc cr grant，通常这个等待下面会跟随着一次磁盘I/O。
@victor666666
这种情况理应不会出现，因为oracle会按照很简单的平分规律在所有节点中平均放置block的master，因此几乎不可能所有block的master都在A节点上，除非因为所有的检索更新操作都在A节点上完成，由于DRM所以master block被全部动态转移到A节点上了，这个跟是10gR1还是10gR2也有关系，这两个版本处理的机制是不一样的，10gR1是DYNAMIC FILE AFFINITY，10gR2是DYNAMIC OBJECT AFFINITY，这个要讲就讲多了，希望尽快有时间写出文章来吧。
你可以尝试使用_gc_undo_affinity=false和_gc_affinity_time=0 来禁用DRM，这样对于多节点的RAC环境应该会有性能的改善。
cpu time多也不一定是好事,只有相对,没有绝对.
一般的OS中，wait 是可以被利用的，cpu利用高，很大程度表示逻辑读高，而你的系统是否应当有这么高的逻辑读？
@piner
自然不是绝对的，但是通常来说是没有问题的。
因为如果是逻辑读高，那么应该会有其它的相关等待事件浮出水面，比如buffer busy等，所以不论何种情况CPU Time应该都不用作为关心的对象
buffer busy不一定的，我们的系统，这个cpu time高一般都是逻辑读高，或者是大规模计算型函数。
带来的就是负载的升高，调整掉这些就好了，其实要明白一点，逻辑读与一些计算型函数，耗费的就是cpu，如果能减少他们，当然是好事情。
你这样的说法当然也没有问题。
本来需要耗费30%的CPU Time在不降低负载的情况经过调优（比如优化逻辑读等）变成只需要耗费20%的CPU，这当然是好事儿。
我的意思只是说，如果你看到CPU Time在Top 5事件中不需要去特意关注他，这个事件只是说CPU在Run，而其它的等待事件更能说明系统需要调整的地方。
按照这个说法，应该是4-way。
获得block的node活通知gcs，它是新的holder。
10g rac sg。
🙂
每次都能在kamus这里发现一些非常有帮助的东西