Global Cache Miss

最近数据库集群通过spotlight监控经常报一些警告：
global cache 总是有Miss的情况
Alarm raised 80.98 milliseconds latency across the interconnect. Average : 27.19 ms (averaged over 30 seconds)HighCluster latency (Interconnect Latency)

通过查找官方文档，发现如下：
确保 UDP 缓冲区大小合适
适用平台： Windows 除外的所有平台

原因： 私网可以说是 RAC 数据库的命脉。但是，如果未向 UDP 分配合适的缓冲空间用以发送和接收缓冲，则私网的性能将大幅降低。这将会导致您的集群出现稳定性问题。

更多信息：有关正确调整 UDP 缓冲区的更多信息，请参考以下文档：
Document 181489.1 Tuning Inter-Instance Performance in RAC and OPS
Document 563566.1 gc lost blocks diagnostics

注意： Windows 集群对 Cache fusion 通信使用 TCP，因此，UDP 缓冲区设置不适用于 Windows。

概要：
在oracle rac环境中，RDBMS收集global cache的工作负载情况，这个情况会在STATSPACK、AWR、GRID CONTROL中被报告。集群中每个节点的全局内存块丢失状态（gc cr block lost" and/or "gc current block lost")都代表着网络中包交互的问题。这样的状态都应该被监控以及评估一确保GCS/GES网络效率。任何的块丢失会标明网络包传输中的问题并且应该被研究。
绝大部分的global cache 块丢失都可以被联系到时网络错误配置的原因导致的。文件服务指南可以评估和查询到这行原因。
即使大多数的讨论集中于性能问题上，它也可能导致一个节点被逐出。oracle集群依赖于心跳机制来确认节点资格。如果网络心跳经常性的被drop，节点被逐出就会发生。以下状况会导致节点被逐出:

主要："gc cr block lost" / "gc current block lost" in top 5 或者重大的等待事件
次要：
SQL traces report multiple gc cr requests / gc current request /
gc cr multiblock requests with long and uniform elapsed times
Poor application performance / throughput
Packet send/receive errors as displayed in ifconfig or vendor supplied utility
Netstat reports errors/retransmits/reassembly failures
Node failures and node integration failures
Abnormal cpu consumption attributed to network processing

注意：块丢失问题经常伴随着gc cr multiblock waits，例如：waits for scans of consecutive blocks

全局块丢失诊断导引：

1、错误或不可靠的线缆/网卡/转换器的配置连接 --这个很好检查，这里不做讨论。
2、不合理的UDP接受缓冲区大小设置/UDP缓存套接字溢出

描述：oracle rac全局内存块的变动通常会是爆发性的，因此，系统需要缓存接受这些包当等待CPU的资源的时候。不可用的缓存区域导致了全局包的丢失。在大多数UNIX系统中 用 'netstat -s' or 'netstat -su'将会得到帮助决定是缓冲区溢出还是内存缓冲接受的错误。

解决办法：包丢失的情况经常是服务器上UDP缓冲设置不充分所引起的。当出现包或块丢失的环境下，可以留心观察到 "global cache cr requests"的等待状况，通常这是由于内存设置不充分引起的。
当设置 DB_FILE_MULTIBLOCK_READ_COUNT 参数超过4的时候，会导致这一问题的出现，为了减轻这个问题带来的影响，通过增加UDP缓冲区和减小 DB_FILE_MULTIBLOCK_READ_COUNT 参数值可以做到。
判断你的UDP套接字缓冲是否溢出和包丢失在UNIX平台上，可执行如下：
‘netstat -s' 或'netstat -su’然后重点查看以下数值是否过大：
udpInOverflowsudpInOverflows
packet receive errors
fragments dropped
outgoing packet drop
注意：UDP包的丢失通常的结果是延时增加，如果netstat -s 中TCP项中"outgoing packets dropped" 增加的明显，增加wmem_default 和 wmem_max 参数值到 4MB可以解决这个问题。UDP的发送和接受缓冲值是依赖于系统的设置的。这些值是可以动态设置的。

net.core.rmem_default 代表socket的接收缓冲区的默认值

可以通过man tcp帮助中查到此参数的详细解释。如果此参数设置过小，将影响到能够接收到的UDP包的大小。

net.core.rmem_max 代表socket的接收缓冲区的最大值
可以通过man tcp帮助中查到此参数的详细解释。如果源代码中设置的值比此值大，这此值为准。

RHEL最初的设置如下：
net.core.rmem_default = 126976
net.core.rmem_max = 131071
推荐使用值：
#net.core.rmem_default = 524288
#net.core.wmem_default = 524288
#net.core.rmem_max = 4194304
#net.core.wmem_max = 4194304

3、低网络性能和高CPU利用率，‘netstat -s’报告包重组失败

状况描述：大UDP数据包可能被重组并依据Medium Transmission Unit（MTU)值发送多帧数据包，这些碎片数据包需要在接受端重组。高CPU利用率、不充分的重组缓冲区和UDP缓冲空间均可导致包的
重组失败。'netstat -s'报告了大量的’ "reassembles failed" 和 "fragments dropped after timeout" 在接受节点的IP状态栏中。
netstat -s 查看IP状态：
3104582 fragments dropped after timeout
34550600 reassemblies required
8961342 packets reassembled ok
3104582 packet reassembles failed

解决办法：增加碎片重组缓冲区，定义更多的重组区域。增加重组碎片的时间，增加UDP接受缓冲区去调节网络延时状况。
增加以下设置调节内存利用率：
IP分片缓冲区参数：
net.ipv4.ipfrag_low_thresh

net.ipv4.ipfrag_high_thresh

用于组装分片的IP数据报的最大内存量，它将直接影响到能够接收到最大的UDP包的大小。因为超过MTU值的包都会被分片，分片的IP包达到目的端后需选缓存起来，等所有包都到达之后再组装。如果缓存不够用，多余的将被丢弃，这会导致组装失败。
redhat linux最初的设置如下：
net.ipv4.ipfrag_low_thresh = 196608
net.ipv4.ipfrag_high_thresh = 262144
该设置能够支持的最大UDP大小约40000字节。

建议修改如下：
net.ipv4.ipfrag_low_thresh = 393216

net.ipv4.ipfrag_high_thresh = 524288

4、Global Cache local miss rate is raised

当本地的全局高速缓存丢失比例超过一定的门槛时候，我们通常需要警惕的是数据库中的热块问题。

当一个block被一个逻辑读的时候，集群中一个实例需要从另外一个实例的不同模式的内存中传输。可能会引起这样的丢失警告。

当一个热块被非常高频率的传输调用时，集群会出现过多的协调活动：

可以解决的办法如下：

1、对经常被调取的表进行分区

2、通过使用服务隔离应用活动