一次dd磁盘的风波--

一次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）在维护业务数据库时小心再小心，三思而后行！！！