数据库的功能都是差不多的，不过我觉得，DB2的海量处理能力比ORACLE要好多了，ORACLE 的RAC功能基本上是垃圾，在国内被ORACLE的销售吹的飞上天了。

[quote]原帖由 [i]glz[/i] 于 2006-12-18 11:25 发表
数据库的功能都是差不多的，不过我觉得，DB2的海量处理能力比ORACLE要好多了，ORACLE 的RAC功能基本上是垃圾，在国内被ORACLE的销售吹的飞上天了。 [/quote]


如果对业务连续性非常敏感的话，RAC的并行模式对快速物理故障恢复还是非常有用的。

DB2没有这样功能，后来弄了一个HADR，也只是日志复制，分区环境下还用不了，加上HACMP热备方式，论切换时间也比不了RAC。

企业版的DB2的分区功能就可以并行,互为热备.  切换速度我在2002年就测试过,不比当时的OPS差..   而且DB2的分区功能才是真正的并行.storage是可以分开的.  Oracle的需要很好的IO才可以支持OPS 的并发访问.

[[i] 本帖最后由 darkbug 于 2006-12-18 15:37 编辑 [/i]]

[quote]原帖由 [i]zdygk[/i] 于 2006-12-18 14:40 发表
企业版的DB2的分区功能就可以并行,互为热备.  切换速度我在2002年就测试过,不比当时的OPS差..   而且DB2的分区功能才是真正的并行.storage是可以分开的.  Oracle的需要很好的IO才可以支持OPS 的并发访问. [/quote]
你咋测的？那个最复杂情况切换脚本片段中光sleep就要至少几分钟，16P，4P我都试过。

db2的分区＋HA解决方案有缺陷，就是切换时候要判断down机情况，node0也就是一般用的管理分区，要是它所在的机器先down了（用halt测试），db2stop force其他的分区几乎停不下来。在不halt node0所在机器的情况下，db2stop、db2start的确挺快，可是对于突然down机呢？

对于多机互备的HA环境下，app start脚本非常复杂，先要判断情况，node0状态如何？根据node0的位置和状态选择stop或者kill干净所有机器上的所有分区的db2进程，再改了db2nodes文件，然后再启动db2，如果多机互备会出现应用集中问题，还要考虑db2配置参数，比如bufferpool，脚本里面还要多留些sleep时间，让每一步的操作有足够的时间完成，不然。。。。。

db2的partition因为share nothing和数据散列，并发的确强，但是切换时候复杂，另外不支持HADR，在保持业务持续性方面不好；Oracle的rac因为share disk，并发差一些，但是在node down机的情况下不用额外动作，只是需要一点时间自适应，保持业务持续性有优势。

有强就有弱，都有缺点的。。。。

[quote]原帖由 [i]zdygk[/i] 于 2006-12-18 14:40 发表
企业版的DB2的分区功能就可以并行,互为热备.  切换速度我在2002年就测试过,不比当时的OPS差..   而且DB2的分区功能才是真正的并行.storage是可以分开的.  Oracle的需要很好的IO才可以支持OPS 的并发访问. [/quote]
老观念了，OPS全部要写到磁盘，RAC是基于内存之间通过网络通信的。
DB2通过HACMP切换不可能比ORACLE RAC 快，主要是在AIX下面的vg需要接管的时间，varyon vg的速度很慢，尤其VG和LV多的情况。换到HPUX和SOLARIS下面一样。但是RAC的VG是并发VG ，双击上面都是varyon的状态。

[quote]原帖由 [i]wolfop[/i] 于 2006-12-19 12:12 发表

老观念了，OPS全部要写到磁盘，RAC是基于内存之间通过网络通信的。
DB2通过HACMP切换不可能比ORACLE RAC 快，主要是在AIX下面的vg需要接管的时间，varyon vg的速度很慢，尤其VG和LV多的情况。换到HPUX和SOLA ... [/quote]

VG切换速度的问题好办，可以建成concurrent VG，切换很快，个人感觉大概在10秒这个级别上

db2每个分区相当于一个实例，切换的时候所有分区都要先停下来，然后再启动。问题就在这个“停”上面；

要是作为管理分区的node0分区先完蛋，其他所有的分区正常停下来几乎不可能，只能kill，还要clean，注意：是每一台机器上的每一个分区！然后才能进入启动阶段，也就是说只要切换，一定有一段不短的时间整个数据库不能提供任何服务，而且这个时间比较要命的长。

就算管理分区不完蛋，切换过程也要先正常停一次所有的分区，然后再启动，这个时间感觉也需要60秒级别上

而且，如果多机互备，切换时势必造成应用集中，资源配给就成了一个新的问题，而且比较麻烦。

RAC不存在切换问题，down node出现时候，可以立刻把down node的所有资源“收编”，然后对外提供服务，这个收编的过程很短，我自己没有测试过，但是听说可以调整到10秒这个级别，毕竟收编比切换要做的工作少很多吧。

[quote]原帖由 [i]darkbug[/i] 于 2006-12-18 13:28 发表



如果对业务连续性非常敏感的话，RAC的并行模式对快速物理故障恢复还是非常有用的。

DB2没有这样功能，后来弄了一个HADR，也只是日志复制，分区环境下还用不了，加上HACMP热备方式，论切换时间也比不 ... [/quote]

HADR好像是从INFORMIX的HDR转过来的，相当于oracle的LOGICAL dataguard。

的确有这样的说法。

因为是滚日志，多分区条件下多个日志，放到一起滚就不好办了，因为不同机器的时间误差，排序就很困难，所以目前还不支持多分区。（个人猜测）

个人认为HADR更多应该是用在DR上，而不是HA上

RAC的垃圾不在这里
RAC的切换是非常的快，我测过，基于session的切换切过去可以接着做（select语句），其他的交易会自动重新链接到未down的node，对交易影响不大，这点是非常强。
RAC最大的问题是性能问题，当然和应用什么的很多方面都有关系了。。。。。

HDR我用过，可以一台生产，一台查询，很好的搭配。但是做HA，我认为也没必要。

session级别的冗余，只能靠软件自己内部解决，HACMP这样主要防物理故障的东西是无能为力的

[quote]原帖由 [i]darkbug[/i] 于 2006-12-19 14:14 发表


VG切换速度的问题好办，可以建成concurrent VG，切换很快，个人感觉大概在10秒这个级别上

db2每个分区相当于一个实例，切换的时候所有分区都要先停下来，然后再启动。问题就在这个“停”上面；

要是 ... [/quote]

在生产环境的DB2或者IDS上面你这样做过没？也配置城并发VG？
我们的环境遇到这个问题的时候，IBM原厂从来没提出可以这样来解决VG接管慢的问题。是否有副作用？

[quote]原帖由 [i]wolfop[/i] 于 2006-12-19 17:45 发表


在生产环境的DB2或者IDS上面你这样做过没？也配置城并发VG？
我们的环境遇到这个问题的时候，IBM原厂从来没提出可以这样来解决VG接管慢的问题。是否有副作用？ [/quote]

我做过，现在我支持的有两个生产系统在用

ha的手册里面说过这种方法，副作用不敢说，至少我没有发现

这年头还有IBM原厂做HA的？另外，VG转移慢不一定是VG的问题，可能应用停的慢，或者停的不干净

hacmp5.2以后感觉VG移动很快呀

[[i] 本帖最后由 darkbug 于 2006-12-20 09:49 编辑 [/i]]

我觉的可能的问题是：
原主机应用挂起，内存有一些修改的数据没有写到硬盘，而备机已经起来，开始访问同一块数据，并发vg怎么协商这个操作：1.直接杀掉原应用的访问，备机开始访问。
2。等待原应用正常停止。
3.备机直接写数据，不管源主机应用（原应用还有可能写盘）。
我认为2的情况更大。。。。
不知对不对

要看应用如何挂起？

如果指主机直接歇菜，内存的东西可能是来不及写入硬盘，相关进程也都死光了，另外db2不存在同时访问一个数据块的问题，只有数据文件或者裸设备。备机启动的时候db2自己会check数据文件的，一般没事。

如果HA出现一些异常乱切，可以通过app start、stop脚本来做一些事情，比如kill干净db2进程，来保证数据文件不被乱写。

但是如果应用自己乱了状态，乱读乱写，有些麻烦，不过那个似乎跟HA没有直接关系。

还是那句话，没有万全之策，所以有些银行连HA都不用，干脆全部靠人

主机直接歇菜是另外情况，前台的业务直接回滚了，不会有影响；原主机挂起才会造成这样的问题，当然你说的kill的方法也可能行，但是kill数据库进程，我觉得是有点野蛮操作。
另外数据库读数据是以数据块（或数据页）方式进行的。

。。。。备机启动的时候db2自己会check数据文件的，一般没事。

我说的也有这种情况，vg是并行的，db2能强制独占vg吗？如果能 当然就不会有什么问题了。

[quote]原帖由 [i]glz[/i] 于 2006-12-20 11:21 发表
。。。。备机启动的时候db2自己会check数据文件的，一般没事。

我说的也有这种情况，vg是并行的，db2能强制独占vg吗？如果能 当然就不会有什么问题了。 [/quote]

干吗要强制独占？什么情况会出现这种要求？

unix平台上，还是oracle性能好一些

[quote]原帖由 [i]十年[/i] 于 2006-12-28 15:07 发表
unix平台上，还是oracle性能好一些 [/quote]
何以见得？

看看测试数据, IBM的第一名就是在Unix平台上拿到的.这个没有必要再争论. 拜托.