如何診斷RAC系統中的

wuweilong發表於2014-10-01
  'gc cr multi block request' 是RAC資料庫上比較常見的一種等待事件，在RAC 上進行全表掃描(Full Table Scan)或者全索引掃描(Index Fast Full Scan）時，容易產生這樣的多塊讀等待。

     這種等待產生的主要原因：
1. 資料庫引數db_file_multiblock_read或者db_block_size設定太大，導致多塊讀時GC傳輸量太大；
2. OS上UDP相關的引數設定不夠大導致接收傳送UDP的快取區溢位；
3. 私網效能；
4. LMS設定問題（個數不足或者不是實時執行(real time)）導致LMS的處理能力不夠，不能及時傳輸global cache data/message。

    這方面的Bug比較少，在11.2之前有一個BUG 8464597，當db_block_size = 32k時，引發大量"gc cr multi block request" 而且效能下降，這個Bug在11.2已經修復。
    很多情況下，降低DB_FILE_MULTIBLOCK_READ_COUNT 並且 加大OS UDP相關引數會將極大緩解'gc cr multi block request' 等待。

     最近處理了一個問題，從10.2升級到11.2.0.3後產生大量'gc cr multi block request' 等待，發現DB_FILE_MULTIBLOCK_READ_COUNT， UDP 引數等都沒有改變，只是升級後LMS的個數在不同例項間不同而且下降了很多，後來把LMS個數增加並且各個例項值保持一致後，問題得到解決。
  1. Avg
  2.                                                           wait % DB
  3. Event Waits Time(s) (ms) time Wait Class
  4. ------------------------------ ------------ ----------- ------ ------ ----------
  5. gc cr multi block request 632,923 32,441 51 35.5 Cluster
  6. DB CPU 13,518 14.8
  7. gc cr grant 2-way 327,717 10,900 33 11.9 Cluster
  8. gc current grant 2-way 190,856 6,855 36 7.5 Cluster
  9. gc current block 2-way 101,154 3,792 37 4.1 Cluster

如果發現AWR TOP5 等待中存在'gc cr multi block request' 而且它的Avg wait(ms)較高，那麼請參考下面的診斷步驟：如果發現AWR TOP5 等待中存在'gc cr multi block request' 而且它的Avg wait(ms)較高，那麼請參考下面的診斷步驟：
第一步，檢視db_file_multiblock_read_count和db_block_size引數設定。
  1. SQL>show parameter db_block_size
  2. SQL>show parameter db_file_multiblock_read_count

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

第二步，參看OS udp相關引數設定，udp 的引數在不同的OS上是不同的，這些引數會設定UDP的接收快取區和傳送快取區的大小，一般來說接收緩存區要>=傳送快取區。 如果在生產庫修改這些引數，最好諮詢OS廠商瞭解注意事項。

AIX上：
#no –a
                udp_recvspace
                udp_sendspace

o 設定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.注意這個值只是最低值，並不是Oracle要求必須設定這麼大。
o 設定udp_recvspace 為 4到10倍 udp_sendpace
o 由於sb_max 必須 >= udp_recvspaceIf ，可能需要增加sb_max的值(預設為1048576)
o 如果udp的引數設定不合理，可能會產生“socket buffer overflows”，如果這個值非0， 需要增加udp_recvspace:
 netstat -s | grep "socket buffer overflows" 
o 參考資料:
  Minimum Software Versions and Patches Required to Support Oracle Products on IBM Power Systems (Doc ID 282036.1)

  1. Linux上:
  2. #More /etc/sysctl.conf

  4. net.core.rmem_default
  5. net.core.rmem_max
  6. net.core.wmem_default
  7. net.core.wmem_max

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

  19. 可以將這幾個值都設為4k：
  20. net.core.rmem_default = 4194304
  21. net.core.rmem_max = 4194304
  22. net.core.wmem_default = 4194304
  23. net.core.wmem_max = 4194304

  25. HP上：

  27. 請檢查UDP設定是否足夠大：
  28. $ /bin/ndd -get /dev/sockets socket_udp_rcvbuf_default
  29. $ /bin/ndd -get /dev/sockets socket_udp_sndbuf_default

  31. 確保socket_udp_rcvbuf_default至少是socket_udp_sndbuf_default的兩倍。

  33. Sun：
  34. 可以用下面的命令檢視UDP設定：
  35. ndd /dev/udp udp_xmit_hiwat
  36. ndd /dev/udp udp_recv_hiwat
  37. ndd /dev/udp udp_max_buf

  39. 可以用下面的命令設定這兩個值為OS最大允許的：
  40. ndd -set /dev/udp udp_xmit_hiwat
  41. ndd -set /dev/udp udp_recv_hiwat
  42. ndd -set /dev/udp udp_max_buf <1M or higher>


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

第三步，檢視網路情況。
比如用netstat -s 命令檢視是否有bad data length, bad checksums, incomplete headers, socket buffer overflows等，注意這些值是累計的，需要檢視它們在發生問題的時候是否有增加。
另外可以檢視AWR中是否有 "Global Cache Blocks Lost" ，理想情況下這個值是0，如果有較大的block lost，說明網路有問題(按照MOS 文件563566.1進行網路檢查)。
還可以請網管檢視私網的效能情況。

第四步，檢查LMS。
1. 檢視LMS的trace file，檢視是否有異常。
2. 檢視LMS程式的優先順序是否是實時的(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 越小說明優先順序越高，PRI小於40說明是Real Time的：
http://aix4admins.blogspot.co.uk/2011/08/commands-and-processes-process-you-use.html

3. 檢視LMS的個數:
SQL>show parameter GCS_SERVER_PROCESSES
這個值決定了LMS的個數

這個值依賴於CPU的個數(cpu_count)，根據11.2官方文件：

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上，有的時候CPU可能是動態增加的，那麼一定要注意檢查LMS程式的個數是否隨之調整了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/20674423/viewspace-1287004/，如需轉載，請註明出處，否則將追究法律責任。

相關文章