RAC中的global cache cr request等待事件 过长

cc59

你作oradebug出来后就看到了.很快,一分钟的事.

foxmile

我所维护的生产系统里面也有这个等待时间，但不是很严重，不知道有没有这个等待事件的完整的解释。

rollingpig

很简单的问题。

1。 100MB的心跳决定实例间通讯速度很受影响。

2。Full table scan , 再加上程序没有考虑应用分离（猜测），造成需要实例间传递大量数据。

在以上两个事实的影响下，global cache cr request 多且影响性能就属情理之中了。

同理，针对以上两个问题，有两个解决方法：
1。 改千兆光纤通道
2。避免FTS
3。程序可能的话应该应用分实例

biti_rainy

两个可能因素造成
1： 节点之间interconnect 通讯 的 global CR
2： 本节点索引访问造成block cache离散，增加了io量

这样一个fts 导致io增加和global cr ，可能会造成情况恶化。

BTW: 即使单节点数据库，原因2 也可能导致fts 很慢，data buffer偏大可能造成情况更糟糕，因为io 大大增加。

Yong Huang

It makes me think of the parameter _serial_direct_read (enable direct read in serial). Once you set it, all db file scans that cause db file scattered read wait, such as FTS or index fast full scan, will bypass buffer cache, and the wait event changes to direct path read. You want to avoid polluting buffer cache by FTS. Right? That's the parameter you can try. Even alter session works.

Yong Huang

cyr1974

同意 rollingpig的观点

oraclinux

有时候应用层分的很开的话 就可以弄两个db 然后link一下了

呵呵  所以rac带来了方便,也带来了副作用

stacyruirui

1)
net.core.rmem_default = 262144
net.core.wmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_max = 262144

depend on your db_block_size and db_file_multiblock_read_count
if db_block_size=8k and db_file_multiblock_read_count=16, increase them to 512K

2) select DATA_REQUESTS,FAIRNESS_DOWN_CONVERTS from  v$cr_block_server;

If the ratio of down-converts to CR, reducing _fairness_threshold

stacyruirui

Can you try to use parallel query for the sql to full table scan?

Yong Huang

原帖由 stacyruirui 于 2008-1-7 06:54 发表
...
2) select DATA_REQUESTS,FAIRNESS_DOWN_CONVERTS from  v$cr_block_server;

If the ratio of down-converts to CR, reducing _fairness_threshold

Your last sentence seems incomplete. If the ratio is What, should we reduce _fairness_threshold?

Yong Huang