欧阳峰

可以的

把日志和状态发上来看看2.既然是restore pending,是缺日志哇

只能说降低了脑裂的概率，不能完全消除，如果存储链路除了问题照样脑裂即使网络 心跳是好的，但是如果有人传送个大文件把网络带宽站满了照样脑裂，所以只能说降低，没法保证100%消除

不知道是oltp还是olap系统？猜测是olap1. 每个月大概10M条-20M条，每条1K,也就是每个月的数据量在10G-20G之间。2.如果是olap系统，而且在8.2版本上来说数据量不小，因此建议表空间选择16K起步。3.按照你给的总量2亿条记录，每

坏块分为逻辑坏块和物理坏块：物理坏块只能通过底层硬件来保护了逻辑坏块有些是bug引起，有些是人为引起，所以该打补丁打补丁

db2dart 应该可以，还有一种方式就是做个全备，然后通过db2ckbkp检查备份不知是否可行

那其实就用你需要的这两个列作为条件不就可以了吗 select a.* from test a, test b where a.hykh=b.hykh and a.bbrq=b.bbrqorder by ...........应该有更简单的sql写法，暂时想不来了，给你一个比较笨重的sql先试一试

[i=s] 本帖最后由 欧阳峰 于 2015-12-15 10:58 编辑 死锁 or 锁超时，令我最为关注的是为何在业务时间（11.07分这个时间猜测应该是业务时间段吧）做重建索引的这种ddl操作，这是大忌！2. 第二，这种ddl操作会锁整张表的，这种操

方案可行，有注意的细节就是在目标端建立asm group的时候最好名字相同，否则在恢复的时候需要进行convert。2. 不能把ocr和voting恢复到目标端的，这样会出问题了，ocr和voting里面记录的是clusterwar的信息，里面有vip , asm ,

如果没有任何备份，那么只能找原厂挖掘日志了，前提是有归档日志