本次10gRAC培训为期四天，解决了许多关于RAC系统诊断和调优的问题，包括AWR报告解读、CacheFusion机制、CRS相关日志分析等。文章还讨论了CPUTime在性能报告中的意义及其与系统负载的关系。
10gRAC培训 - 2 and last:
为期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
from：http://www.dbform.com/html/2007/337.html
[转载]statspack中cpu time的学习:
kamus在他的blog10gRAC培训 - 2 and last。说到了这个cpu time，具体可以看正文以及下面我与他的留言，他的意思其实就是：
CPU Time相对于其它等待事件，应当先忽略CPU Time，处理其它等待事件。而且cpu time高一般代表是好事情，因为系统并没有把时间耗费在Wait上。Elapsed Time = CPU Time + Wait Time，所以甚至我们可以说CPU Time越高越好。
不是说他的不对，只是比较觉得这句话太容易误导别人，所以，给一些补充建议，我同意如果有很明显的其它事件，而cpu time不明显的时候，可以优先处理其它事件。但是，还有以下2个地方需要注意：
1、cpu time高一般代表系统的逻辑读大，或者是高计算型的东西，如case函数，decode函数，自定义的计算类型函数等等，把cpu给耗光了，但是这个时候可能根本没有其它等待事件。这样是否证明这个系统很好呢？很可能是，非常不好，因为他很有可能没有必要有这么多的逻辑多，或者是，没有必要有这么多的cpu密集型计算就可以完成的任务，现在消耗这么CPU Time就是不正常的，很容易导致系统负载异常。
2、至于wait time，比如OLTP环境上最典型的db file sequential read引起的等待，是因为发生了物理io而引起的，而很多时候，物理读是随逻辑读增加而增加的，而逻辑读可能会导致cpu time高，也就是说，cpu time与wait time一般是同时增加的。特别是比较高访问量，大数据量，大SGA的系统，逻辑读与物理读都比较高，除了cpu time与db file sequential read，可能不会有很明显的其它等待事件，而优化的结果可能是cpu time与wait time同时减少。
既然说到了db file sequential read，也解释一下这个事件，与cpu time一样，很多时候说明系统是比较正常的，一个优化非常良好的系统，很可能第一个等待事件就是它。因为没有一个系统，不会发生任何物理IO，既然有物理IO，当然db file sequential read就是最好的了，一般表示读数据正常。同样的理由，db file sequential read大了，也可能预兆系统有不该有的物理读发生了。
如一个看起来很正常的sql语句，单个语句效率看起来并不差，执行时间已经小于0.01秒。假定原来逻辑读每个语句平均是100个，物理读平均10个，执行次数每小时50万次，优化完成以后，逻辑读降低为平均50个，物理读平均5个，那么，每小时降低的逻辑读总量就是50*50w=2500w个，降低的物理读为5*50w=250w个。那么再假定每个cpu每秒处理100000个逻辑读就达到了极限，每个物理读需要等待8ms，那么，就可以减少约2500w/100000*3600=7%的CPU使用率（单CPU），可以减少250w*8ms=20000秒的总io wait time。
同理，如果能采用同样的方法，减少执行次数从每小时50w到每小时25w，则收到的效果是一样的。
评价这个cpu time与db file sequential read是否正常，需要很多调优的经验，不过，需要记住的是，任何情况下，不要绝对的说好还是不好。最好的方式就是从statspack或者是awr上看看，排在cpu time，或者是物理读top的语句，他们是否应当有这么大的消耗，他们是否应当执行这么多的次数。
扫一扫
1335
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
