甲骨文演示Oracle 10g的128节点群集

jiangzx · 发表于 2005-10-26 09:40

呵呵,在制造行业,我倒知道有蛮多的人在用RAC,但实际上并没有把RAC应有的功能完全发挥,电信行业也有一些,但大多都是2节点的,金融行业好象用RAC的很少,大家都比较愿意用HA.

mugen · 发表于 2005-10-26 11:48

在oracle的技术上,oracle没有说支持节点数的限制.但是os总有限制把?另外,节点越多,
管理维护就越麻烦,性能一定就好吗?

wzy25 · 发表于 2005-10-26 23:17

节点数多了，对程序的要求就更高了，有那么多精力去做这个，还不如128个单独的oracle来跑呢。

overmars · 发表于 2005-10-27 15:00

这种就是抄作新闻，现实很少使用的，想象要多少钱呀！

chj733 · 发表于 2005-10-27 17:31

我晕,128个节点,多大个机房装的下?上海的房价很贵的,
128个机器,多大的辐射啊,站在里面没几天估计就病悄悄,哈哈哈

cyr1974 · 发表于 2005-10-28 11:32

估计oracle把节点内部分成不同虚拟组，要不内存通道再快也会受到并发数的影响啊

tolywang · 发表于 2005-10-29 11:57

128 个节点不算什么，那得看看它应用。并发多了。

对 share_disk 的结构可能没得搞。 db2 , sql server 一直在抨击oracle的 share_disk rac . 已达到推广他们的share nothing 的目的。

kinnix · 发表于 2005-11-18 09:12

db2用的数据库分区，SQL server用的啥？

Yong Huang · 发表于 2005-11-20 12:04

One problem with too many nodes / instances in RAC is indirectly related to the setting of MAX_COMMIT_PROPAGATION_DELAY. Contrary to Oracle's belief, many applications do require this parameter to be set to 0 to avoid read inconsistency in the application. (By this, I mean when you commit and immediately read the result, you sometimes see a result as if the previous commit was not done. I don't mean any data corruption inside the database.)

This problem is more common than Oracle thought and the only solution is setting that parameter to 0, in spite of Oracle's warning. Why is this related to number of instances of RAC? Because if you have only two instances, setting this parameter to 0 causes no or very little performance overhead. But with more instances, God forbid 128, setting it to 0 causes a very noticeable delay on each commit, no matter how fast cross-instance communication is.

Yong Huang

yue_01 · 发表于 2005-11-22 16:46

我装过6个节点的10g在REDHAT上，并且真正的上线系统是10个节点的！但是我比较遗憾的是没有深入研究过撤销节点和增加新的节点，学习中。。。，如果那位高人有这方面的经历请指点一二