关于RAC环境下的等待事件的一点自己的理解

今天在论坛上看到这一篇帖子： http://www.itpub.net/viewthread.php?tid=1229973&page=1#pid14475336

 

关于RAC环境下的等待事件的一点自己的理解

---------------------------------------------------------------

关于 RAC 环境下的等待事件的一点自己的理解 --copy...

b最近有些闲时间，就看一些文档。看到精彩处，就想翻译一下。但自己的水平有限，有的理解理解错误，有的地方理解不够深刻，权当抛砖引玉。

下面贴的英文都出自oracle10gRAC的官方培训课程。

分析session在等待什么是非常重要的，这样才能看出究竟时间是花在了什么地方。在RAC环境下，等待时间被归结为一个事件，反映了一个请求的最终的结果（这句话理解起来感觉有些困难。我的理解是当我在RAC环境下请求一个块时，会经过不同的途径得到这个块，或者失败，不同的结果对应不同的等待事件，我想在后面再描述描述关于不同的结果产生不同的等待事件）。举个例子，当一个实例的某个session，想global cache中looking一个block的时候，它是不知道它会从那个实例获得这个block，或者是收到一个消息，然后去disk读该block。the wait events for the global cache convey precise information and wait for global cache blocks or messages.上面这句英文不知道怎么翻译。这些事件被总结为以下：

u 所有的事件都叫cluster wait class（我感觉好像这句话没用，我的理解是关于RAC的事件都被归为一类，那就是cluster类等待事件，从v$event_name中可以查询，cluster类的事件10.2.0.3是47个）

u 在等待block的整个过程中，都临时表示为placeholder event（这句话的意思是某个instance的某个session在请求一个block（或多个）的时候，oracle的internal code就会写一个等待事件，这个等待事件被看成是placeholder event，占位事件，只到这个请求block的过程结束。placeholder event，包括gc cr request、gc current request等，这类事件没有表示出最终请求这个block的结果，是从别的instance获得了这个block呢，还是别的instance传过来一个message，告诉这个instance去磁盘上读该block呢）

u 当请求一个块结束的时候，也就是说整个请求过程结束的时候，会有更精确的事件产生。此类事件，例如gc cr 2-way（表示经过两个network hop获得了该block）、gc buffer busy（表示没有获得该block，该block被别的进程占用）。看此类事件，是应该知道一个block的请求过程的。关于network hop，看到kamus的解释，明白了。kamus举了个例子，说比如当一个instance请求一个block时（该isntance被称为requester），它会首先查看resource master table，找到这个block的master instance，然后请求这个block的master instance（这是一个network hop），这个block的master instance（该instance被称为master）发现这个block实际在另外的实例上（该实例被称为holder），master要求holder将这个block传给requester（这又是一个network hop），holder将该block传递给requester（这又是一个network hop），理解network hop就是一次网络通信吧

感觉下面这个图非常的好，理解这个图，对于RAC的等待事件，就理解差不多了。下面对这个图的英文我翻译了一下，自己理解上还是有一些欠缺。

将该图从上往下看，上面的gc [current/cr] [multiblock] request实际上就是placeholder的event，图的左上角也做了说明。

gc [current/cr] [multiblock] request实际上是表示了四个事件中的一个（gc current request、gc cr request、gc current multiblock request、gc cr multiblock request）。current 和cr的不同，相信大家都很熟悉，如果是读的话，那就是cr request，如果是更改的话，那就是current request。现在感觉10g在很多地方区分了multiblock request还是singleblock request，这样容易分析业务的数据特点吧。当在RAC环境下，一个session请求一个block的时候，就会触发这个事件。

u 当请求一个block时，如果经过两个或者三个network hop就获得了该块的话，那就会产生gc [current/cr] [2/3]-way。如果是3-way,那应该是master和holder不是同一个instance，如果是2-way，那就应该是master和holder是同一个instance，这是自己的理解，还没有在文档上看到。这应该是最好的情况，请求后，就获得了，请求的block即没有busy，也没有说在请求的过程中等待。该类事件应该暗示是进行了block的网络传递，会产生流量，而grant 2-way的网络流量应该相对小吧

u gc [current/cr] block busy 是说虽然也返回了，但是没有immediate send，我的理解是控制流程返回了，但是实际的block并没有马上传递到requester instance（自己还不是很清楚），gc [current/cr] block busy是和gc [current/cr] [2/3]-way对应的，一个是通过两个或者三个network hop获得了该块，另外一个是说busy

u gc [current/cr] grant 2-way 当请求一个block时，receive了一个message，该message应该是赋予了requester instance可以访问这个block。如果这个block没有在local cache中，则随后的动作就是去磁盘上读该block。（插一点别的，oracle的对数据的访问的控制，是在row级别和object级别，但是实际操作的对象却是block，传递的对象也是block，对于一个block，来说，会有一个master instance，也就是这个block的管理者，然后还有零到多个参与者，比如有的instance为了读一致性，可能会在自己的local cache中存着该block的过去某个时间的image，有的instace为了修改该block，可能会在自己的local cache中存着该block的past image）

u gc current grant busy 当一个instance请求一个block时，被告诉是busy的。不明白在什么情况下会产生grant busy的事件

u gc [current/cr] [block/grant] congested 我对这几个事件的理解是无论是对于current还是cr类型的block或者grant，都获得了，但是在过程中有拥堵。也就是在内部的队列中等待超过1msec（纳秒）

u gc [current/cr] [failure/retry] 这就是发生错误了，没有请求到block

u gc buffer busy 对于gc buffer busy的解释我是看不懂，自己的理解是和single instance的buffer busy一样，多个进程在同时访问一个block，造成锁竞争了。

我现在对于RAC这一块的cache fusion，我的想法是通过分区应用，尽量让一个实例只访问数据库的部分数据，来减少cache fusion的次数（不知道是不是是这样）。如果cache fusion的竞争真的发生了，我现在还真不知道从什么地方下手呢。

在网上看了一篇文章http://www.oralife.cn/html/2008/429_gc-cr-buffer-busy.html

gc cr busy

看到如下代码，既熟又感慨吧

Module Operation
Kdifbk： Fetches the single index row matching the argument key.
Kdusru： Updates the single row piece.
Kdifind： Finds the appropriate index block to store the key.
Kdstgr ：Performs full table scan get row. Rows are accessed by a full table scan. Check the number of FULL table scans
Kdsgrp ：Performs get row piece. Typically, row pieces are affected only in case of chained and migrated rows. Row chaining has to be analyzed and fixed.
Kdiixs ：Performs index range scan.
Kdifxs ：Fetches the next or previous row in the index scan.
Kdifbk ：Fetches the single index row matching the agreement key.
Ktugct ：Block cleanout.

做个记号，有环境的时候看看！

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/11782778/viewspace-617521/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/11782778/viewspace-617521/