db2回滚处理问题

wxz75 · 发表于 2004-3-29 10:14

没错,ROLLBACK 是ORACLE特有的,但可能恰恰是它的一个极大优势,这个问题不展开了.
说到结构,ORACLE使用的是share-disk结构, 4节点共享一块存储;DB2使用的是share-nothing结构, 4节点分别拥有各自的存储.如果ORACLE的一个节点宕,对其他节点几乎没有影响.而DB2一般来说表空间分散在nodegoup上,而nodegroup一般根据应用要求往往会包含至少2个节点.这样一来,DB2的一个节点宕,在相关资源切换完之前会对nodegroup内其他节点的可用性带来严重冲击.尽管如果设计得好, 切换时间可以控制在分钟级,但一个节点宕会影响其他节点这一点令电信类关键应用很难接受.DB2的share-nothing结构的提出主要是为了保证可扩展性和IO吞吐.但在目前高端存储和SAN网络开始流行的情况下,该架构的优点已经失去,相反稳定性上的缺点开始暴露.对ORACLE来说正相反.

jiangzx · 发表于 2004-3-29 16:16

呵呵，DB2的分区数据库和群集应该是不同的概念吧，

m505 · 发表于 2004-3-29 16:32

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技术来解决这个问题。

wxz75 · 发表于 2004-3-29 17:30

很高兴与大家交流.由于时间关系很多观点我先不说了.
不过我想全局锁的问题,ORACLE9I的RAC比起原来的OPS来说,以我的实际经验来看,似乎确实长进不少.

实际上我现在的一个很强烈的感觉是:我不敢用DB2代替ORACLE.以前我曾经以为DB2可以,但自从我学DB2后就不敢了.我们电信业看重的是并发性能和稳定性,尤其是后者.考核也是很严的,可能外人会觉得不尽人情.在这种情况下,DB2的很多优点我都只能视而不见了,而稳定性和并发性上的缺陷对我而言几乎否定了DB2的一切.其实我还是就事论事纯粹讨论技术的,有些话我没有说,怕引起DB2爱好者的反感.实际上,DB2培训完之后,有ORACLE DBA说:'真想不到DB2这样一个具有如此致命缺陷的数据库竟然会有人感用!?连一致性都没有!?'实际上我当时也有类似想法,所以事后我才找IBM工程师探讨,谈了很多,谈到了390,还有IBM和银行业的关系,等等.后来我才明白DB2的许多特点(无论是优点还是缺点)是怎么来的.但现在我个人仍然认为在关键OLTP上,选择DB2类似于自杀,但在DSS或BATCH业务(如ERP和银行业务)上,DB2没问题.个人观点,欢迎指正.