Comments on: 10gRAC培训 - 2 and last http://www.dbform.com/html/2007/337.html 面朝大海，春暖花开 Thu, 04 Dec 2008 20:43:07 +0000 http://wordpress.org/?v=2.1 By: 木匠 http://www.dbform.com/html/2007/337.html#comment-16106 木匠 Thu, 09 Aug 2007 18:01:25 +0000 http://www.dbform.com/html/2007/337.html#comment-16106 那么趁着你正热乎着, 帮忙给分析看看下面这个等待时间的起因和解决方法: Wait: gc current request, Class: Cluster Oracle 10.1.0.4 RAC on Linux 那么趁着你正热乎着, 帮忙给分析看看下面这个等待时间的起因和解决方法:

Wait: gc current request, Class: Cluster

Oracle 10.1.0.4 RAC on Linux

]]> By: kamus http://www.dbform.com/html/2007/337.html#comment-16107 kamus Thu, 09 Aug 2007 18:36:04 +0000 http://www.dbform.com/html/2007/337.html#comment-16107 在数据库的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是慢在哪里了。 在数据库的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是慢在哪里了。

]]> By: victor666666 http://www.dbform.com/html/2007/337.html#comment-16109 victor666666 Fri, 10 Aug 2007 00:52:16 +0000 http://www.dbform.com/html/2007/337.html#comment-16109 RAC我见过的一般都是2、3个节点，遇到的工程师都胜传4~6个节点时db慢的不行，想了一下，如果对于一个点如A节点(相对于剩下的节点既是master也是requester)，是不是RAC中的点越多，对A点的请求或A对其它点的请求会越多，导致了资源紧张，尤其是在load balance做了session分摊的情况下 RAC我见过的一般都是2、3个节点，遇到的工程师都胜传4~6个节点时db慢的不行，想了一下，如果对于一个点如A节点(相对于剩下的节点既是master也是requester)，是不是RAC中的点越多，对A点的请求或A对其它点的请求会越多，导致了资源紧张，尤其是在load balance做了session分摊的情况下

]]> By: big_bear http://www.dbform.com/html/2007/337.html#comment-16110 big_bear Fri, 10 Aug 2007 01:10:01 +0000 http://www.dbform.com/html/2007/337.html#comment-16110 真羡慕楼主有这样的机会啊，期待楼主能够把培训资料整理发表出来。 真羡慕楼主有这样的机会啊，期待楼主能够把培训资料整理发表出来。

]]> By: 马艺桐mayitong@hotmail.com http://www.dbform.com/html/2007/337.html#comment-16112 马艺桐mayitong@hotmail.com Fri, 10 Aug 2007 01:55:43 +0000 http://www.dbform.com/html/2007/337.html#comment-16112 10708 trace另外节点的lms进程,楼主能否贴出一个TRACE 分析一下 10708 trace另外节点的lms进程,楼主能否贴出一个TRACE 分析一下

]]> By: 木匠 http://www.dbform.com/html/2007/337.html#comment-16114 木匠 Fri, 10 Aug 2007 04:36:49 +0000 http://www.dbform.com/html/2007/337.html#comment-16114 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过去了. 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过去了.

]]> By: kamus http://www.dbform.com/html/2007/337.html#comment-16116 kamus Fri, 10 Aug 2007 15:46:29 +0000 http://www.dbform.com/html/2007/337.html#comment-16116 @木匠 暂时还没有时间看你的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。 @木匠
暂时还没有时间看你的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。

]]> By: kamus http://www.dbform.com/html/2007/337.html#comment-16117 kamus Fri, 10 Aug 2007 15:54:22 +0000 http://www.dbform.com/html/2007/337.html#comment-16117 @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环境应该会有性能的改善。 @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环境应该会有性能的改善。

]]> By: piner http://www.dbform.com/html/2007/337.html#comment-16137 piner Mon, 13 Aug 2007 02:26:18 +0000 http://www.dbform.com/html/2007/337.html#comment-16137 cpu time多也不一定是好事,只有相对,没有绝对. cpu time多也不一定是好事,只有相对,没有绝对.

]]> By: piner http://www.dbform.com/html/2007/337.html#comment-16138 piner Mon, 13 Aug 2007 02:28:43 +0000 http://www.dbform.com/html/2007/337.html#comment-16138 一般的OS中，wait 是可以被利用的，cpu利用高，很大程度表示逻辑读高，而你的系统是否应当有这么高的逻辑读？ 一般的OS中，wait 是可以被利用的，cpu利用高，很大程度表示逻辑读高，而你的系统是否应当有这么高的逻辑读？

]]> By: kamus http://www.dbform.com/html/2007/337.html#comment-16139 kamus Mon, 13 Aug 2007 03:17:18 +0000 http://www.dbform.com/html/2007/337.html#comment-16139 @piner 自然不是绝对的，但是通常来说是没有问题的。 因为如果是逻辑读高，那么应该会有其它的相关等待事件浮出水面，比如buffer busy等，所以不论何种情况CPU Time应该都不用作为关心的对象 @piner
自然不是绝对的，但是通常来说是没有问题的。
因为如果是逻辑读高，那么应该会有其它的相关等待事件浮出水面，比如buffer busy等，所以不论何种情况CPU Time应该都不用作为关心的对象

]]> By: piner http://www.dbform.com/html/2007/337.html#comment-16150 piner Tue, 14 Aug 2007 15:24:49 +0000 http://www.dbform.com/html/2007/337.html#comment-16150 buffer busy不一定的，我们的系统，这个cpu time高一般都是逻辑读高，或者是大规模计算型函数。 带来的就是负载的升高，调整掉这些就好了，其实要明白一点，逻辑读与一些计算型函数，耗费的就是cpu，如果能减少他们，当然是好事情。 buffer busy不一定的，我们的系统，这个cpu time高一般都是逻辑读高，或者是大规模计算型函数。
带来的就是负载的升高，调整掉这些就好了，其实要明白一点，逻辑读与一些计算型函数，耗费的就是cpu，如果能减少他们，当然是好事情。

]]> By: kamus http://www.dbform.com/html/2007/337.html#comment-16151 kamus Tue, 14 Aug 2007 18:12:14 +0000 http://www.dbform.com/html/2007/337.html#comment-16151 你这样的说法当然也没有问题。 本来需要耗费30%的CPU Time在不降低负载的情况经过调优（比如优化逻辑读等）变成只需要耗费20%的CPU，这当然是好事儿。 我的意思只是说，如果你看到CPU Time在Top 5事件中不需要去特意关注他，这个事件只是说CPU在Run，而其它的等待事件更能说明系统需要调整的地方。 你这样的说法当然也没有问题。
本来需要耗费30%的CPU Time在不降低负载的情况经过调优（比如优化逻辑读等）变成只需要耗费20%的CPU，这当然是好事儿。
我的意思只是说，如果你看到CPU Time在Top 5事件中不需要去特意关注他，这个事件只是说CPU在Run，而其它的等待事件更能说明系统需要调整的地方。

]]> By: vecentli http://www.dbform.com/html/2007/337.html#comment-16268 vecentli Wed, 05 Sep 2007 09:44:55 +0000 http://www.dbform.com/html/2007/337.html#comment-16268 <blockquote><a href="#comment-16116" title="View the original comment" rel="nofollow"><em>kamus on August 10, 2007 at 11:46 pm said:</em></a> @木匠 暂时还没有时间看你的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。</blockquote> 按照这个说法，应该是4-way。 获得block的node活通知gcs，它是新的holder。 10g rac sg。 :)

kamus on August 10, 2007 at 11:46 pm said:

@木匠
暂时还没有时间看你的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。

按照这个说法，应该是4-way。
获得block的node活通知gcs，它是新的holder。

10g rac sg。

:)

]]> By: (转)Oracle CPU Time http://www.dbform.com/html/2007/337.html#comment-20645 (转)Oracle CPU Time Fri, 21 Nov 2008 15:39:07 +0000 http://www.dbform.com/html/2007/337.html#comment-20645 [...] 10gRAC培训 - 2 and last。说到了这个cpu [...] […] 10gRAC培训 - 2 and last。说到了这个cpu […]

]]>