RAC更适合跑OLTP还是OLAP？

root_dba

怎么没有回答,我的问题?

anlinew

原帖由 eagle3250 于 2008-11-20 17:11 发表
相对于OLTP,RAC更适合OLAP的,RAC除了高可用性,
还有scareup和speedup;对于OLAP,RAC synchronization的成本要低不少,
因此OLAP可以更好的实现scareup和speedup

书本上自是如此

可实际上OLAP synchronization很难避免，而OLTP却能够通过业务分割较为简单的进行分割从而避免synchronization

jarjar

DW/OLAP的应用，有没有用过Sybase IQ的？

eagle3250

OLAP synchronization应该说是很少的,
很容易scaleup和speedup;
OLTP上的应用再怎么分割也是相对的,
否则跟单机有什么区别?

blue_prince

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




终于跟oracle签下了ula

ula 是什么?

unlimited license agreement

biti_rainy

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



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

extent 不够大？  数据导入的时候大量更新 bitmap吧？

battleman

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


extent 不够大？  数据导入的时候大量更新 bitmap吧？

extent是自动分配，intial是65535，blocksize是32k

数据导入之前都自动drop bitmap index，完成过后再create的

[ 本帖最后由 battleman 于 2008-11-20 18:00 编辑 ]

biti_rainy

原帖由 battleman 于 2008-11-20 17:56 发表


extent是自动分配，intial是65535，blocksize是32k

数据导入之前都自动drop bitmap index，完成过后再create的

64k的 extent 在olap应用中那肯定问题比较严重了
bitmap是数据文件头的  extent map信息啊，extent 的分配就要更新 bitmap信息导致竞争激烈（多进程同时工作时候）

blue_prince

原帖由 battleman 于 2008-11-20 17:56 发表


extent是自动分配，intial是65535，blocksize是32k

数据导入之前都自动drop bitmap index，完成过后再create的

应该是ASSM的表空间吧，如果大数据量的话确实有可能有问题，建议改成UNIFORM SIZE，每个EXTENT 4MB或者8MB以上

eof007

为啥不测一下oracle exadata,
1T数据，3秒扫完。

测一下是否真的3秒扫完啊。