今天与一位ORACLE老兄谈论了一下DB2与ORACLE的差别，在这里发贴，想看看大家的看法

askgyliu

DB2的PARTITION是分TABLE-LEVEL PARTITIONING(V8才有) 跟DB-LEVEL PARTITIONING。后者以前是只有EEE DB2 才有。
ORACLE的PARTITIONING是指TABLE-LEVEL PARTITIONING。RAC倒是跟DB2的DB-LEVEL PARTITIONING比较象。
DB2的DB-LEVEL PARTITIONING从理论上加越多SERVERS会越快，因为彼此是SHARED-NOTHING。ORACLE RAC 多加几个SERVERS就可能会有很多问题了，因为是SHARED DISK。
若干年前看过ORACLE的WHITE PAPER，其中一段在比较ORACLE和DB2(V7)的PARTITIONING，笑死了。两者根本就不是同一回事。

rheet1978

对“select不会被锁”，在DB2中，只要打开把DB2_SKIPINSERTED 设置成ON即可，默认是OFF

rheet1978

undo tablespace,DB2对应的是log的方式，效果一样

junsansi

看到这类对比，俺总是想到之前编程区对于c#好还是java好的讨论，总之各说各的理谁也说服不了谁~~~

askgyliu

我上面的话有点错误。TABLE PARTITIONING 是 V9 才有的。MY APOLOGY.

beebear

感受最深还是大批量并发场景锁的问题上，db2 锁机制对应用设计要求更严格，产生的锁等待超时、死锁几率远远高于Oracle。其次就是db2 的数据压缩技术很有特色，大量节省存储且能保持很好的性能，这点远远好于Oracle。
总的来说，除非非常特别的应用场景，通常oracle、db2结合自身特性进行适应性调整、优化，都能满足要求。

macrozeng

最初由 rheet1978 发布
[B]undo tablespace,DB2对应的是log的方式，效果一样 [/B]

Oracle 中的日志有前滚和回滚之分， db2 中的 logs 又可以作为 Rollback 又可以用于 Roll Forward ?
正是因为 db2 没有专门的 undo tablespace ，所以它就无法实现 Oracle 的 Read committed 的隔离级别。
请各位发表高见，见
http://www.itpub.net/793123,3.html

askgyliu

一个简单的想法，如果DB2没法ROLLBACK UNCOMMITTED TRANSACTIONS 跟 ROLL FORWARD COMMITTED TRANSACTIONS的话，那DB2怎么做RESTORE AND RECOVERY？

ORACLE用UNDO跟REDO LOGS来保护数据库，而DB2用LOG FILES来保护数据库。没所谓ROLLBACK LOG FILE或ROLL FORWARD LOG FILE。

还要注意的是，ORACLE和DB2都用WRITE-AHEAD-LOGGING来提升PERFORMANCE。就是说一个TRANSACTION，不管有没有COMMITTED，它的资料其实都被LOGGED在LOG FILE了。只是在RECOVERY时有没有RE-APPLY而已。

UNCOMMITTED READ本身就是DIRTY READ来着。ORACLE和DB2各有千秋吧。

想象一下银行的TRANSACTION系统。若是一个户头同时有两个TRANSACTIONS的话，ORACLE就得用某种方法来SERIALIZE这两个TRANSACTIONS了。而DB2 BY DEFAULT就会SERIALIZE这种TRANSACTION。

而任何一种数据库，只要是COMMITTED，再来读，肯定不能算是DIRTY READ了。不然的话，数据库的INTEGRITY怎样保证？

jacky_liu_cn

最初由 macrozeng 发布
[B]

Oracle 中的日志有前滚和回滚之分， db2 中的 logs 又可以作为 Rollback 又可以用于 Roll Forward ?
正是因为 db2 没有专门的 undo tablespace ，所以它就无法实现 Oracle 的 Read committed 的隔离级别。
请各位发表高见，见
http://www.itpub.net/793123,3.html [/B]

DB2在CS级别下不可以实现Read Committed吗？

mdkii

难得有人提到了IQ，
我用IQ差不多也有3年多了，简单说一下对IQ的看法。
总的来说，
1、IQ只适合用于OLAP的场景，不适合OLTP场景，尤其对于并发更新的支持尤其的差，
因为sybase与ibm和oracle策略不同，他的oltp和olap分开两个产品线，ase一个（OLTP），
iq一个（OLAP)，所以当存在olap和oltp混合压力时ase+IQ是一个做法，
但是个人感觉两者结合并不是太好，
iq的前端引擎是用的ASA，语法与ase的语法还有些不一致，
两者的数据通道除了互建proxy table外也没什么特别好的办法 。所以，
如果是这类应用，不建议用IQ，而应该选择db2或oracle。
2、其实相比较而言，IQ的性价比不错，它可以在比较低配置的机器上，在数据量比较大
的情况下，跑出比较好的效率。我们这里IQ最大的表已经超过100亿，在8cpu 32G内存的
机器上做一些查询，响应时间依然得到很好的保证。
3、IQ有比较强大的索引机制，比如常用的LF，HG，HNG等索引，bit-wise只是其中一种索引
技术，LF就是bit-wise索引，HG则用的是G-ARRRY的存储方式。这些索引在做条件检索，
group by时都可以很好的提高效率。
4、IQ稳定性存在问题，早期的版本比如12.6，有时会莫名其妙的down机。主要是因为前端
的ASA引擎比较脆弱。原来ASA就是个桌面数据库，所以要支撑商业应用可能有点困难。
最近的主流版本已经到12.7 ESD8了，打上ESD8后，IQ的稳定性大大增强了。但仍不建议
在关键的7*24小时的系统中使用IQ。
5、IQ产品成熟度与db2 oracle还是差很多，毕竟是新出来的产品，在一些兼容性问题上可能
没有很好的解决。另外，还有IQ的资料很少，用的人少，当出现问题时，除了
找sybase 工程师和自己摸索之外，没有什么办法。这一点远不如db2和oracle。
6、IQ load是一大特性，尤其是多线程load，速度达到10万/秒是没问题的。
7、IQ的数据压缩显然是一个不错的功能，压缩比达到一般能达到1/3左右，在
充分节省空间的同时，还大大减小了IO。这也是下面要说的multiplex得以实现的基础。
8、IQ有一个号称是multiplex的架构，有点类似于oracle的rac，不过它只能
有一个write server，其他只能是query server（只能读不能写），最新版本
好像支持多个write server了。它的读一致性
通过other version来实现，有点类似于oracle的回滚段。不过，它的other version占用的
是主数据库空间，由于某些原因如果节点间没有及时通讯，
会发生由于other version过大把数据库空间撑满的的情况，这一点很恶心，我已经深受其害。
所以multipex可以酌情使用，如果要用一定要用，补丁一定要达到12。7 ESD8以上。

所以IQ做数据集市还是相当不错的，这些集市数据量大，访问并发度低，基本是只读访问。而且
对稳定性要求没有那些实时系统高。iq充分发挥数据压缩，节省空间，对机器和磁盘要求比较低的优势。


如果要做企业级数据仓库，个人推荐还是用teradata。
要说海量数据的处理能力teradata绝对是首屈一指的。
我们做过实验，在16个节点的情况下，对一张40亿左右的表做10个维度的group by，
结果集为8千多万条记录，插入一张结果空表中，大概需要20分钟左右。
多表join的效率也是很高，一些批处理里经常10多个表join，依然跑得飞快。
teradata的一个工作单位叫做AMP，当数据分布均匀时，16个AMP一起工作的效率是惊人的。
teradata类似于db2，也是share nothing架构，不过它的强大bynet好像比db2之间的分区间
通讯效率高很多。
teradata的稳定性也可以，备份机制也很成熟。
最重要的是它有一套成熟的DW方法论和实施团队，这一点远远强于只卖产品的sybase。
不过teradata也有缺点：
1、TD只适合做DW不适合做OLTP应用。
2、TD实施成本非常昂贵，不光机器设备卖的贵，而且他的磁盘空间也很紧张，一般只能到65%
，其余空间只能做为spool空间，供多表join时数据重分布使用。实施团队的费用也不低，
如果不是大企业建议还是不要用TD了。
3、TD很大程度依赖规模效应，如果只有一两个节点，还不如不用，一旦形成
规模比如16个，其效率估计其他数据库都比不上了。


所以，我们这边的策略是，OLTP用db2，部门集市用IQ，EDW用teradata。
一些OLTP+OLAP的应用就用 db2+IQ的方式，夜间批量通过文件做数据交互。

希望我的回答对楼主有所帮助。