當一個進程訪問需要一個或者多個塊時，它會首先檢查自己的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 等待事件是一樣的，這里不在敘述。

轉載于:https://www.cnblogs.com/zwl715/p/3922233.html

總結

以上是生活随笔為你收集整理的global cache cr request的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。