RAC更适合跑OLTP还是OLAP？

anlinew

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


OLAP？也不至于差这么多吧，不过确实也需要调整应用，当初我们从单机到RAC时调整了一堆的SQL，然后还要把SQL给优化好，这个不是简单的工作。刚开始上RAC时也是经历过很多痛苦的。
调整主要是一个个来进行调整，总会调整好的。

OLAP及OLTP混杂，大范围数据库块访问是难免的
SQL优化，我们这里至少可以说还是走在行业前列的，看得到的基本上是会处理掉的，至少测试环境上能搞定
我们的系统至少白天并行是严格禁止滴

[ 本帖最后由 anlinew 于 2008-11-20 16:58 编辑 ]

novenbersky

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


OLAP？也不至于差这么多吧，不过确实也需要调整应用，当初我们从单机到RAC时调整了一堆的SQL，然后还要把SQL给优化好，这个不是简单的工作。刚开始上RAC时也是经历过很多痛苦的。
调整主要是一个个来进行调整，总会调整好的。

转RAC为何要调整SQL？能否介绍一下？

battleman

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


ASM其实提供了类似于祼设备的性能，相对文件系统来说也就是少了文件系统缓存和文件系统管理开销这一层。
ASM实际测试和运行中，底层的硬盘IO分布非常均衡，能够充分把磁盘利用起来，而且比祼设备管理方便多了。
总体来说ASM还是非常不错的，这个也是ORACLE以后数据文件存储的方向，我比较赞成使用ASM。

现在单节点的OLAP，大量的等待都在file header block 上，ASM过后应该会好一些吧。。

blue_prince

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



转RAC为何要调整SQL？能否介绍一下？

其实也不是的，原来单机上的SQL由于机器资源的限制只能不并行运行，转到RAC后为了发挥RAC的威力，就需要转成并行处理，并行又需要很多的考虑和权衡，是否并行？并行度为多少？是否跨节点并行？稳定性如何？呵呵，并行也是很容易触发BUG的一个点，并行也碰到过非常多的BUG。

wzy25

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


ASM是黑盒子，出现单块ASM盘损坏就需要重建整个DISK GROUP，这个非常被动。假如你ASM盘没有冗余的话。其实OLTP上也是可以上的，采用STANDBY，当然STANDBY要能够接管，这样ASM假如宕掉的话，STANDBY也能够接管过来。
实际使用过程中，ASM的管理便利性、性能确实是很不错的，但是也出过问题，弄得非常被动，幸好最终把问题解决了。

ASM毕竟出来的时间还短，需要时间来完善吗。。。。
这个是趋势吗，没办法。。。。。。性能确实好。。。

blue_prince

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



现在单节点的OLAP，大量的等待都在file header block 上，ASM过后应该会好一些吧。。

file header block 上？这个啥意思？是什么等待发生在这上面？
ASM也不一定会有很大性能提升的，只是管理维护便利而已。

anlinew

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



现在单节点的OLAP，大量的等待都在file header block 上，ASM过后应该会好一些吧。。

是OLAP系统？

battleman

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



file header block 上？这个啥意思？是什么等待发生在这上面？
ASM也不一定会有很大性能提升的，只是管理维护便利而已。

是通过v$waitstat查看到的，我怀疑是数据文件集中访问太频繁造成的。
asm可以做到底层均匀io分布，感觉应该会缓解一些吧

battleman

原帖由 anlinew 于 2008-11-20 17:06 发表

是OLAP系统？

是啊

eagle3250

相对于OLTP,RAC更适合OLAP的,RAC除了高可用性,
还有scaleup和speedup;对于OLAP,RAC synchronization的成本要低不少,
因此OLAP可以更好的实现scaleup和speedup

[ 本帖最后由 eagle3250 于 2008-11-20 17:19 编辑 ]