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

hooman

最初由 zjxs 发布
[B]用到sequence了吗？

statspack有专门一部分是rac相关的统计信息的 [/B]

用到Sequence 了, 后来把SEQUENCE 的CACHE 调到10000 了.

eygle

扩容可以分为两个方面的，横向以及纵向的。

横向的可以通过软件扩容来实现，纵向的可以考虑硬件扩容。
年前我们的一个方案最后就选用了硬件扩容，把原来的12 SUN  UltraSPARC III的CPU换成12 SUN UltraSPARC IV 的CPU，通过硬件能力的提升来满足业务增长的需要。

hooman

最初由 eygle 发布
[B]扩容可以分为两个方面的，横向以及纵向的。

横向的可以通过软件扩容来实现，纵向的可以考虑硬件扩容。
年前我们的一个方案最后就选用了硬件扩容，把原来的12 SUN  UltraSPARC III的CPU换成12 SUN UltraSPARC IV 的CPU，通过硬件能力的提升来满足业务增长的需要。 [/B]

如果RAC 不行, 那就只有这招了.

biti_rainy

最初由 herycom 发布
[B]rac应该都要用到至少2个光纤通道吧？
供参考。   
[/B]

一般来说阵列都会是双通道，所以不论是否是RAC，阵列基本都会考虑双通道的。

即使使用rac，只使用一个通道也是可以的。 rac +  双通道 ，如果不做负载均衡，使用主备模式也是可能的，这样就只有一个通道被使用。

zjxs

最初由 hooman 发布
[B]

用到Sequence 了, 后来把SEQUENCE 的CACHE 调到10000 了. [/B]

如果用sequence产生的值作为主键并持续插入数据，可能在index会产生访问冲突，在rac中会更明显的。如果有statspack，上传一份大家分析一下，前面各位DX已经讲了很多理论了。

hooman

最初由 zjxs 发布
[B]

如果用sequence产生的值作为主键并持续插入数据，可能在index会产生访问冲突，在rac中会更明显的。如果有statspack，上传一份大家分析一下，前面各位DX已经讲了很多理论了。 [/B]

没错, 正是在INDEX 发现了大量的冲突, 目前还不知道是不是根本原因, 咋解决呢.

附件是STATSPACK.

hooman

最初由 biti_rainy 发布
[B]

其实rac，在数据库本身的设置方面除了 interconnect 方面的网络问题外，已经没有太多的可以控制的东西。能分应用最好。 [/B]

谢谢, 如果不分应用而想达到目标的话, 我以为最可能的突破口就在表及索引的设计与调整上了.

不知Biti_rainny 常弄的RAC 环境是咋用的?有没有试过VERITAS 4.0 下的 RAC 呢?

biti_rainy

最初由 hooman 发布
[B]

没错, 正是在INDEX 发现了大量的冲突, 目前还不知道是不是根本原因, 咋解决呢.

附件是STATSPACK. [/B]

如果应用不能分割可能造成这样的情况,其中一种解决办法就是 使用 反向索引， 另外一种办法使用2k block 的表空间恐怕不大合适

hooman

最初由 biti_rainy 发布
[B]

如果应用不能分割可能造成这样的情况,其中一种解决办法就是 使用 反向索引， 另外一种办法使用2k block 的表空间恐怕不大合适 [/B]

试过反向索引和HASH 分区.
但让人困惑的是, 使用反向索引会导致测试结果大幅度波动. 从300-1000/秒的结果都出现过. 百思不得其解.

biti_rainy

最初由 hooman 发布
[B]

试过反向索引和HASH 分区.
但让人困惑的是, 使用反向索引会导致测试结果大幅度波动. 从300-1000/秒的结果都出现过. 百思不得其解. [/B]

hash 分区没有意义的啊，你打散的是 表数据，但是没有解决 索引block


要么，使用 hash + 反向索引

同时打散  索引和表数据看看？