37.Oracle深度学习笔记——RAC的相关等待事件

37.Oracle深度学习笔记——RAC的相关等待事件

欢迎转载，转载请标明出处：http://blog.csdn.net/notbaron/article/details/50891037

在性能BENCHMARK中碰到的几个等待事件：

gc cr multi block request

multi block一般情况下都是全表扫描或全索引扫描导致， gc cr multiblock request 会造成CPU 对内存的调度和管理，会消耗CPU时间。

当进程请求数据库块时，首先会在本地的CACHE里面查看是否存在，这种查看是根据DBA (Data Block Address) 转化为cache bufferschains,然后再从hash bucket确认是否存在。
如果在本地没发现有块的CACHE，进程就会请求resourcemaster授予共享访问给数据块，然后再去获取数据块的CACHE。
如果请求的BLOCK CACHE在远程的节点，resourcemaster就会使用内部通讯把远程的CACHE传输到本地。当请求的CACHE BUFFER是共享模式的，远程节点就会克隆一个然后传输到本地。非则，就建立PI映像，然后传输到本地。

 这种等待产生的主要原因： 
1. 数据库参数db_file_multiblock_read或者db_block_size设置太大，导致多块读时GC传输量太大
2. OS上UDP相关的参数设置不够大导致接收发送UDP的缓存区溢出
3. 私网性能
4. LMS设置问题（个数不足或者不是实时运行(realtime)）导致LMS的处理能力不够，不能及时传输global cache data/message

gc current block 2-way:

 1.Sga 1 发送请求道SGA2 request block  SGA1 产生gc current blockrequest .

2.SGA2 检查这个block是否被改变 如果已被改变的话LMS  则会要求LGWR 写redo log  （这时SGA1 会显示busy）  然后传送。

3.SGA2 发送NODE 并产生Gc current block 2-way 等待 直到BLOCK 发送到SGA1 等待终结。

当发送NODE 过程中 对这个block的请求将会产生 GCbuffer busy.

 

3 way: 就是多一个节点  resource MASTER 和 cached 节点不是同一个节点。

 

当前块的等待事件意味着被传输的块的版本是块的最新版本。这个等待事件读取和写入活动中都可能遇到。如果该块被访问是以读取活动进行，那么该资源上锁以KJUSERPR（PR）模式获得。刚才我在“资源和锁定”一节中所讨论的示例展示了KJUSERPR模式的锁。

在下面的例子中，我从表t_one中查询一行，造成连接到节点2的磁盘读。查看SQL跟踪文件，没有全局缓存等待事件。原因是该块被本地掌控（本地实例是master），所以FG进程中可直接获取该资源上锁，而不会产生任何全局缓存等待。这种类型的锁也被称为亲和力锁定（相似度锁定）方案。动态掌握资源（DRM，Dynamic Resource Mastering）的部分将详细讨论相似度锁定（亲和力锁定）。

GC CR Block 2-Way/3-Way

CR模式的块传输发生在只读访问的请求中。考虑这样一个场景：一个块以CURRENT模式驻留在实例2上，实例2以独占模式保持了该资源的BL锁。另一个会话连接到实例1来请求该块，阻止。由于Oracle数据库中“其他人看不到未提交的更改”，SELECT语句请求一个查询开始时间的块的特定版本。SCN被用于标识块版本，本质上，SELECT语句请求的版本与块的SCN一致。LMS进程维护实例2的请求，以CURRENT的模式克隆该块到缓冲区，验证SCN版本与请求是一致的，然后发送该块的CR拷贝给FG进程。

这些CR模式传输和CURRENT模式传输之间的主要区别在于，在CR模式传输的情况下，在GRD中没有资源或锁来维护CR缓冲区。从本质上讲，CR模式块不需要全局缓存资源或锁。接收到的CR副本只能由提出请求的会话使用，并且只适用于这个特定的SQL执行中。这就是为什么Oracle数据库不对CR传输获取BL资源的任何锁。

由于没有全局缓存锁保护缓冲区，连接到实例1再次执行这个SQL语句访问那个块时将遭遇gc cr block 2-way 或者 gc cr block 3-way等待事件。

因此，每次从实例1访问该块都将触发新CR缓冲区的构造。即使在实例2的缓冲区没有发生该块修改，在实例1中的FG进程仍然会遭遇到CR等待事件。驻留在实例1的CR缓冲区是不能重复使用的，因为每SQL执行请求查询时的SCN会有所不同。

下面的跟踪显示了一个块从资源主实例以0.6毫秒的延迟被传输到请求实例。另外，file_id，BLOCK_ID，和跟踪文件中的object_id信息，可以被用来识别正在遭遇这两个等待事件的对象。当然，也可以通过查询ASH数据来识别该对象。

GC CR Grant 2-Way/Gc Current Grant 2-Way

如果被请求的块没有驻留在任何缓冲区中，就会遭遇gc cr grant 2-way 和 gc current grant 2-way等待事件。FG进程向LMS进程请求一个块，但块没有驻留在任何缓冲区。因此，LMS进程回复一条授权FG进程从磁盘读取的块的消息。FG进程从磁盘读取该块并继续后续的处理。

下面一行显示了为了访问file_id=4和lock_id=180数据块，FG进程接收到来自LMS进程的授权响应。下一行显示了，执行了一个从磁盘读取块的物理读。

nam=’gc cr grant 2-way’ ela= 402 p1=4 p2=180p3=1 obj#=75742

nam=’db file sequential read’ ela= 553file#=4 block#=180 blocks=1 obj#=75742

过多的此类等待意味着，要么缓冲区高速缓存太小，要么SQL语句的执行过分的刷新了缓冲区高速缓存。识别正在遭遇此类等待事件的SQL语句和对象，并优化这些SQL语句。

DRM功能的设计就是为了减少发生这类授权相关的等待事件。

GC CR Block Busy/GC Current Block Busy

繁忙事件（Busy events）表明，LMS执行了额外的工作去处理并发相关的问题。例如，要建立一个CR块，LMS进程可能要应用撤消记录（undo records），重构一个与查询的SCN一致的块。在把该块回传给FG过程时，LMS将标记块传输是否遇到gc cr block busy或gc current block busy等待事件，这取决于块传输的类型。

GC CR Block Congested/GC Current Block Congested

如果LMS进程在接收到请求后没有在1毫秒内处理该请求，那么LMS进程标记这个响应为：该块正遭遇拥堵相关的等待事件。堵塞相关的等待事件有很多原因，比如说，LMS进程被大量全局高速缓存的请求所淹没。LMS进程正遭遇CPU的调度延迟，LMS进程已经遇到了另一种资源耗尽（如内存）等。

通常情况下，LMS进程运行在实时CPU调度优先级，因此，CPU调度的延迟将是最小的。大量这类的等待此事件表明出现了全局缓存请求的突然飙升，且LMS进程无法快速处理这些请求。服务器内存匮乏也可能导致LMS进程的分页，影响全局缓存的性能。