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

bulkaunt

standby数据库是单机rac，只开启了一个实例，数据库用的是Hp服务器自带的磁盘；

这个和我说的有什么关系呢？？你在STANDBY上执行的，和在RAC上执行的机制很大不同，虽然是同样的全表扫描，但是在RAC上还得进行LOCAL CACHE－－GLOBE CACHE 寻找等等

另外，如果是EMC磁盘速度存在问题的话，那就不会只是你进行全表扫描才会出现慢的情况了。

zhu47172310

如果EMC磁盘速度存在问题，我觉得其他的地方表现得不会很明显，只有全表扫描这种磁盘操作多的才比较明显。上面提到的现象，我认为虽然standby的单实例还得进行LOCAL CACHE－－GLOBE CACHE ，但是很明显不需要从其他实例上传cashe数据过来，因为这时没有其他的实例。而rac上的两个实例就有可能从另一个实例上找到自己实例上没有cashe数据，通过心跳线传过来。如果心跳线网速很慢，就可能会出现我上面提的现象。

这只是我的猜测。
你有msn的话。留一个给我。我的MSN是zhu_0922@yahoo.com.cn。
有想讨论RAC的朋友可以直接联系我，大家共同进步。

solaris8

为什么一定让他走全表扫描呢?

是不是全表扫描的执行计划最快?

zhu47172310

其实多数情况下是不全表扫描。但极少的时候还是会有全表扫描的。不用讨论是否要全表扫描。你可以认为是一定要进行，关键是如何提高这个速度。

zhu47172310

今天碰到有人来msn向我问这个问题的解决方法。我的答案是未找到有解决办法。从当时提这个问题到现在，已经过了几个月了。自己的RAC早已上了线，现在我的临时办法是监控数据库中运行的sql，如果有全表扫描的操作，尽可能想办法避免它。我觉得产生该等待的主要原因可能是两台机器间的数据缓存要通过心跳线同步，而等待网络传输引起的；一个可能的解决办法是把心跳线换成光纤来传输网络数据。

aqiangcheng

心跳线一般都用光纤的

cc59

再一个,您需要确定您的通信是否走的心跳.

如果走的公网.一样会造样这样的问题.

cluster ware用的是啥?

cc59

你可以作一个dump ipc来观察一下.

jerryma6002

1  first , you should confirm weather your ipc channel is on the inter-connect as  the up-stairs brother said.
2  second,  maybe you should consider the  RAC GUARD deploymnet to reduce cache fusion cost. that means application partition.  but as we known,  there is seldom the 9i RAC GUARD deploymnet  in domestic  producing enviroment. so you need  think it carefully.

zhu47172310

不好意思，dump ipc我不会。本人人比较懒，目前系统正常在用，不想在搞什么事，没有深入研究，就撮合着用吧。