如何診斷RAC系統(tǒng)中的'gc cr multi block request'?

     'gc cr multi block request' 是RAC數(shù)據(jù)庫(kù)上比較常見的一種等待事件，在RAC 上進(jìn)行全表掃描(Full Table Scan)或者全索引掃描(Index Fast Full Scan）時(shí)，容易產(chǎn)生這樣的多塊讀等待。

     這種等待產(chǎn)生的主要原因：
1. 數(shù)據(jù)庫(kù)參數(shù)db_file_multiblock_read或者db_block_size設(shè)置太大，導(dǎo)致多塊讀時(shí)GC傳輸量太大；
2. OS上UDP相關(guān)的參數(shù)設(shè)置不夠大導(dǎo)致接收發(fā)送UDP的緩存區(qū)溢出；
3. 私網(wǎng)性能；
4. LMS設(shè)置問題（個(gè)數(shù)不足或者不是實(shí)時(shí)運(yùn)行(real time)）導(dǎo)致LMS的處理能力不夠，不能及時(shí)傳輸global cache data/message。

    這方面的Bug比較少，在11.2之前有一個(gè)BUG 8464597，當(dāng)db_block_size = 32k時(shí)，引發(fā)大量"gc cr multi block request" 而且性能下降，這個(gè)Bug在11.2已經(jīng)修復(fù)。
    很多情況下，降低DB_FILE_MULTIBLOCK_READ_COUNT 并且 加大OS UDP相關(guān)參數(shù)會(huì)將極大緩解'gc cr multi block request' 等待。

     最近處理了一個(gè)問題，從10.2升級(jí)到11.2.0.3后產(chǎn)生大量'gc cr multi block request' 等待，發(fā)現(xiàn)DB_FILE_MULTIBLOCK_READ_COUNT， UDP 參數(shù)等都沒有改變，只是升級(jí)后LMS的個(gè)數(shù)在不同實(shí)例間不同而且下降了很多，后來(lái)把LMS個(gè)數(shù)增加并且各個(gè)實(shí)例值保持一致后，問題得到解決。

                                                                Avg
                                                          wait   % DB
Event                                 Waits     Time(s)   (ms)   time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
gc cr multi block request           632,923      32,441     51   35.5 Cluster
DB CPU                                           13,518          14.8
gc cr grant 2-way                   327,717      10,900     33   11.9 Cluster
gc current grant 2-way              190,856       6,855     36    7.5 Cluster
gc current block 2-way              101,154       3,792     37    4.1 Cluster

如果發(fā)現(xiàn)AWR TOP5 等待中存在'gc cr multi block request' 而且它的Avg wait(ms)較高，那么請(qǐng)參考下面的診斷步驟：

第一步，查看db_file_multiblock_read_count和db_block_size參數(shù)設(shè)置。

SQL>show parameter db_block_size
SQL>show parameter db_file_multiblock_read_count

db_block_size一般為8192, db_file_multiblock_read_count一般為16. 

第二步，參看OS udp相關(guān)參數(shù)設(shè)置，udp 的參數(shù)在不同的OS上是不同的，這些參數(shù)會(huì)設(shè)置UDP的接收緩存區(qū)和發(fā)送緩存區(qū)的大小，一般來(lái)說(shuō)接收緩存區(qū)要>=發(fā)送緩存區(qū)。 如果在生產(chǎn)庫(kù)修改這些參數(shù)，最好咨詢OS廠商了解注意事項(xiàng)。

AIX上：
#no –a
                udp_recvspace
                udp_sendspace

o 設(shè)置udp_sendspace >=[(DB_BLOCK_SIZE * DB_FILE_MULTIBLOCK_READ_COUNT) + 4096]，但是不低于 65536. 
  比如，DB_BLOCK_SIZE=8192, DB_FILE_MULTIBLOCK_READ_COUNT=16，那么udp_sendspace>= (8192 * 16) + 4096=135168.注意這個(gè)值只是最低值，并不是Oracle要求必須設(shè)置這么大。
o 設(shè)置udp_recvspace 為 4到10倍 udp_sendpace
o 由于sb_max 必須 >= udp_recvspaceIf ，可能需要增加sb_max的值(默認(rèn)為1048576)
o 如果udp的參數(shù)設(shè)置不合理，可能會(huì)產(chǎn)生“socket buffer overflows”，如果這個(gè)值非0， 需要增加udp_recvspace:
 netstat -s | grep "socket buffer overflows" 
o 參考資料:http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100883
  Minimum Software Versions and Patches Required to Support Oracle Products on IBM Power Systems (Doc ID 282036.1)

Linux上:
#More /etc/sysctl.conf

net.core.rmem_default
net.core.rmem_max
net.core.wmem_default
net.core.wmem_max

官方文檔上要求的最低值：
http://docs.oracle.com/cd/E11882_01/install.112/e24321/pre_install.htm#BABDAEDB
Oracle Database Installation Guide
11g Release 2 (11.2) for Linux
E24321-07
rmem_default     262144     
rmem_max     4194304 
wmem_default     262144     
wmem_max     1048576

可以將這幾個(gè)值都設(shè)為4k：
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 4194304
net.core.wmem_max = 4194304

HP上：

請(qǐng)檢查UDP設(shè)置是否足夠大：
$ /bin/ndd -get /dev/sockets socket_udp_rcvbuf_default
$ /bin/ndd -get /dev/sockets socket_udp_sndbuf_default

確保socket_udp_rcvbuf_default至少是socket_udp_sndbuf_default的兩倍。

Sun：
可以用下面的命令查看UDP設(shè)置：
ndd /dev/udp udp_xmit_hiwat
ndd /dev/udp udp_recv_hiwat
ndd /dev/udp udp_max_buf

可以用下面的命令設(shè)置這兩個(gè)值為OS最大允許的：
ndd -set /dev/udp udp_xmit_hiwat
ndd -set /dev/udp udp_recv_hiwat
ndd -set /dev/udp udp_max_buf <1M or higher>

更多信息，可以參考MOS文檔：
Tuning Inter-Instance Performance in RAC and OPS (Doc ID 181489.1)

第三步，查看網(wǎng)絡(luò)情況。
比如用netstat -s 命令查看是否有bad data length, bad checksums, incomplete headers, socket buffer overflows等，注意這些值是累計(jì)的，需要查看它們?cè)诎l(fā)生問題的時(shí)候是否有增加。
另外可以查看AWR中是否有 "Global Cache Blocks Lost" ，理想情況下這個(gè)值是0，如果有較大的block lost，說(shuō)明網(wǎng)絡(luò)有問題(按照MOS 文檔563566.1進(jìn)行網(wǎng)絡(luò)檢查)。
還可以請(qǐng)網(wǎng)管查看私網(wǎng)的性能情況。

第四步，檢查L(zhǎng)MS。
1. 查看LMS的trace file，查看是否有異常。
2. 查看LMS進(jìn)程的優(yōu)先級(jí)是否是實(shí)時(shí)的(real time）的？

比如AIX:
# ps -elf|grep lms

ps -elf|grep lms
F      S      UID      PID     PPID   C PRI NI ADDR    SZ    WCHAN    STIME    TTY  TIME CMD 
240103 A   oracle  4719002        1   5  39 -- 8ae40b590 248856            Jul 28      - 570:45 ora_lms0_rac1

priority 越小說(shuō)明優(yōu)先級(jí)越高，PRI小于40說(shuō)明是Real Time的：
http://aix4admins.blogspot.co.uk/2011/08/commands-and-processes-process-you-use.html

3. 查看LMS的個(gè)數(shù):
SQL>show parameter GCS_SERVER_PROCESSES
這個(gè)值決定了LMS的個(gè)數(shù)

這個(gè)值依賴于CPU的個(gè)數(shù)(cpu_count)，根據(jù)11.2官方文檔：
http://docs.oracle.com/cd/E11882_01/server.112/e25513/initparams094.htm#REFRN10259
Default value
If 1 - 3 CPUS, then 1
If 4 - 15 CPUs, then 2
If 16 or more CPUs, then 2 + (CPUs / 32). If the result includes a fraction, then the fraction is disregarded. For example, if you had 20 CPUs, then 2 + (20 / 32) would equal 2 GCS processes.
If CLUSTER_DATABASE is set to false, then 0
If ASM, then 1

在AIX上，有的時(shí)候CPU可能是動(dòng)態(tài)增加的，那么一定要注意檢查L(zhǎng)MS進(jìn)程的個(gè)數(shù)是否隨之調(diào)整了。

有關(guān)這個(gè)問題的討論，可以在中文社區(qū)帖子中進(jìn)行 如何診斷RAC系統(tǒng)中的'gc cr multi block request'?