已去除客户信息。

接到报障，客户说从ASM磁盘组DATA里踢了一块盘加到ARCH里，没加进去，再把盘加回DATA发现加不进去，然后DATA磁盘组挂了。

取回来日志，我读了一遍发现，不是这样的。

下面是当时事发的过程，客户从前一天下午就开始变更扩容，但是因为有一块盘原先应该给ARCH但是错给了DATA，并且已经rebalance完了，他们想纠正这个事情，强迫症是好事情。按道理说，踢出，加盘，就算是rebalance没有完成，也不会导致磁盘组整个坏掉，客户全程使用asmca操作的（我非常推荐用asmca来管理磁盘组，非常避讳用命令行），也没有用到force方式加盘。

事*故发生在第二天凌晨的2点21分。

最先从：

从DATA磁盘组drop DATA_008磁盘，这个MEMBER磁盘指向：

26秒之后，尝试向ARCH加盘（第一次误操作）（并且DATA的REBAL没有完成）

但是加错了盘，应该加/dev/mapper/asmARCH04p1（会报错，因为还在rebalance），但是加成了/dev/mapper/asmARCH04，这个盘的头部不是ASM的元数据，
是这个盘的分区表，ASM认为这个盘不是ASM磁盘组的，所以可以顺利加入ARCH磁盘组，并且会更新这个磁盘的头部，把分区表干掉：

因为/dev/mapper/asmARCH04p1这个分区虽然已经执行了从DATA的drop，但是它的rebalance操作没有完成。
所以在ARCH加盘的过程中DATA出现大量ASM block header错误，因为ARCH的add操作破坏了DATA的这个盘的信息。

日志如下：

因为ARCH的操作，需要向/dev/mapper/asmARCH04的头部写入ASM的元数据，这导致/dev/mapper/asmARCH04p1这个分区消失，随后DATA磁盘组被强制DISMOUNT：

这个操作触发ASM保护，去dismount掉其他磁盘组。ARCH的REBAL也被中断了（是好事）,因为数据没有被覆盖，或者说没有被覆盖很多。

我理解这个时候，数据基本上都在。但是随后ASM实例被重启了，不知道是agent做的还是人工做的。（这是第二个让事情不可收拾的操作）

重启之后，ASM主动去挂载各个磁盘组，只有DATA因为损坏无法挂载，但是ARCH是可以正常挂载的。
随即ARCH开始rebalance数据，擦除 asmARCH04 这个磁盘的数据，写入ARCH的的rebalance数据：
这是ARCH的成员盘信息：

随后rebalance完成了，这一步意味着asmARCH04的asmARCH04p1分区（仍然数据DATA磁盘组）的原先数据被清空。这一步清除了盘前面的无数个AU。这些AU原先是DATA磁盘组的。
之后，又有从ARCH里drop这个磁盘的操作：
drop掉那个错误进入的整盘。事实上这一步已经没什么意义了：

也成功rebalance完成了。将近5分钟时间说明/dev/mapper/asmARCH04上的数据有很大可能之前被抹除了5分钟。因完全未知抹除的是哪些DATA盘组的数据。
所以恢复难度较大。

这个盘目前的数据构成是，former的磁盘头，一部分arch的数据，和一部分原先DATA的数据。DATA的数据又是打散的。所以恢复难度非常大。
我建议是从备份和ARCH的归档，恢复数据库。如果ARCH中有数据库的redolog的副本，基本可以实现无损恢复。

事后，我在想，如果对ASM很熟悉的话，踢除的盘应该是FORMER状态，而不是CANDIDATE状态，如果知道这个，asmca加盘看到的状态异常就得警醒。

此外，在上一波rebalance没有完成的时候，asmca似乎是看不到这个盘的，操作者原先应该是想找p1的，但是这个盘没有从rebalance里走出来。asmca看不到，加上熬夜太久，凌晨两三点是人最困的时候，一看到有arch04这个盘，就它了。一顿操作猛如虎。

所以，不要熬夜变更，上天是不会眷顾熬夜的人的。如果实在要操作的话，找俩年轻力壮的小伙子做，互相check。

不要用分区。ASM不需要你分区。越简单，越好。