'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个数增加并且各个实例值保持一致后，问题得到解决。
如果发现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参数设置。
第二步，参看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 参考资料: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)
更多信息，可以参考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官方文档：
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上，有的时候CPU可能是动态增加的，那么一定要注意检查LMS进程的个数是否随之调整了。
这种等待产生的主要原因：
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个数增加并且各个实例值保持一致后，问题得到解决。
-
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
如果发现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参数设置。
-
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相关参数设置，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 参考资料: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
-
-
可以将这几个值都设为4k：
-
net.core.rmem_default = 4194304
-
net.core.rmem_max = 4194304
-
net.core.wmem_default = 4194304
-
net.core.wmem_max = 4194304
-
-
HP上：
-
-
请检查UDP设置是否足够大：
-
$ /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设置：
-
ndd /dev/udp udp_xmit_hiwat
-
ndd /dev/udp udp_recv_hiwat
-
ndd /dev/udp udp_max_buf
-
-
可以用下面的命令设置这两个值为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)
第三步，查看网络情况。
比如用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官方文档：
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上，有的时候CPU可能是动态增加的，那么一定要注意检查LMS进程的个数是否随之调整了。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/20674423/viewspace-1287004/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
Oracle 最简单的随系统自动启动
请登录后发表评论
登录
全部评论
