db2回滚处理问题

yhangw

最初由 caucasus_lee 发布
[B]

从这两点来说，我认为Oracle的cluster技术还是要优于DB2的cluster技术的。

最后，我想说一句，任何一个企业的决策者，在考虑数据库产品时，一定要考虑整个IT业的技术环境。相对来说，oracle的技术环境是优于DB2的。这点我想没有人反对 [/B]

我认为就Oracle与DB2有竞争的部分来说Oracle的cluster对DB2确实有优势。

与RAC对应，DB2没有一个完全对应的冬冬。

对于海量数据的BI系统，DPF+HACMP地解决方案缺点在于切换时间一般稍长--其实也看具体实施，目前的实施一般在比较简单的层次上。澄清一点，这种方案里面，一个节点down并不一定导致其他节点不可用，不涉及该节点的sql还是能跑的。当然，主节点down除外。

如果小数据量的交易系统，HADR提供了远比RAC更快速的切换，一般在秒级。缺点是目前不能应用多个节点。

mwong

最初由 yhangw 发布
[B]

我认为就Oracle与DB2有竞争的部分来说Oracle的cluster对DB2确实有优势。

与RAC对应，DB2没有一个完全对应的冬冬。

对于海量数据的BI系统，DPF+HACMP地解决方案缺点在于切换时间一般稍长--其实也看具体实施，目前的实施一般在比较简单的层次上。澄清一点，这种方案里面，一个节点down并不一定导致其他节点不可用，不涉及该节点的sql还是能跑的。当然，主节点down除外。

如果小数据量的交易系统，HADR提供了远比RAC更快速的切换，一般在秒级。缺点是目前不能应用多个节点。 [/B]

补充一下。

关于cluster，请大家分清楚两个概念：cluster for scalability vs. cluster for high availability。我们说的扩展性scalability是指
“性能的提高/节点的增加”，不是简单的叠加节点数目。Oracle试图使用RAC来同时达到高可用性和可扩展性这两个目的。DB2 UDB针对高可用性的解决方案是HADR，针对可扩展性是share-nothing的DPF分区技术。

孰优孰劣？

RAC看起来很美，但share-disk架构会导致节点数可扩展性很差，最大的瓶颈在于节点间通讯。另外，高可用性方面，RAC的节点fail后也不是完全透明、对整个机群的可用性完全没有影响。这点我相信熟悉Oracle的朋友会比我更清楚。

DB2 UDB的分区技术对应用规划设计有比较高的要求。设计的不好，无法获得高性能和扩展性是必然的；但设计得好，是RAC无法匹敌的，目前最多的DPF是1000个节点。高可用性的解决方案目前有很多：HACMP/Veritas/IBM TSA一类的cluster软件，Replication，还有新的HADR。正如yhangw所说，HADR可以做到秒级切换，（我不知道RAC能否做到？）缺点是目前还不支持DPF。至于DPF+HACMP的认识误区，yhangw已经提过。

我个人的观点是，RAC易于实施，但效果如何，是不是能达到真正的扩展性和高可用性，需要冷静思考。不可否认，RAC把这两个技术点合二为一的市场定位，很容易让客户感觉良好，但可能是一个错觉。而DB2的确受国内当前的技术水平和条件制约，要有一个良好的实施比较困难。这也是我们大家需要继续努力的地方。

附上一个视角比较客观的白皮书，虽然是IBM发表的，但内容是Oracle专家提出的：
Much to Oracle’s chagrin, an article has been published in the
International Oracle Users Group Select Journal (3rd Qtr. 2003)
entitled “You Probably Don’t Need RAC”, authored by Mogens
Norgaard, a renowned Oracle expert and member of an elite group of
40 Oracle specialists (known as the Oak Table Network). The
conclusion of the article states, “Most likely, you probably don’t
need RAC. Alternatives will usually be cheaper, easier to
manage and quite sufficient.”

欢迎大家一起讨论。

caucasus_lee

RAC看起来很美，但share-disk架构会导致节点数可扩展性很差，最大的瓶颈在于节点间通讯。另外，高可用性方面，RAC的节点fail后也不是完全透明、对整个机群的可用性完全没有影响。这点我相信熟悉Oracle的朋友会比我更清楚。

DB2 UDB的分区技术对应用规划设计有比较高的要求。设计的不好，无法获得高性能和扩展性是必然的；但设计得好，是RAC无法匹敌的，目前最多的DPF是1000个节点。高可用性的解决方案目前有很多：HACMP/Veritas/IBM TSA一类的cluster软件，Replication，还有新的HADR。正如yhangw所说，HADR可以做到秒级切换，（我不知道RAC能否做到？）缺点是目前还不支持DPF。至于DPF+HACMP的认识误区，yhangw已经提过。

附上一个视角比较客观的白皮书，虽然是IBM发表的，但内容是Oracle专家提出的：
Much to Oracle’s chagrin, an article has been published in the
International Oracle Users Group Select Journal (3rd Qtr. 2003)
entitled “You Probably Don’t Need RAC”, authored by Mogens
Norgaard, a renowned Oracle expert and member of an elite group of
40 Oracle specialists (known as the Oak Table Network). The
conclusion of the article states, “Most likely, you probably don’t
need RAC. Alternatives will usually be cheaper, easier to
manage and quite sufficient.”

欢迎大家一起讨论。 [/B][/QUOTE]

第一段有凭空捏造的嫌隙 ：）
RAC的cache fusion技术，在部署是如果你仔细研究reference，会看到这样的内容 ---- heartbeat配置建议前兆以太网卡或以上，目前的项目都是光纤。至于是否产生瓶颈，也和应用的部署有很大关系，这也是体现初始规划和应用程序设计人员价值的地方，这一点不会有人怀疑。

第二段，由于不懂DB2，不敢乱说，但是好像正好符合了“IBM软件不足硬件补”的说法

第三段，Oracle专家的说法，值得怀疑，保留意见：）

suwolf

最初由 cliser 发布
[B]银行每天9点多业务高峰期的估计一个省也有3000个窗口在同时办业务。呵呵。。。你能说DB2不好。 [/B]

这个问题，睡然4000个点同时营业，可是使用的却是第个的卡与存折，这个东西不太可能同时被几个人使用。所以感觉不出来，但是真的是OLAP的话，问题真大的。本人正在学习db2，原先使用ORACLE  SYBASE  MSSQLSER,对一家超级大医院而言，db2跑 起来可能有问题的

booker2688

有怎么可怕吗？
其实把DB2分多个点处理就可以了。银行的系统好象是用sybase（以前），现在用的数据库我忘了。但是核心是用DB2。

gotocool

为什么RAC四节点就不行？？

mwong

最初由 caucasus_lee 发布

第一段有凭空捏造的嫌隙 ：）
RAC的cache fusion技术，在部署是如果你仔细研究reference，会看到这样的内容 ---- heartbeat配置建议前兆以太网卡或以上，目前的项目都是光纤。至于是否产生瓶颈，也和应用的部署有很大关系，这也是体现初始规划和应用程序设计人员价值的地方，这一点不会有人怀疑。

第二段，由于不懂DB2，不敢乱说，但是好像正好符合了“IBM软件不足硬件补”的说法

第三段，Oracle专家的说法，值得怀疑，保留意见：） [/B]

嘿嘿，我说的就是光纤都不够快。有谁见过超过8节点以上的RAC吗？

“软件不足硬件补”是我们讨论可扩展性的前提。我前面已经说了，我们讨论的RAC属于扩展性问题，不是性能问题。所有软件都有受硬件能力限制的时候。扩展性好还是不好，就是看是否能通过硬件来获取近于线性的性能曲线。老大你混淆了我们讨论的话题了：）

caucasus_lee

最初由 mwong 发布
[B]

嘿嘿，我说的就是光纤都不够快。有谁见过超过8节点以上的RAC吗？

“软件不足硬件补”是我们讨论可扩展性的前提。我前面已经说了，我们讨论的RAC属于扩展性问题，不是性能问题。所有软件都有受硬件能力限制的时候。扩展性好还是不好，就是看是否能通过硬件来获取近于线性的性能曲线。老大你混淆了我们讨论的话题了：） [/B]

呵呵，8个节点的RAC你没有见过，不等于没有。IT很大的 ：）

可扩展性方面，硬件的可扩展性我们也可以讨论一下：

请问，硬件的可扩展性如何实现？

请不要告诉我通过背板或者总线之类的高速连接实现。

同意“扩展性好还是不好，就是看是否能通过硬件来获取近于线性的性能曲线”的观点。同时，Oracle是一个在硬件平台上运行的软件，RAC的架构保证了，只要硬件可以提供接近线性的增长，oracle没有问题。

同时，也没有必要就某一种特定的应用环境展开讨论。早就说过，一个系统的好坏不仅仅只是DB的问题，和硬件功能和应用设计都有非常的大的关心。

再来说说软件的可扩展性：

对于用户来说，可扩展性的一个最最基本的要求就是实施扩展时无需中断应用，这点我想没有人反对。

RAC技术就满足了这个基本的需求，而DB2的cluster无论如何无法满足的。这点不知道老兄有没有异议？

其它可扩展性问题方面，诸如保护投资，降低成本之类，各个产品都有自己的一种计算方法。我知道的时Oracle的RAC技术不需要硬件平台完全对称，只需要操作系统保持一致，不知DB2是否能够做到？（这个是要请教一下的）

良好的可移植性也是可扩展性的一个指标，oracle在各个平台上的互相移植非常的容易，DB2呢？我听说DB2在不同平台上的内核不一致，导致移植工作非常困难，不知是否属实？

因此，就是但从可扩展性来说，RAC也是好于DB2的cluster的。：）

caucasus_lee

最初由 mwong 发布
[B]

补充一下。

关于cluster，请大家分清楚两个概念：cluster for scalability vs. cluster for high availability。我们说的扩展性scalability是指
“性能的提高/节点的增加”，不是简单的叠加节点数目。Oracle试图使用RAC来同时达到高可用性和可扩展性这两个目的。DB2 UDB针对高可用性的解决方案是HADR，针对可扩展性是share-nothing的DPF分区技术。

孰优孰劣？

RAC看起来很美，但share-disk架构会导致节点数可扩展性很差，最大的瓶颈在于节点间通讯。另外，高可用性方面，RAC的节点fail后也不是完全透明、对整个机群的可用性完全没有影响。这点我相信熟悉Oracle的朋友会比我更清楚。

DB2 UDB的分区技术对应用规划设计有比较高的要求。设计的不好，无法获得高性能和扩展性是必然的；但设计得好，是RAC无法匹敌的，目前最多的DPF是1000个节点。高可用性的解决方案目前有很多：HACMP/Veritas/IBM TSA一类的cluster软件，Replication，还有新的HADR。正如yhangw所说，HADR可以做到秒级切换，（我不知道RAC能否做到？）缺点是目前还不支持DPF。至于DPF+HACMP的认识误区，yhangw已经提过。

我个人的观点是，RAC易于实施，但效果如何，是不是能达到真正的扩展性和高可用性，需要冷静思考。不可否认，RAC把这两个技术点合二为一的市场定位，很容易让客户感觉良好，但可能是一个错觉。而DB2的确受国内当前的技术水平和条件制约，要有一个良好的实施比较困难。这也是我们大家需要继续努力的地方。

附上一个视角比较客观的白皮书，虽然是IBM发表的，但内容是Oracle专家提出的：
Much to Oracle’s chagrin, an article has been published in the
International Oracle Users Group Select Journal (3rd Qtr. 2003)
entitled “You Probably Don’t Need RAC”, authored by Mogens
Norgaard, a renowned Oracle expert and member of an elite group of
40 Oracle specialists (known as the Oak Table Network). The
conclusion of the article states, “Most likely, you probably don’t
need RAC. Alternatives will usually be cheaper, easier to
manage and quite sufficient.”

欢迎大家一起讨论。 [/B]

五一长假，有比较多的闲工夫，又看了一遍帖子。


mwong兄提到下面的说法：

HACMP/Veritas/IBM TSA一类的cluster软件，Replication，还有新的HADR。正如yhangw所说，HADR可以做到秒级切换，（我不知道RAC能否做到？）

有一个明显的偏差，这里提到的cluster软件，只是cluster软件而已。cluster软件的功能是什么？是提供操作系统级别的集群，也就是说，操作系统级别的切换真的可以满足秒级切换没有错，但是操作系统切换了有什么用呢？必须将应用也切换过来是不是？这个应用就包括oracle，相信配过IBM HACMP主备模式的人都清楚，阵列和IP的切换确实是非常快（其实应该是十秒级），之后的应用切换，就要看应用自己的切换速度了。这个时间，恐怕就不是秒级了，完全是根据宕机那一刻，系统的繁忙程度成正比的。

其实我们大家都知道，这些cluster软件切换的一个重要环节就是配置Oracle切换脚本。如果配置过这样的脚本，就会知道，这个脚本就是关闭和启动数据库。因此，真正切换时间不应该只是计算硬件资源的切换，最关键的和时间最长的应该是应用重启一次的时间，具体时间的长短，我想有过实施经验的人都会很明白的。

这个讨论真是有意思，我喜欢

一村的小野猪

那位高手给个MSN 号出来，我有好多问题要问，最好做过PB +ORACLE 转PB +DB2 的，如M505所说，迁移起来搞死人~~~