为期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中进一步清晰。…