一篇关于Oracle与DB2精彩讨论 (转载)
db2回滚处理问题 本人是DB2的初学者，和oracle,sybase,sql server作比较，发现在处理rollback时有些疑问，象oracle是有rollback segment，sybase和sql server有日志段，但在DB2中好象是找不到类似于oracle的rollback segment或者是sybase之类的日志段，是不是其恢复和rollback都是利...显示全部
db2回滚处理问题 本人是DB2的初学者，和oracle,sybase,sql server作比较，发现在处理rollback时有些疑问，象oracle是有rollback segment，sybase和sql server有日志段，但在DB2中好象是找不到类似于oracle的rollback segment或者是sybase之类的日志段，是不是其恢复和rollback都是利用其日志文件来实现，因为好象其日志文件有primary和secondary之分，而且有整个日志文件大小限制，是不是这个大小限制也决定了其能rollback的程度，不知道理解是否正确，请指导。 -------------------------------------------------------------------------- 你发现了DB2的一个大问题! 没错,DB2没有rollback segment,它只有log.
回退时使用的是online log.
你再往深处想想,这样一来缺省情况下DB2就失去了读一致性,可怕吧.
当然可以通过调整参数来强行保证读一致性,但又失去了并发性.
个人认为这是DB2的一个大缺陷! -------------------------------------------------------呵呵,其实发现db2在某些方面还是不错的,特别是在大型处理方面,可以比较方便的把数据库分散到多个节点上,但这其实也存在一个问题,在Unix平台下,好象需要把实例的相关代码放在共享NFS磁盘上,这好象又增加了安全方面的考虑了 ---------------------------------------------------------第一，任何由于日志空间满或主动roll back的交易，都可以被完整rollback;
第二，log file和读一致性没有关系。 一致性是可以通过isolation level解决,但这是以牺牲并发性为代价的.
DB2有四种隔离级别: 未提交读、游标稳定性(缺省)、读稳定性和可重复读. 未提交读的并发性最好,但是没有任何读一致性可言; 缺省的游标稳定性的并发性已经不如ORACLE(select 和update互相影响,ORACLE无此问题),而且读一致性也不能保证,其他两种级别应该可以保证读一致性,但并发性完全不可接受.
之所以银行可以用DB2有两个原因:
1.有些银行用的是390,机制不同
2.其他银行用UDB,但是银行和许多其他如电信等行业不同,对OLD IMAGE的要求不高,所以DB2的一致性和并发性的问题被掩盖.
这些问题我发现时也很疑惑,简直不敢相信.但我与IBM的资深工程师探讨过多次后,才一致共同确认DB2是存在此类缺陷.
这就是事情的经过,有些问题你光从DB2的角度看不出来,你如果能同时掌握DB2和ORACLE,就很容易看出来了.当然,以DB2的角度,ORACLE也不是没问题. ------------------------------------------------------没错,ROLLBACK 是ORACLE特有的,但可能恰恰是它的一个极大优势,这个问题不展开了.
说到结构,ORACLE使用的是share-disk结构, 4节点共享一块存储;DB2使用的是share-nothing结构, 4节点分别拥有各自的存储.如果ORACLE的一个节点宕,对其他节点几乎没有影响.而DB2一般来说表空间分散在nodegoup上,而nodegroup一般根据应用要求往往会包含至少2个节点.这样一来,DB2的一个节点宕,在相关资源切换完之前会对nodegroup内其他节点的可用性带来严重冲击.尽管如果设计得好, 切换时间可以控制在分钟级,但一个节点宕会影响其他节点这一点令电信类关键应用很难接受.DB2的share-nothing结构的提出主要是为了保证可扩展性和IO吞吐.但在目前高端存储和SAN网络开始流行的情况下,该架构的优点已经失去,相反稳定性上的缺点开始暴露.对ORACLE来说正相反. -------------------------------------------------------1. 很重要，除了uncommited read以外，不存在读一致性的问题，而这不是ur所能提供的。
2. 很少有（几乎没有）rr/rs的应用，正如你所说，并发行很差（包括oracle）。
3. Oracle采用data page(block)上记录ITL来控制并发，代价是增加磁盘的开销。
4. 不管哪种方式都有其利弊，从实践上看，Oracle的机制好一些，db2的应用碰到的并发问题很多都是因为从Oracle移植过来 ，不过移植是很痛苦的。
5. share-disk的问题不仅仅是IO吞吐，而是全局的锁，以及仅仅一个节点为请求工作。Oracle从未发布过比较好的/大的tpc-h cluster(RAC)测试。而这恰恰是SHARE-NOTHING的SCALABILITY的优势。我称之为inbeing 。
6. share-disk的可用性(inbeing)确实好，但不是宕机对其他节点没有影响，因为它涉及到remaster以及GCS重建 - 不知道10G有没有改进。DB2准备用Informix的HDR技术来解决这个问题。 -------------------------------------------------很高兴与大家交流.由于时间关系很多观点我先不说了.
不过我想全局锁的问题,ORACLE9I的RAC比起原来的OPS来说,以我的实际经验来看,似乎确实长进不少.
实际上我现在的一个很强烈的感觉是:我不敢用DB2代替ORACLE.以前我曾经以为DB2可以,但自从我学DB2后就不敢了.我们电信业看重的是并发性能和稳定性,尤其是后者.考核也是很严的,可能外人会觉得不尽人情.在这种情况下,DB2的很多优点我都只能视而不见了,而稳定性和并发性上的缺陷对我而言几乎否定了DB2的一切.其实我还是就事论事纯粹讨论技术的,有些话我没有说,怕引起DB2爱好者的反感.实际上,DB2培训完之后,有ORACLE DBA说:'真想不到DB2这样一个具有如此致命缺陷的数据库竟然会有人感用!?连一致性都没有!?'实际上我当时也有类似想法,所以事后我才找IBM工程师探讨,谈了很多,谈到了390,还有IBM和银行业的关系,等等.后来我才明白DB2的许多特点(无论是优点还是缺点)是怎么来的.但现在我个人仍然认为在关键OLTP上,选择DB2类似于自杀,但在DSS或BATCH业务(如ERP和银行业务)上,DB2没问题.个人观点,欢迎指正. -------------------------------------------------------------------------- 现在单台服务器的oltp性能已经很好了，单台p690上db2已经可以跑到1,000,000 tpmC（Oracle在Superdome上也做到了）。
---------------------------------------------------------我前面已经说了,有些问题要对ORACLE和DB2都有了解之后才能发现.....
从我个人经验来说,别的不说,我几乎可以肯定ORACLE真正做到了一致性和并发性的平衡,DB2则在这一点上存在差距.这种差距是否致命各人有个人的看法,我从我的实际经验判断认为还是比较严重的.你怎么认为是你的事.你我也没必要强求一致.这些不要再纠缠了吧,该说的我前面的贴子都说了,多说也无益.
还有,所谓国外DB2市场DB2占用如何如何优势这种言论,不信也罢.这种数据商业气息太浓,你知道它是怎么统计出来的?什么平台上的?什么行业的?ORACLE和DB2都可以认为自己是老大,关键看是从哪个角度去统计,看谁的文字游戏和商业欺诈玩得出色,仅此而已.
具我所知,似乎还是IBM的文字游戏和商业欺诈更出色些.上次有家公司招标,该公司的人对数据库不了解,于是要求做测试,谁快选谁.一开始怎么测都是DB2快,ORACLE很不解.后来发现,你猜怎么着?原来DB2把许多参数都调了,许多必要的校验都去掉了,速度那个快啊,和飞似的.(怎么调的?比如我就知道把隔离级别降低不就是公开的一招吗?别的还有.不过ORACLE可是没有这种公开招数的.)后来ORACLE也联系老美,如法炮制加上了内部参数,结果速度也一样快.不知道后来那公司选的是什么.我说这些,是想让你明白,技术是技术,商业是商业,呵呵! ---------------------------------------------------------行了行了，别老是技术技术的，你们选用4节点的RAC，就说明你们根本不是认真从技术上考虑。我大概也可以猜到你是哪个公司的，4节点的RAC分明就是给ORACLE的商业手段给骗了，之前是否有成功的案例也没有仔细调查吧，而且没有先对选项做试验。当然IBM也这么玩，上次打算卖给我们的XPS，当然就直接找测试环境加应用测试，马上否决。
而且当时测试的还挺搞笑，因为用EMC的设备，EMC的一个销售（原来做ORACLE，而且据说做的挺高）偷偷低拉我过去说：“你们这么大的数据库，INFORMIX不行啊，干嘛不用ORACLE呢？如果在你们的库再大点，ORCLE也不行了，应该用DB2“。哈哈。
收起
回退时使用的是online log.
你再往深处想想,这样一来缺省情况下DB2就失去了读一致性,可怕吧.
当然可以通过调整参数来强行保证读一致性,但又失去了并发性.
个人认为这是DB2的一个大缺陷! -------------------------------------------------------呵呵,其实发现db2在某些方面还是不错的,特别是在大型处理方面,可以比较方便的把数据库分散到多个节点上,但这其实也存在一个问题,在Unix平台下,好象需要把实例的相关代码放在共享NFS磁盘上,这好象又增加了安全方面的考虑了 ---------------------------------------------------------第一，任何由于日志空间满或主动roll back的交易，都可以被完整rollback;
第二，log file和读一致性没有关系。 一致性是可以通过isolation level解决,但这是以牺牲并发性为代价的.
DB2有四种隔离级别: 未提交读、游标稳定性(缺省)、读稳定性和可重复读. 未提交读的并发性最好,但是没有任何读一致性可言; 缺省的游标稳定性的并发性已经不如ORACLE(select 和update互相影响,ORACLE无此问题),而且读一致性也不能保证,其他两种级别应该可以保证读一致性,但并发性完全不可接受.
之所以银行可以用DB2有两个原因:
1.有些银行用的是390,机制不同
2.其他银行用UDB,但是银行和许多其他如电信等行业不同,对OLD IMAGE的要求不高,所以DB2的一致性和并发性的问题被掩盖.
这些问题我发现时也很疑惑,简直不敢相信.但我与IBM的资深工程师探讨过多次后,才一致共同确认DB2是存在此类缺陷.
这就是事情的经过,有些问题你光从DB2的角度看不出来,你如果能同时掌握DB2和ORACLE,就很容易看出来了.当然,以DB2的角度,ORACLE也不是没问题. ------------------------------------------------------没错,ROLLBACK 是ORACLE特有的,但可能恰恰是它的一个极大优势,这个问题不展开了.
说到结构,ORACLE使用的是share-disk结构, 4节点共享一块存储;DB2使用的是share-nothing结构, 4节点分别拥有各自的存储.如果ORACLE的一个节点宕,对其他节点几乎没有影响.而DB2一般来说表空间分散在nodegoup上,而nodegroup一般根据应用要求往往会包含至少2个节点.这样一来,DB2的一个节点宕,在相关资源切换完之前会对nodegroup内其他节点的可用性带来严重冲击.尽管如果设计得好, 切换时间可以控制在分钟级,但一个节点宕会影响其他节点这一点令电信类关键应用很难接受.DB2的share-nothing结构的提出主要是为了保证可扩展性和IO吞吐.但在目前高端存储和SAN网络开始流行的情况下,该架构的优点已经失去,相反稳定性上的缺点开始暴露.对ORACLE来说正相反. -------------------------------------------------------1. 很重要，除了uncommited read以外，不存在读一致性的问题，而这不是ur所能提供的。
2. 很少有（几乎没有）rr/rs的应用，正如你所说，并发行很差（包括oracle）。
3. Oracle采用data page(block)上记录ITL来控制并发，代价是增加磁盘的开销。
4. 不管哪种方式都有其利弊，从实践上看，Oracle的机制好一些，db2的应用碰到的并发问题很多都是因为从Oracle移植过来 ，不过移植是很痛苦的。
5. share-disk的问题不仅仅是IO吞吐，而是全局的锁，以及仅仅一个节点为请求工作。Oracle从未发布过比较好的/大的tpc-h cluster(RAC)测试。而这恰恰是SHARE-NOTHING的SCALABILITY的优势。我称之为inbeing 。
6. share-disk的可用性(inbeing)确实好，但不是宕机对其他节点没有影响，因为它涉及到remaster以及GCS重建 - 不知道10G有没有改进。DB2准备用Informix的HDR技术来解决这个问题。 -------------------------------------------------很高兴与大家交流.由于时间关系很多观点我先不说了.
不过我想全局锁的问题,ORACLE9I的RAC比起原来的OPS来说,以我的实际经验来看,似乎确实长进不少.
实际上我现在的一个很强烈的感觉是:我不敢用DB2代替ORACLE.以前我曾经以为DB2可以,但自从我学DB2后就不敢了.我们电信业看重的是并发性能和稳定性,尤其是后者.考核也是很严的,可能外人会觉得不尽人情.在这种情况下,DB2的很多优点我都只能视而不见了,而稳定性和并发性上的缺陷对我而言几乎否定了DB2的一切.其实我还是就事论事纯粹讨论技术的,有些话我没有说,怕引起DB2爱好者的反感.实际上,DB2培训完之后,有ORACLE DBA说:'真想不到DB2这样一个具有如此致命缺陷的数据库竟然会有人感用!?连一致性都没有!?'实际上我当时也有类似想法,所以事后我才找IBM工程师探讨,谈了很多,谈到了390,还有IBM和银行业的关系,等等.后来我才明白DB2的许多特点(无论是优点还是缺点)是怎么来的.但现在我个人仍然认为在关键OLTP上,选择DB2类似于自杀,但在DSS或BATCH业务(如ERP和银行业务)上,DB2没问题.个人观点,欢迎指正. -------------------------------------------------------------------------- 现在单台服务器的oltp性能已经很好了，单台p690上db2已经可以跑到1,000,000 tpmC（Oracle在Superdome上也做到了）。
---------------------------------------------------------我前面已经说了,有些问题要对ORACLE和DB2都有了解之后才能发现.....
从我个人经验来说,别的不说,我几乎可以肯定ORACLE真正做到了一致性和并发性的平衡,DB2则在这一点上存在差距.这种差距是否致命各人有个人的看法,我从我的实际经验判断认为还是比较严重的.你怎么认为是你的事.你我也没必要强求一致.这些不要再纠缠了吧,该说的我前面的贴子都说了,多说也无益.
还有,所谓国外DB2市场DB2占用如何如何优势这种言论,不信也罢.这种数据商业气息太浓,你知道它是怎么统计出来的?什么平台上的?什么行业的?ORACLE和DB2都可以认为自己是老大,关键看是从哪个角度去统计,看谁的文字游戏和商业欺诈玩得出色,仅此而已.
具我所知,似乎还是IBM的文字游戏和商业欺诈更出色些.上次有家公司招标,该公司的人对数据库不了解,于是要求做测试,谁快选谁.一开始怎么测都是DB2快,ORACLE很不解.后来发现,你猜怎么着?原来DB2把许多参数都调了,许多必要的校验都去掉了,速度那个快啊,和飞似的.(怎么调的?比如我就知道把隔离级别降低不就是公开的一招吗?别的还有.不过ORACLE可是没有这种公开招数的.)后来ORACLE也联系老美,如法炮制加上了内部参数,结果速度也一样快.不知道后来那公司选的是什么.我说这些,是想让你明白,技术是技术,商业是商业,呵呵! ---------------------------------------------------------行了行了，别老是技术技术的，你们选用4节点的RAC，就说明你们根本不是认真从技术上考虑。我大概也可以猜到你是哪个公司的，4节点的RAC分明就是给ORACLE的商业手段给骗了，之前是否有成功的案例也没有仔细调查吧，而且没有先对选项做试验。当然IBM也这么玩，上次打算卖给我们的XPS，当然就直接找测试环境加应用测试，马上否决。
而且当时测试的还挺搞笑，因为用EMC的设备，EMC的一个销售（原来做ORACLE，而且据说做的挺高）偷偷低拉我过去说：“你们这么大的数据库，INFORMIX不行啊，干嘛不用ORACLE呢？如果在你们的库再大点，ORCLE也不行了，应该用DB2“。哈哈。
收起