高可用 vs 公司

anycall2010

原帖由 blue_prince 于 2008-12-13 23:46 发表


其实上面链接中的那个帖子我已经透露了足够多的信息了，呵呵。有啥兴趣的可以在帖子里面问，方便回答的我都可以回答。

老哥，什么时候也向PINER一样，出本书。让我们拜读一下。

[ 本帖最后由 anycall2010 于 2008-12-14 19:57 编辑 ]

tiegang_zhang

http://www.itpub.net/thread-1088711-2-2.html，这个帖子我也看不了

blue_prince

原帖由 anycall2010 于 2008-12-14 19:52 发表



http://www.itpub.net/thread-1088711-2-2.html
这个帖子权限太高，看不到啊？？

没什么的,就说RAC适合啥应用然后就有管理版那个帖了.

wolfop

amazon跑DSS，对高可用的需求没有OLTP强烈。

owlstudio

银行讲求稳定，创新不够，新技术还是在创新型公司捣鼓的多一些

owlstudio

电信也是，都是会用比较成熟的解决方案的

不过现在RAC成功的案例也比较多，但是我感觉创新的尝试比较少

wuxunhym

一些互联网公司，对新技术能够带来的实惠还是很乐意去尝试。
而传统一些的公司，这种实力还是不能和新兴的这些创新积极性高的公司相比。而且，技术部门在公司中的重要程度没有那么高。

记得前几年的最佳CIO评比中，只要实施过ERP系统的都能上榜。后来的评比就偏重的创新这个方向，香港赛马会的CIO（名字忘记了）的一段采访：他们投入设计出的系统，让下注变得更快更加简洁，效果很好。

zhang41082

他会告诉你如果是非常繁忙的OLTP系统，那不要用RAC。

理由列举了N条，不过印象最深的是RAC下的锁管理机制，这个问题我们也经常碰到

原帖由 shahand 于 2008-12-13 16:36 发表
amazon的关于RAC反馈会让你大吃一惊。

zhang41082

suggest move away from RAC for OLTP database, remove one big central database, function split to many small databases, Amazon got 100+ databases.

- Cluster ware down, database down
- one instance hang, database hang
- painful global lock control
- Lot’s of issues with RAC
# Add database file make RAC database hang (happened in Amazon)
# enq-US (undo segment management) cause slow Global cache/message transfer

youngcow

现在电信运营商的rac一堆一堆的，不过很多都是9i的，10g倒是好像不多