db2回滚处理问题

hahabean

原帖由 wxz75 于 2004-4-3 08:56 发表
要说清楚得打多少字啊!?我又没职责在这儿上课.我看你也是对数据库很有经验的人,讨论一下对大家或许都又提高.给个电话,OK?

不过关于这个问题我和IBM的人探讨过,最后结果是他们被我说服,承认这方面DB2存在不足.呵呵!所以我可决不是信口开河哦!

读到这儿，实在受不了，你这人有点轻狂。说问题比价解释，对别人有横加指责，实在没啥意思。

hahabean

原帖由 hahabean 于 2009-12-23 12:02 发表


读到这儿，实在受不了，你这人有点轻狂。说问题比价解释，对别人有横加指责，实在没啥意思。

sorry，看贴没注意时间，呵呵

sqysl

读一致性，除了oracle，其他数据库都差不多吧，关于回滚，MSSQL有日志，DB2也有啊，都是通过日志实现的。

ppgoml

看到这么精彩的老贴，虽然花了我2个小时，但是还是觉得很值得一看。
接触DB2比较多，但是看了本贴以后发现Oracle利用回滚段的多版本读，个人认为确实是一个不错的设计，否则DB2 9.7中也不会提供一个新的隔离级别CC来实现相同的用户体验了，虽然和oracle的所用的技术细节有些不同。

wolfop

我仍然不认可多版本一致性是业务需要的，而且开销太大，所以ORACLE自己的内存数据库TimesTen为了保证性能也不支持多版本一致性。
而DB2 9.7并不是有新的隔离级别，而是在CS级别下，使用lastcommit的值而已。

kt563

其实讨论到后面还是和具体业务场景有关的。
oracle 的高并发性可以很好的应用于一些数据一致性“准实时”要求的环境，例如电信移动业务场景，当就算是预付费用户在通话时，在余额用完发生欠费时，秒级计费的时代来临，可以将企业的损失风险降到最低，这个经常是电信移动企业可承受的损失范围。这一业务特点对“读一致性”的要求就不会太高，但对于“并发性”要求就比较高，多版本读的oracle在oltp的业务环境必然会比较受欢迎。基于大数据存储的数据仓库环境的下，由于oracle的“share-disk”体系结构会对性能形成一定的消极的影响，在DSS系统中用ORACLE做后台数据库就会形成一定的局限性，所以电信移动业务类型的数据仓库数据库在DB2（SHARE-NOTHING）还是比较合适的。例如：上海移动的BOSS侧OLTP系统用的oracle数据库，BASS侧数据仓库环境用的DB2数据库，是一个比较经典的案例。
db2的数据一致性“实时”要求会对数据库的并发产生影响，但通过调整参数和其他优化手段可以将影响降低，但IBM能很好的利用硬件技术去弥补这一影响，前面已经有所提及。在银行业务场景中，去柜台取钱这一个业务来讲，可能其他系统窗口在处理同一帐户的“取钱”操作，这个金额一般不能由银行侧进行控制（好象没怎么听说柜台取现有大额限制，虽然巨额取款会有相应确认操作），相对而言现金风险会比较高。假如为了提高并发而允许数据的多版本读，对于不能控制取款金额的操作将会给银行带来不可估量的损失，银行方面肯定不愿意看到这个现象。所以数据一致性“实时”高的DB2就会受银行的欢迎，这毕竟为企业的经营降低了技术风险。跟前面同样的道理，在大数据量的数据仓库环境，DB2（SHARE-NOTHING）的系统架构特性和IBM相关硬件产品仍比较适合DSS系统。
前面暂提到了ORACLE和DB2两种数据库，象SYSBASE(“读一致性”类似DB2)也在农行获得了订单，作为联机综合业务系统和分析类信息系统的数据库，也算是一个比较有意思的案例，例外在电网分析型数据仓库的数据库产品。SYBASE的产品定位（内存、移动数据库等）却让其在大型数据管理领域渐行渐远，在大型数据库市场的份额逐渐被其他数据库厂商蚕食。

[ 本帖最后由 kt563 于 2011-7-25 11:02 编辑 ]

燕听雨

反正我就用DB2了，主机的没有问题，最新版的也换了个方法实现了，只是迟了那么一点点，反正眼下好多公司钱多，掏出来，测试purescale啊

tom_fans

这个问题怎么还在讨论？ 很多人对所谓的一致性有个特殊的错误的认识，尤其是ORACLE DBA。 什么是一致，你告诉我。谈一致性，其实不过是谈isolate level而已，这个每个数据库都一样，所谓不要在用一致性来作为话题，感觉很幼稚。

一直以来，ORACLE的口号是获取一致性数据，而DB2的口号是获取当前数据，。 当然，ORACLE一致性获取更加高明，这也是后来很多数据库学习的理由。现在的DB2 v9.7也同样使用了这个类似的功能，只不过和ORACLE的多版本查询相比还是差一些。

DB2要取当前数据，说白了就是select都要用S锁，导致并发差，有时候我也在想，DB2的这种机制能用在OLTP系统? 到目前为止，也只听到说大部分是银行里的系统，银行里的transaction我猜想语句都非常简单，就好比所谓的存钱，取钱之类，真正用在高并发的OLTP谁能给个例子？ 什么公司用了？

另外ORACLE DBA也喜欢用回滚段来作为话题，ORACLE数据库回滚段的优势造就了ORACLE多版本查询取代部分锁机制，说白了不过是select不需要锁，这样的并发显而易见，另外flashback也是回滚段引申出来的，这个功能可以flashback table，database，这个功能有点鸡肋，也许对dataguard有比较明显的优势。

但是这并不表示数据库就一定要回滚段，ORACLE通过UNDO SEGMENT来回滚，DB2就也要吗？ DB2通过ONLINE LOG来回滚怎么不可以？如果说DB2可能会有LOG FULL的情况，那么ORACLE同样也有UNDO过时的问题，导致UNDO不了。

不管如何，ORACLE 的UNDO非常高明，不知道当时是谁来设计ORACLE的这个UNDO，有时候我在想这个人真他妈聪明。 DB2成天号称获取当前数据有时候觉得挺丢人的，一个insert，还没commit，select竟然要去等待。没有commit表示这个数据根本就不存在，为了一个不存在的数据去等待，难道不丢人吗？ update也是同样的道理. 幸好v9.5+版本已经能够获取前映像了,算是个小进步.

其实我讨厌DB2的地方不是上面提高的东西，ORACLE任何功能的实现都依靠SQL来实现，而DB2却相反，什么东西依靠OS层来实现，既然是做数据库，就做出个样子，别把数据库和OS太混淆了。

get snapshot ，DB2 TOP，db2expln, db2exfmt ，等等等等

反之ORACLE， v$view, dba_view ,等等都是依靠SQL来获取。 ORACLE可以很容易的通过dba_hist来获取历史数据库状态信息，而DB2，好像天方夜谭，一个很忙的数据库get snapshot肯定有很多数据，还要通过grep来过滤，烦不烦？获取计划的命令后面那么多参数，ORACLE一句SQL搞定。

到了9.7，DB2也学ORACLE加了一些视图，DB2设计者的思维和ORACLE设计者的思维从我来看，完全不一样，差距太大。ORACLE设计者明显头脑灵活，简洁，而DB2设计者头脑混乱，思路不清。

kt563

其实一致性和并发一直是数据库领域的一个永恒的话题，深入到底层无非是锁机制的问题，如何抉择和定位及后期的弥补是数据库厂商一个艰难的课题。
ORACLE采用乐观锁机制和回滚段镜像带来了高并发和数据的多版本读，这点是好的，而DB2和其他数据库产品（如SYBASE，SQL SERVER）采用悲观锁机制带来了数据的当前读，当然DB2后来也引入了乐观锁机制（V9.5+）。
产品层面，ORACLE推出了RAC，DB2推出了PURESCALE，着力点无非是要保证业务环境的高可用性。
从DB2发布的新版本新增功能来看，DB2在不断向ORACLE学习，作为老牌的数据库厂商，“师夷长技”这点还是值得肯定的。
一直以来，DB2都是以贵族的身份出现在数据库领域，ORACLE以王者的风范出现，不管是售前还是售后环节，^_^。
无论是ORACLE还是DB2，都只是一个数据库产品，是产品就必然有其优缺点，如何做到“光大其优点，弥补其缺点”，为客户带来更好的服务才是王道。
做DBA，今后的技术方向不能只盯紧数据库，应该把这把刀磨砺好后，扩展到其他层面，例如应用，服务器，操作系统，中间件，存储，网络等，这样的话在解决实际问题才可能更全面些。当然客户也更喜欢软硬件结合得很好的厂商,无论ORACLE还是IBM,或者其他厂商,其方向都不会只是数据库,都已经在提解决方案了,这个可以有。
数据库领域的相关高人还是比较佩服盖国强和牛新庄等人的，技术做的好，人也不错，当前钱也赚得不少，^_^。

[ 本帖最后由 kt563 于 2011-7-25 10:57 编辑 ]

xiaowg

如果说DB2可能会有LOG FULL的情况 => 整个系统挂了
那么ORACLE同样也有UNDO过时的问题，导致UNDO不了不得 => 某个事务失败
比较两者, 影响级别大不一样.

[ 本帖最后由 xiaowg 于 2011-8-12 11:09 编辑 ]