关于oracle＆DB2的比较

zhangfei__

各有所长吧，要是比性能，那oracle还是好一点的，因为用户可以根据数据库的反映来调整一下数据库，但是DB2可以调的地方就很少，所以DB2数据库适合那种数据库一安装好只管用，不用优化的那些客户，但是DB2也有它的优点，它的数据复制功能就要比oracle的方便，特别是Q复制，虽然说要用到MQ，但是它可以复制到大多的主流数据库。但是DB2的分区和数据压缩功能能就不如oracle了。所以，我认为，用数据库主要要看客户的业务模式是什么样的。还有数据库中也不只是有oracle和db2还有sybase，mysql，这两种数据库现在可都是有基于列导向的存储引擎，非常的适合做大型的数据仓库，它的压缩是传统的oracle,db2,sybase,mysql等基于行引擎的数据库拍马都赶不上的，至于压缩有什么好处，我想DBA们都了解吧，可以带来更少的IO和更高的速度。

sqysl

1、db2可调整的地方是比ORACLE少，也不是特别少，尤其是针对大数据量的检索，我不认为比其他数据库差；
2、其他数据库，比如MYSQL，MSSQL，SYBASE在检索性能方面不一定比ORACLE差多少，他们和ORACLE差的是并发修改性能，因为他们采取的锁模型不同，ORACLE相比他们要更乐观，当然MYSQL有些引擎的锁模型沿用了ORACLE锁模型的特点；
3、数据压缩有时会带来好处，但有时也不一定，因为它会消耗大量CPU;
4、最后，行引擎和列引擎我不是很清楚，能否赐教，非常感激，谢谢。

Meets

其实 有些时候 我也经常有这种疑问：
如 一天 客户问道： 我们为什么用oracle 而不用 mysql or sql server db2 之类的， 我们应该如何回答呢

sqysl

其实，目前中国的企业或机构在选择数据库时，很大一部分是比较盲目的，它们并不知道为什么选择ORACLE，很多时候人云亦云，或凭关系公司推荐使用，至于国家企事业单位，就更不说了，比较复杂。
要说清楚这件事情确实比较麻烦，除了了解各种数据库系统的特点，还有很多方面因素需要考虑，比如：机构业务需求，机构经济承受能力，机构维护成本等，如果要搞清楚、用明白，这需要比较周全的考察论证，可多少企业和机构这么做了呢？

Meets

我也是这么想的；

淘宝现在 说： my sql 我们的新方向。
莫非是他们发现 昂贵的oracle 能做的事情 免费的my sql 也能做了吗？ 这对于我们这些oracle 爱好者可不是什么好事

同时 我也感觉到 my sql 的市场正在增大；

ben_zhong

我们公司一般bi这一块一般用的是db2..企业信息化，电信平台一般是oracle..其实，不是海量数据应用的话难以区分那个好。。那个不好。。总比mysql强得多。

原帖由 晶晶小妹 于 2008-11-6 22:05 发表
这就不好说了，就好像刀与剑，哪个更厉害。决定孰优孰劣的不是兵器本身，而是使用兵器的人。
就好像你用飞刀还有可能伤到自己，但小李的飞刀就是天下利器，要是飞刀到了小李他妈手里，那就是......

呵呵，我对DB2不了解，但既然是存放历史数据，DML很少，如果数据量不是十分的巨大的话，这样的数据库管理起来也比较容易，无论DB2还是Oracle，应该都可以胜任的。建议你选个你最想学的，或者选个成本低的。

oracledba

原帖由 sqysl 于 2008-11-8 08:46 发表
不一致也是暂时的不一致，研究一下ORACLE和其他数据库的锁机制就知道了，模型或观念不一样而已，如果其他数据库软件商要效仿ORACLE的锁机制，也不是什么难事情，只是每个软件商都有自己的观点，MYSQL里的INNODB不就是在某些方面，尤其是锁方面效仿了ORACLE的锁机制吗？

暂时的不一致在企业级的应用也是受不了的，您怎么发现的暂时的不一致？

sqysl

1、mysql数据库不可小觑，它虽然很多方面不是很完善或集成的不好，但它无论是在性能还是功能上，还是有很多亮点的，尤其是它的多引擎技术，给了用户很多选择，有的引擎在某些方面的性能快的出奇，它对系统的资源要求也是非常的低，相同硬件条件下，它的性能和功能其他数据库系统是没办法和它比的。
2、ORACLE的这种不一致，可能说得挺吓人，其实并不是ORACLE系统的不完善，而是由它的锁模型决定的，它的锁是读写不阻塞的，当一行数据被加行锁后，其后的读却乐观的认为它没发生改变，其实，加锁的数据行是有两个结果的：commit,rollback，其中一个结果会和查询出来的结果不一致；同时其他数据库的锁模型，要比较悲观些，比如：mssql的锁模型，在一个表上有DML操作事务发生但未提交前，其他事务是不可以进行的，哪怕是读也是，这些后面的事务会被阻塞，因为它认为未提交的DML事务结果未定，所以其后的事务要等这个事务COMMIT或ROLLBACK后，才可以进行其后阻塞的事务，因为数据被修改了，在事务完成前，无法知道被修改的最后结果，但这就导致了并发修改性能的低效。
3、当然，MSSQL2005也出现了多版本功能，虽然不象ORACLE那么完善，但它毕竟给用户一个选择，可以选择读写不阻塞，而写事务结束前，就认为它没发生变化。当然，ORACLE也给了用户一个选择，那就是事务的serializable，那就是事务的串行执行，可ORACLE用户有哪个会用这个事务级别呢？MSSQL2005用户，又有多少用到多版本呢？真所谓有得必有失啊。

oracledba

原帖由 sqysl 于 2008-11-19 19:08 发表
1、mysql数据库不可小觑，它虽然很多方面不是很完善或集成的不好，但它无论是在性能还是功能上，还是有很多亮点的，尤其是它的多引擎技术，给了用户很多选择，有的引擎在某些方面的性能快的出奇，它对系统的资源要求也是非常的低，相同硬件条件下，它的性能和功能其他数据库系统是没办法和它比的。
2、ORACLE的这种不一致，可能说得挺吓人，其实并不是ORACLE系统的不完善，而是由它的锁模型决定的，它的锁是读写不阻塞的，当一行数据被加行锁后，其后的读却乐观的认为它没发生改变，其实，加锁的数据行是有两个结果的：commit,rollback，其中一个结果会和查询出来的结果不一致；同时其他数据库的锁模型，要比较悲观些，比如：mssql的锁模型，在一个表上有DML操作事务发生但未提交前，其他事务是不可以进行的，哪怕是读也是，这些后面的事务会被阻塞，因为它认为未提交的DML事务结果未定，所以其后的事务要等这个事务COMMIT或ROLLBACK后，才可以进行其后阻塞的事务，因为数据被修改了，在事务完成前，无法知道被修改的最后结果，但这就导致了并发修改性能的低效。
3、当然，MSSQL2005也出现了多版本功能，虽然不象ORACLE那么完善，但它毕竟给用户一个选择，可以选择读写不阻塞，而写事务结束前，就认为它没发生变化。当然，ORACLE也给了用户一个选择，那就是事务的serializable，那就是事务的串行执行，可ORACLE用户有哪个会用这个事务级别呢？MSSQL2005用户，又有多少用到多版本呢？真所谓有得必有失啊。

您的解释才是惊人的，好好看看文档，评价一个产品以前要对这个产品有本质的了解，至少oracle是和您说的有些不一样的

sqysl

呵呵，我不能保证说的都是对的，不过，我愿意听听你的有关ORACLE本质的高见，只说和俺认为的不一样的就可以了，说说，也让俺学习学习，期待中。。。

[ 本帖最后由 sqysl 于 2008-11-19 21:39 编辑 ]