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

hooman

这张图描述了我们应用的架构

zjxs

和测试程序的编写也很有关系的，比如交易随机值的选取，我以前用两个模拟程序做测试，性能狂差，后来发现是取随机值时的种子是一样的，导致每个instance几乎总是同时访问相同的块，性能当然就差了。

即使不做应用分区，如果数据量很大，每个instance同时访问相同块的几率比较还是比较小的，性能应该有所提升的。

eygle

元宵节快乐，明天再研究吧

zjxs

用到sequence了吗？

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

biti_rainy

总的来说，如果 数据在 两个 instance 之间传输的量比较大一点，则影响是很严重的，尤其是涉及到 lock 的

我个人的理解：

rac 的主要作用，可以承担更多的并发，或者说支持更多的连接数量，减少单个机器上的进程数量，尤其linux上，进程数量太多带来的影响不是线性的而是影响非常大。
rac作为节点容灾难，当然如果是两个节点，谈容灾通常是不合适的，在一个节点crash的之后另一个接点恢复、负担更多的连接，在这个时候很容易出现问题一起，无法提供服务。在我们的系统中遭遇过2次大约会中断3--5分钟的服务（还没有failover）。


尤其在两个节点的应用中都频繁访问某些比较集中存储的数据的时候影响比较大

我听过的好多例子中rac/ops  的处理速度都比不上单机。在我的理解中，oracle对于全局资源的管理上，不是那么让人满意。

另，oracle访问数据的时候恐怕还不仅仅是按照block这么来考量的，由于block存在于sga中会割裂原本可以连续的一个io成为多个io，增加入rac，实际情况更复杂。如果再考虑 dml 在里面，对性能的影响，是难以简单地阐述的，只能通过测试来判断。

BTW: 我们新的架构将放弃RAC使用HA   

hooman

我就是在怀疑在这种CASE下, RAC 到底行不行

谢谢各位, 祝元宵快乐!
明天接着研究!!!

我真想在将来的架构中把ORACLE 拿掉, 或者干脆数据库也拿掉. 嘿嘿...

herycom

对rac，磁盘阵列具有负载均衡软件将大大提高io性能。
对rac，需要有特别的参数设置，特别是关于网络方面的参数。
目前数据库性能感觉满意，不过我们购买了oracle的服务。
具体情况我们这的数据库管理员比较清楚。
我们这不同的机器放置不同的应用，要用好rac，不但参数要调整好，而且应用也要设计好。

biti_rainy

最初由 herycom 发布
[B]对rac，磁盘阵列具有负载均衡软件将大大提高io性能。
对rac，需要有特别的参数设置，特别是关于网络方面的参数。
[/B]

负载均衡的问题，我估计是有2个 光纤通道(or 2块hba卡)，配合相关的厂商的负载均衡（一般同时具有故障检测和接管功能），这样双通道提高了io能力。 但是这个问题和rac 并没有什么联系。


所谓网络方面的特别的参数设置，基本就是指 发送和接受网络包的buffer，比如linux下就是
Linux (edit files)        
/proc/sys/net/core/rmem_default         
/proc/sys/net/core/rmem_max
/proc/sys/net/core/wmem_default        
/proc/sys/net/core/wmem_max  

其他os相应的也有
参考 metalink
http://metalink.oracle.com/metal ... T&p_id=181489.1


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

herycom

biti_rainy不愧为论坛第一大侠，什么都懂。
不过我也不知道具体是不是你提到的这些参数，oracle专家调的，这方面我只知道大概情况。还有需要将网间通讯的内存设置为禁止交换出去。
我们用了autopath后对整个数据库的io性能有很大提高。
rac应该都要用到至少2个光纤通道吧？
供参考。   
（我终于在1万名以内了，争取到1000名内）

feng_xin

最初由 hooman 发布
[B]

2) 同样的硬件环境, 改成RAC, 重复上面的测试. 数据库连接采用LOADBALANCE 方式. 同样可以得到一个交易速度的最大值. 和上面的结果相比较, 结论让人失望. ( 这时, 从Statspack 的报告中, TOP 5 event 中, Global Cache 相关的占据前两名甚至前三名)

? [/B]

不论是RAC还是OPS，它们的机制都是磁盘共享，所以决定了Global Cache的维护是系统的最大瓶径。与OPS比起来，RAC这个方面做了很多改进，减少了PING的操作，但是我认为从实质上来说，在没有改变磁盘共享这个机制的前提下，Global Cache的维护仍然是RAC的致命弱点。在多个节点共同访问同一张表，同一个BLOCK时，特别是一个节点修改，多个节点读取时，性能问题尤为严重，出现TOP 5的event都跟Global Cache相关是很正常的。

若是两个不同的应用，分别访问不同的表，比如，一个是财务系统，一个是人事系统，这种情况下，使用RAC是比较好的选择。