一次dd磁盘的风波
本人切身一次经历。
在运维客户数据库（核心库之一）由于ASM磁盘组空间不足需要加盘，存储工程师告诉我盘已经划好了，同时也告诉我了****四位LDEV号我同时也叫做lun ID。
接下来就是我们常规的加盘操作。
加盘操作：由于主机信息涉及敏感信息
1.
扫盘操作我们通过Linux RPM包sg3提供
/usr/bin/rescan-scsi-bus.sh 执行脚本即可。
节点1、2都需要执行
2.编写UDEV配置文件
ACTION=="add|change", KERNEL=="dm-?*", ENV{DM_UUID}=="mpath-3600b3422bbd54a2d66a1d66e0d0000dc", SYMLINK+="oracleasm/disks/vsp_raid1_00dc",GROUP="asmadmin", OWNER="grid", MODE="0660"
ACTION=="add|change", KERNEL=="dm-?*", ENV{DM_UUID}=="mpath-3600b34234c106d2dd4cfd908ed0000da", SYMLINK+="oracleasm/disks/vsp_raid1_00da",GROUP="asmadmin", OWNER="grid", MODE="0660"
下图是模版
节点1、2都做。
3.修改磁盘的属组
编写脚本如下：Chown_disk.sh
echo $#
if [ $# -lt 1 ]; then
echo "usage : $0 <dm device>"
exit 1
fi
if [ -d /sys/devices/virtual/block/$1 ]; then
echo 2
udevadm test --action=change /devices/virtual/block/$1/
fi
OK，执行脚本修改盘的属组。
登录ASM实例检查盘是否存在：
select GROUP_NUMBER,DISK_NUMBER,STATE,OS_MB,TOTAL_MB,FREE_MB,NAME,PATH from gv$asm_disk where GROUP_NUMBER=0 order by 5 ;
在这里应该看到rows 2则代表我们盘已正确规划。
3.开始加盘
alter diskgroup DG7 add disk '/dev/oracleasm/disks/vsp_raid1_00dc' rebalance power 8 ;
加盘姿势也很标准，报错如下：
Error：
/dev/oracleasm/disks/vsp_raid1_00dc这个盘已经存在于ARCHDG中，但是这块盘是新加上来的，于是我去DG6中查看该盘是否存在？
错误由此产生：没再去检查/etc/udev/rules.d/96-multipath.rules
清除磁盘头信息：
dd if=/dev/zero of=/dev/mapper/mpathcd bs=1k count=5000
然后再重新加盘
这个时候开始慌了，知道自己那里有问题了。
说不慌其实慌的一逼，那是安慰自己，内心早已凌乱。（这是客户核心库之一，数据量近70T日归档量有8T，众多业务以及边缘业务都依赖与此系统）
值得庆幸的是ARCHDG而不是DATADG，心里还是有把握搞的。
没再多想赶紧理一下思路，整理解决方案：
思路一：提出ARCHDG中坏盘，dd掉重新在加入ARCHDG；
思路二：切换归档路径，删除ARCHDG，重建。（但这种方式就需要删除ARCHDG中所有归档）；
思路一解析：由于我采用dd方式清除了mpathcd 的盘头信息，ASM实例磁盘组，所以采用drop disk未必能够剔除mpathcd该盘。
思路二解析：切换归档路径，删除ARCHDG重建ASM磁盘组，归档则全部丢失。
“归档丢失”也够让我“颤抖”的，核心库有OGG还有DG备库呢！
检查OGG，抽取进程也没延迟。
检查DG备库：
权衡利弊得失，决定还是删除DG重建来的比较快一些。说时迟那时快，抡起袖子就是干。
第一步切换归档路径
第二步切换日志（每一个节点都要切换）
第三步删除archdg
Sqlplus / as sysasm
我们在删除DG前确保OGG抽取、DG备库日志应用没有延迟！
第四步集群资源中提出archdg
第五步create diskgroup
第六步归档盘切回archdg；
到此为止该盘组恢复如初，然而付出的代价却是近2天的归档丢失，值得庆幸的是dd归档盘非数据盘。再不济了，我还有active dataguard 备库呢！
通过这件事情需要我们值得注意，我们作为数据库工程师（DBA）在维护业务数据库时小心再小心，三思而后行！！！