[Q]问有RAC 实施经验的大虾:不进行应用分布, RAC性能可以超过HA吗?

hooman · 发表于 2005-3-3 20:34

可以计算出来, 32个分区, 8个线程时. 冲突的概率高达 60%.

理论上, 如果索引不进行反序, 其值采用sequence 顺序增加的话. 索引的BLOCK 会有同样的冲突概率.

因为没个索引块可以容纳更多行, 索引上甚至会产生2个以上的SESSION 冲突的可能. 这个概率如何计算, 我还没有仔细想过.

理论上, 反序索引会避免INSERT 导致更新同一块索引. 但是否完全随机分开, 就像下面的公式这样呢? 我测的结果不是这样, 但还没有分析出原因.

hooman · 发表于 2005-3-3 20:41

实际上, 测试时并没有发现太多表上的数据块有冲突. 主要是索引上的.

我想可能是因为各个SESSION 写操作的时间错开, 进一步降低了冲突的概率. 而索引上因为同一BLOCK 有太多行的数据, 而冲突依然?

hooman · 发表于 2005-3-3 20:55

所有上面这些情况, 都是有办法进一步调整表及索引结构并最终减少冲突的.

假如我们的应用的压力是随机分布在所有节点上的. 那么这种情况似乎没有办法避免:
INSTANCE 1 对BLOCK1 进行了写操作之后, 下一次对这一BLOCK 进行写操作的INSTANCE 还落在 INSTANCE 1 上的概率为

1/n

N 是RAC 的节点数.

也就是说有>=50% 的可能性, ORACLE 会通过CACHE FUSHION 的机制将这一个BLOCK 从一个INSTANCE 搬到另外一边.

除非:
1) ORACLE CACHE FUSHION 的速度很快.
2) 我们有办法让应用不是随机的写BLOCK , 而是让他往INSTANCE 相关的地方写.

我们就根本不能指望RAC 的吞吐量能超过HA.
然而,关于1) 对于ORACLE 9i 来说, 我们应该对其CACHE FUSHION 的速度报多大的信心呢?
关于2) 谁能帮忙出出主意?

大家看看我这么分析对不对, 是不是歪掰呐

shimu · 发表于 2005-3-8 09:49

大家的CACHE FUSHION 的通讯链路是怎么连接的，100M,1000M?

wing hong · 发表于 2005-3-8 11:18

最初由 hooman 发布
[B].
2) 我们有办法让应用不是随机的写BLOCK , 而是让他往INSTANCE 相关的地方写.
[/B]

Is it OK for your applicaton to support partition by key that has instance ID and/or instance Name info ?

Yong Huang · 发表于 2005-3-8 12:51

最初由 hooman 发布
[B]...
2) 我们有办法让应用不是随机的写BLOCK , 而是让他往INSTANCE 相关的地方写.
...
[/B]

I thought about freelist groups. Then I checked 9i and 10g Admin guide. Both say

In a Real Application Clusters environment, automatic segment-space management allows for a dynamic affinity of space to instances, thus avoiding the hard partitioning of space inherent with using free list groups.

So I guess if you use ASSM for your tablespaces, insert should not completely be random on the instances you have. I'm not sure how to verify. Maybe create a trigger fired on insert.

Yong Huang