失眠网,内容丰富有趣,生活中的好帮手!
失眠网 > oracle查询导致 gc等待 如何诊断Oracle RAC系统中的等待事件gc cr multi block request?...

oracle查询导致 gc等待 如何诊断Oracle RAC系统中的等待事件gc cr multi block request?...

时间:2018-09-23 08:51:46

相关推荐

oracle查询导致 gc等待 如何诊断Oracle RAC系统中的等待事件gc cr multi block request?...

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-/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

官方文档上要求的最低值:

/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 TTYTIME CMD

240103 A oracle4719002 1539 -- 8ae40b590 248856 Jul 28 - 570:45 ora_lms0_rac1

priority 越小说明优先级越高,PRI小于40说明是Real Time的:

http://aix4admins.blogspot.co.uk//08/commands-and-processes-process-you-use.html

3. 查看LMS的个数:

SQL>show parameter GCS_SERVER_PROCESSES

这个值决定了LMS的个数

这个值依赖于CPU的个数(cpu_count),根据11.2官方文档:

/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进程的个数是否随之调整了。

如果觉得《oracle查询导致 gc等待 如何诊断Oracle RAC系统中的等待事件gc cr multi block request?...》对你有帮助,请点赞、收藏,并留下你的观点哦!

本内容不代表本网观点和政治立场,如有侵犯你的权益请联系我们处理。
网友评论
网友评论仅供其表达个人看法,并不表明网站立场。