RAC全域性等待事件分析[@more@]

在RAC環境中，和全域性調整快取相關的最常見的等待事件是：global cache cr request，global cache busy和equeue

如spreport中的top 5 wait events中出現了global cache cr request等待事件，

那麼這個等待事件是什麼原因引起的呢？

首先，我們來看看這個等待事件是如何產生的，當一個程式訪問需要一個或者多個塊時，oracle會首先檢查自己的CACHE是否存在該塊，如果發現沒有，就會先透過global cache賦予這些塊共享訪問的許可權，然後再訪問。假如，透過global cache 發現這些塊已經在另一個例項的CACHE裡面，那麼這些塊就會透過CACHE FUSION,在節點之間直接傳遞，

同時出現global cache cr request等待事件

注意：在10G中，global cache cr request 已經簡稱為 gc cr request

從remote cache運輸塊到本地cache花費的時間還得看這些塊是共享還是獨佔模式，如果塊是共享(scur)的，REMOTE CACHE就克隆資訊傳送過來，否則就要產生一個PI，然後再傳送過去。顯然，global cache cr request等待事件和db file sequential/scattered read 等待事件有著直接的關係。

通常，RAC中的程式會等待1S去嘗試從本地或者遠端CACHE讀取資料塊資訊，當然，這還得依靠塊處於什麼樣的模式。如果超過了1S，那就表明節點之間連線慢，這個時候節點之間就使用private連線，而客戶端的連線使用public，有時候，節點之間的連線， Cache Fusion就不會透過公共網路，在這種情況下，就會有大量的global cache cr request等待事件出現，你可以使用oradebug ipc命令去驗證下節點之間的連線是否使用了private network。

例如：

SQL> oradebug setmypid

Statement processed.

SQL> oradebug ipc

Information written to trace file.

SQL> oradebug tracefile_name

/home/oracle/admin/rac/udump/rac1_ora_3194.trc

SKGXPCTX: 0xb3ca990 ctx

admono 0x1e00b916 admport:

SSKGXPT 0xb3caa78 flags info for network 0

socket no 8 IP 192.168.1.1 UDP 53064

sflags SSKGXPT_UP

info for network 1

socket no 0 IP 0.0.0.0 UDP 0

sflags SSKGXPT_DOWN

active 0 actcnt 1

context timestamp 0

從上面你可以看到IP 92.168.1.1在Cache Fusion使用，而且協議是UDP預設情況下，節點之間的連線是採取TCP協議的，為了更改這個而使用告訴內部連線，你需要進行以下操作。例如，預設情況下，在LINUX作業系統上，節點之間的連線使用UDP，這個資訊你可以從後臺日誌中看到：

cluster interconnect IPC version:Oracle UDP/IP

IPC Vendor 1 proto 2 Version 1.0

為了使用高速連線，關閉ORACLE所有服務，重新連線如下：

$ make -f ins_rdbms.mk rac_on ipc_hms ioracle

如果你想重新使用UDP，則

$ make -f ins_rdbms.mk rac_on ipc_udp ioracle

當會話從開始提交一致讀的請求，到它獲取請求資訊，這個過程它是SLEEP狀態的，對我們而言，看到的就是global cache cr request等待事件，而wait time就是記錄這個過程的時間。

通常，大量的global cache cr request主要有以下幾個原因：

1 節點之間內部連線慢或者節點之間傳輸頻寬窄。這個可以透過重新連線獲取高速連線

2 存在熱點資料塊的競爭

3 CPU負載過高或者LMS後臺程式不夠。正常情況下，只有兩個LMS後臺程式從CPU那裡獲取資源，增加LMS程式的數量或者提高它的優先權能夠幫助從CPU那裡獲取更多的資源。隱藏引數 _lm_lms是設定LMS程式數量的

4 大量未提交的事務或者系統磁碟裝置傳輸慢

有關global cache的資訊：

SQL> select name,value from v$sysstat where name like '%global cache%';

NAME VALUE

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

global cache gets 1791587

global cache get time 85911

global cache converts 179612

global cache convert time 1262

global cache cr blocks received 17189

global cache cr block receive time 31547

global cache current blocks received 4627

global cache current block receive time 763

global cache cr blocks served 16805

global cache cr block build time 72

global cache cr block flush time 25043

NAME VALUE

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

global cache cr block send time 54

global cache current blocks served 3529

global cache current block pin time 21

global cache current block flush time 0

global cache current block send time 15

global cache freelist waits 285

global cache defers 2

global cache convert timeouts 0

global cache blocks lost 0

global cache claim blocks lost 0

global cache blocks corrupt 0

NAME VALUE

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

global cache prepare failures 8

global cache skip prepare failures 3408

24 rows selected.

透過查詢V$BH檢視，獲取當前緩衝區的資訊：

SQL> select status,count(*)from v$bh group by status;

STATU COUNT(*)

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

cr 67

free 8571

scur 10636

xcur 43094

上面的2，4可透過減少PI和緩衝區的CR複製緩解global cache cr request等待事件，

實際上2的處理方法和處理db file sequential/scattered read 等待事件是一樣的

RAC全域性等待事件分析

相關文章