RAC更适合跑OLTP还是OLAP？

battleman

很有借鉴价值，目前公司正打算把OLAP迁移到RAC＋ASM，不过感觉ASM对OLAP来说好处更大

anlinew

原帖由 battleman 于 2008-11-20 16:05 发表
很有借鉴价值，目前公司正打算把OLAP迁移到RAC＋ASM，不过感觉ASM对OLAP来说好处更大

如果是我，目前OLAP我绝不选择RAC

blue_prince

原帖由 anlinew 于 2008-11-20 16:13 发表

如果是我，目前OLAP我绝不选择RAC

这个要根据自己的需要而定。适合自己的才是最好的。

blue_prince

原帖由 battleman 于 2008-11-20 16:05 发表
很有借鉴价值，目前公司正打算把OLAP迁移到RAC＋ASM，不过感觉ASM对OLAP来说好处更大

呵呵，ASM无非就是管理维护上的便利上而已，无所谓在OLAP或者OLTP上的优势。

anlinew

原帖由 blue_prince 于 2008-11-20 16:16 发表


这个要根据自己的需要而定。适合自己的才是最好的。

是否适合要试过才知道，而试一下付出的成本太大
在硬件（设备，软件）、软件（DBA，知识储备）环境不足以支持的情况下不如选择更成熟的方案

blue_prince

原帖由 anlinew 于 2008-11-20 16:21 发表

是否适合要试过才知道，而试一下付出的成本太大
在硬件（设备，软件）、软件（DBA，知识储备）环境不足以支持的情况下不如选择更成熟的方案

如果现有系统跑得好好的，当然就不用操心了。
但是假如现有系统已经出现了性能瓶颈，这时候你需要重新规划选型，而且也具备条件进行测试，这步就可以做了。我们做任何事情都是在有明确目的的前提下去做的。

root_dba

试也并不是所有的公司都可试的.
有时并不是技术问题,个人认为技术问题都好解决,
取得上层的同意也是很困难的. 还有风险什么的.

root_dba

原帖由 biti_rainy 于 2008-11-20 13:52 发表


ebay在 f5 分析url规则来转发 ＋ shareplex 同步  是成功的，但这个也要再架构层面布局做好基础，现有的比较复杂的系统要去改造成本还是蛮大的。就我们现在的情况而言，如果要在 rac 的intance之间分割应用，其实不困难的，因为只要分割主要的压力大但关联少的应用就可以了。但没下这个决定的原因也是多方面的，毕竟比如 4c core 的 pc，4个节点，那么license数量就是 4*4/2*4*1.75=56个。这样的软件成本其实也蛮高的了。 而如果是 p590，16c的 590的license是  16*0.75*1.25=15，那么license数量差异是 41个（费用上有多少大家心里就有数了）。 而基本上以前我们会认为4个pc server的rac 不会强于一台 16c的 590 的 oltp能力。 一台 16c的 590 的价格大约在 280万左右。 所以以前在 oltp上采用了 ibm小型机这样的策略，毕竟风险也低一些。

但是未来 p590 满足不了需要，必须要分割，既然分割，那么就没必要依赖小型机了。

biti,对于ebay的 f5+shareplex方案能不能再详细说明一下

root_dba

原帖由 biti_rainy 于 2008-11-20 11:32 发表


和架构、业务一起去解决问题，而不是在数据库内部解决问题
mysql的问题不在数据库比oracle好，而在 软件费用的问题

我们经历了快一年时间终于跟oracle签下了ula，2008年11月25日生效，oracle无限制使用3年！ 但这只是给我们留了3年时间来解决 数据库的分拆和转移，而不是现在我们就放任自流。
pc server的性能发展和成本下降非常快，ssd的可能使用也非常值得期待，但是oracle要架在pc server上带来巨大的 license费用，我们必须在3年内解决这个问题。

终于跟oracle签下了ula

ula 是什么?

battleman

原帖由 blue_prince 于 2008-11-20 16:17 发表


呵呵，ASM无非就是管理维护上的便利上而已，无所谓在OLAP或者OLTP上的优势。

是啊，不过总感觉ASM不是很成熟，OLTP不敢轻易上啊